Network Working Group
Request for Comments: 4276
Category: Informational
S. Hares
NextHop
A. Retana
Cisco
January 2006

BGP-4 Implementation Report

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).

The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on.

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
   2. Results of Survey ...............................................4
      2.1. Significant Differences ....................................4
      2.2. Overview of Differences ....................................5
      2.3. Implementations and Interoperability .......................6
      2.4. BGP Implementation Identification ..........................7
   3. BGP-4 Implementation Report .....................................7
      3.0. Summary of Operation / Section 3 [RFC4271] .................7
      3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271] ..8
      3.2. Routing Information Bases / Section 3.2 [RFC4271] ..........9
      3.3. Message Formats / Section 4 [RFC4271] ......................9
      3.4. Message Header Format / Section 4.1 [RFC4271] .............10
   
      3.5. OPEN Message / Section 4.2 [RFC4271] ......................11
      3.6. UPDATE Message Format / Section 4.3 [RFC4271] .............12
      3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271] ..........16
      3.8. NOTIFICATION Message Format / Section 4.5 [RFC4271] .......17
      3.9. Path Attributes /Section 5 [RFC4271] ......................17
      3.10. ORIGIN / Section 5.1.1 [RFC4271] .........................22
      3.11. AS_PATH / Section 5.1.2 [RFC4271] ........................22
      3.12. NEXT_HOP / Section 5.1.3 [RFC4271] .......................23
      3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC4271] ................27
      3.14. LOCAL_PREF / Section 5.1.5 [RFC4271] .....................30
      3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC4271] ...............31
      3.16. AGGREGATOR / Section 5.1.7 [RFC4271] .....................32
      3.17. BGP Error Handling / Section 6 [RFC4271] .................34
      3.18. Message Header Error Handling / Section 6.1 [RFC4271] ....34
      3.19. OPEN Message Error Handling / Section 6.2 [RFC4271] ......36
      3.20. UPDATE Message Error Handling / Section 6.3 [RFC4271] ....40
      3.21. NOTIFICATION Message Error Handling / Section 6.4
            [RFC4271] ................................................50
      3.22. Hold Timer Expired Error Handling / Section 6.5
            [RFC4271] ................................................51
      3.23. Finite State Machine Error Handling / Section 6.6
            [RFC4271] ................................................51
      3.24. Cease / Section 6.7 [RFC4271] ............................51
      3.25. BGP Connection Collision Detection / Section 6.8
            [RFC4271] ................................................53
      3.26. BGP Version Negotiation / Section 7 [RFC4271] ............54
      3.27. BGP Finite State Machine (FSM) / Section 8 [RFC4271] .....55
      3.28. Administrative Events / Section 8.1.2 [RFC4271] ..........55
      3.29. Timer Events / Section 8.1.3 [RFC4271] ...................61
      3.30. TCP Connection-Based Events / Section 8.1.4 [RFC4271] ....62
      3.31. BGP Messages-Based Events / Section 8.1.5 [RFC4271] ......63
      3.32. FSM Definition / Section 8.2.1 [RFC4271] .................65
      3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC4271] ..66
      3.34. FSM Event numbers / Section 8.2.1.4 [RFC4271] ............66
      3.35. Finite State Machine / Section 8.2.2 [RFC4271] ...........67
      3.36. UPDATE Message Handling / Section 9 [RFC4271] ............67
      3.37. Decision Process / Section 9.1 [RFC4271] .................69
      3.38. Phase 1: Calculation of Degree of Preference /
            Section 9.1.1 ............................................70
      3.39. Phase 2: Route Selection / Section 9.1.2 [RFC4271] .......71
      3.40. Route Resolvability Condition / Section 9.1.2.1
            [RFC4271] ................................................73
      3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271] ......74
      3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC4271] ...76
      3.43. Overlapping Routes / Section 9.1.4 [RFC4271] .............77
      3.44. Update-Send Process / Section 9.2 [RFC4271] ..............79
      3.45. Frequency of Route Advertisement / Section
            9.2.1.1 [RFC4271] ........................................81
   
      3.46. Aggregating Routing Information / Section 9.2.2.2
            [RFC4271] ................................................82
      3.47. Route Selection Criteria / Section 9.3 [RFC4271] .........87
      3.48. Originating BGP Routes / Section 9.4 [RFC4271] ...........88
      3.49. BGP Timers / Section 10 [RFC4271] ........................88
      3.50. TCP Options that May Be Used with BGP / Appendix
            E [RFC4271] ..............................................91
      3.51. Reducing Route Flapping / Appendix F.2 [RFC4271] .........92
      3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC4271] .....92
      3.53. Security Considerations [RFC4271] ........................92
   4. Additional BGP Implementations Information .....................93
      4.1. Avici .....................................................93
      4.2. Data Connection Ltd. ......................................94
      4.3. Nokia .....................................................94
   5. Security Considerations ........................................95
   6. Normative References ...........................................95
   7. Acknowledgements ...............................................96

1. Introduction

This document reports results from a survey of implementations of BGP-4 as specified in [RFC4271]. RFC 4271 is in alignment with current deployments of BGP-4 and obsoletes the BGP standard [RFC1771]. BGP is a widely deployed cornerstone of Internet technology that continues to add additional functionality as the needs of the Internet evolve. As deployed in the Internet, BGP-4 encompasses both this base specification and additional specifications such as TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065], and BGP Route Refresh [RFC2918].

The BGP-4 implementation survey had 259 detailed questions about compliance with [RFC4271]. Four implementers (Alcatel, Cisco, Laurel, and NextHop) completed the survey. Section 3 provides a compilation of those results.

Section 2.1 highlights significant differences and Section 2.2 provides an overview of the differences between the four implementations. Section 2.3 provides interoperability information.

Due to the large number of BGP implementations and the small number of respondents, the editors took an informal survey to determine if the length of the original survey caused implementers not to submit it. Three implementers responded, and all indicated the length of the survey was the issue. Section 4 gives the results of this informal survey.

In this document, the editors have compiled the results of the implementation survey results and the informal survey.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Results of Survey

The respondents replied "Y" (yes) or "N" (no) to the survey's 259 questions to indicate whether their implementation supports the Functionality/Description of the [RFC2119] language in [RFC4271]. The respondents replied "O" (other) to indicate that the support is neither "Y" nor "N" (for example, an alternate behavior).

2.1. Significant Differences

Each question received affirmative responses from at least two implementers (i.e., two "Y" responses, or one "Y" and one "O"), except the following questions:

   a) MUST - Linked Questions 212/213, regarding Section 9.1.4

Due to the format of the linked questions, three vendors (Cisco, Laurel, and NextHop) replied "N" to Question 213. (See Section 2.2 for details.)

   b) SHALL NOT - Question 228, regarding Section 9.2.2.2

Three vendors (Alcatel, Cisco, and Laurel) answered "N" to SHALL NOT (meaning they did). One vendor (NextHop) indicated "O" matching the specification.

      Text:  Routes that have different MULTI_EXIT_DISC attribute SHALL
             NOT be aggregated.  (Section 9.2.2.2, [RFC4271])

c) SHOULD - Questions 257 and 258, regarding Appendix F

Three vendors answered "N" and one vendor answered "Y" to Question 257. All four vendors answered "N" to Question 258. (Please note that support of Appendix F, "Implementation Recommendations", is optional.)

      Text:  A BGP speaker which needs to withdraw a destination and
             send an update about a more specific or less specific route
             SHOULD combine them into the same UPDATE message.
             (Appendix F.2, [RFC4271])
      
      Text:  The last instance (rightmost occurrence) of that AS number
             is kept.  (Appendix F.6, [RFC4271])

d) MAY - Questions 180 and 254, regarding Sections 8.1.2.4 and 10

Three vendors answered "N", and 1 replied "Y" to Question 180.

      Text:  The Event numbers (1-28) utilized in this state machine
             description aid in specifying the behavior of the BGP state
             machine.  Implementations MAY use these numbers to provide
             network management information.  The exact form of a FSM or
             the FSM events are specific to each implementation.
             (Section 8.1.2.4, [RFC4271])
      
      Editors' note:  Section 8.1.2.4 was written to allow existing
                      implementations to transition to the new event
                      numbering.  It was expected over time (3 years)
                      that the FSM event numbering would be updated to
                      the new numbering.

Three vendors answered "N" and one answered "Y" to Question 254 about configurable jitter time values.

      Text:  A given BGP speaker MAY apply the same jitter to each of
      
             these quantities regardless of the destinations to which
             the updates are being sent; that is, jitter need not be
             configured on a "per peer" basis.  (Section 10, [RFC4271])
      
      Question:  Is the jitter range configurable?

2.2. Overview of Differences

This section provides the reader with a shortcut to the points where the four implementations differ.

The following questions were not answered "Y" by all four respondents (Note that the question numbers correspond to the final digit of subsection numbers of Section 3):

      MUST
      97, 106, 107, 111, 122, 125, 138, 141, 213

SHALL
233, 239

SHALL NOT
228

      SHOULD
      42, 117, 132, 146, 152, 155, 156, 157, 158, 159, 160, 161, 163,
      164, 165, 169, 170, 171, 173, 174, 175, 202, 225, 250, 255, 256

SHOULD NOT
226

      MAY
      67, 94, 121, 143, 180, 223, 247, 254

Other
236, 238

Linked Questions
212/213

Three vendors answered "N" and one answered "Y" to Question 213 about the aggregation of routes. Questions 212 and 213 are grouped together.

Question 212 states: "The decision process MUST either install

         both routes or..."
      
      Question 213 states:  "Aggregate the two routes and install the
         aggregated route, provided that both routes have the same value
         of the NEXT_HOP attribute"

Of the four respondents that said "Y" to Question 212, three said "N" to Question 213. Given the context of the question, answering "N" to Question 213 is appropriate.

2.3. Implementations and Interoperability

                      Alcatel Cisco Laurel NextHop
         Alcatel         Y     Y
         Cisco                 Y
         Laurel                Y      Y
         NextHop               Y             Y

2.4. BGP Implementation Identification

      1.6.0 Alcatel
      Implementation Name/Version:
            Alcatel 7750 BGP Implementation Release 1.3
      Date: July 2003
      Contact Name: Devendra Raut
      Contact Email: [email protected]
      
      1.6.1 Cisco
      Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S
      Contact Name: Alvaro Retana
      Date: 11/26/2003
      
      1.6.2 Laurel
      Implementation Name/Version: Laurel Networks 3.0
      Contact Name: Manish Vora
      Contact Email: [email protected]
      Date: 2/1/2004

1.6.3 NextHop Technologies
Implementation Name/Version: Gated NGC 2.0, 2.2
Date: January 2004

3. BGP-4 Implementation Report

For every item listed, the respondents indicated whether their implementation supports the Functionality/Description or not (Y/N) according to the [RFC2119] language indicated. Any respondent comments are included. If appropriate, the respondents indicated with "O" the fact that the support is neither Y/N (an alternate behavior, for example). Refer to the appropriate sections in [RFC4271] for additional details. Note that the last digit of the subsection number is the number of the survey question.

3.0. Summary of Operation / Section 3 [RFC4271]

3.0.1. Base Behavior

Functionality/Description: Is your implementation compatible with the base behavior described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.0.2. Local Policy Changes

Functionality/Description: To allow local policy changes to have the correct effect without resetting any BGP connections, a BGP speaker SHOULD either (a) retain the current version of the routes advertised to it by all of its peers for the duration of the connection, or (b) make use of the Route Refresh extension [RFC2918]

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271]

   3.1.3.  Withdraw Routes from Service

Functionality/Description: Does your implementation support the three methods described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.1.4. Path Attributes

Functionality/Description: Added to or modified before advertising the route

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.2. Routing Information Bases / Section 3.2 [RFC4271]

3.2.5. Routing Information Bases

Functionality/Description: Is your implementation compatible with the RIB structure described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.2.6. Next Hop Resolution

Functionality/Description: The next hop for each route in the Loc-RIB MUST be resolvable via the local BGP speaker's Routing Table

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.3. Message Formats / Section 4 [RFC4271]

3.3.7. Message Size

Functionality/Description: Does your implementation support the message sizes described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.4. Message Header Format / Section 4.1 [RFC4271]

   3.4.8.  Marker

Functionality/Description:

                                  MUST be set to all ones

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.4.9.  Length

Functionality/Description: MUST always be at least 19 and no greater than 4096

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.4.10.  Length

Functionality/Description: MAY be further constrained, depending on the message type

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.4.11. Message "Padding"

Functionality/Description: No "padding" of extra data after the message is allowed, so the Length field MUST have the smallest value required given the rest of the message

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.5. OPEN Message / Section 4.2 [RFC4271]

3.5.12. Hold Timer Calculation

Functionality/Description: Use the smaller of its configured Hold Time and the Hold Time received in the OPEN message

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.5.13. Minimum Hold Time

Functionality/Description: MUST be either zero or at least three seconds

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.5.14. Connection Rejection

Functionality/Description:

Based on the Hold Time

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    Sends notification.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6. UPDATE Message Format / Section 4.3 [RFC4271]

   3.6.15.  UPDATE

Functionality/Description: Simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    We have capability to process this
                                    functionality on receiving end but
                                    we don't send feasible & unfeasible
                                    simultaneously.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6.16. Transitive Bit Setting

Functionality/Description: For well-known attributes, the Transitive bit MUST be set to 1

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6.17. Partial Bit Setting

Functionality/Description: For well-known attributes and for optional non-transitive attributes the Partial bit MUST be set to 0

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.6.18.  Attribute Flags Octet Sending
   
       Functionality/Description: Lower-order four bits set to zero

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.6.19.  Attribute Flags Octet Receiving
   
       Functionality/Description: Lower-order four bits ignored

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.6.20.  NEXT_HOP

Functionality/Description: Used as the next hop to the destinations listed in the NLRI field of the UPDATE message

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.6.21.  MULTI_EXIT_DISC

Functionality/Description: Used by a BGP speaker's decision process to discriminate among multiple entry points to a neighboring autonomous system

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6.22. AGGREGATOR IP Address

Functionality/Description: Same address as the one used for the BGP Identifier of the speaker

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y    Default behavior.  Can be configured
                                    different from BGP ID.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6.23. UPDATE messages that include the same address prefix in the

WITHDRAWN ROUTES and Network Layer Reachability Information fields

Functionality/Description: UPDATE messages SHOULD NOT include that information

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6.24. UPDATE messages that include the same address prefix in the

WITHDRAWN ROUTES and Network Layer Reachability Information fields

Functionality/Description: The BGP speaker MUST be able to handle them

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.6.25. UPDATE messages that include the same address prefix in the

WITHDRAWN ROUTES and Network Layer Reachability Information fields

Functionality/Description: Treated as if the WITHDRAWN ROUTES doesn't contain the address prefix

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y    Withdrawn routes are processed
                                    before NLRI fields.  Hence we get
                                    the desired behavior.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271]

3.7.26. Maximum KEEPALIVE Frequency

Functionality/Description:

Not greater than one second

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.7.27. KEEPALIVE Messages Rate

Functionality/Description: Adjusted as a function of the Hold Time interval

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.7.28. Negotiated Hold Time of 0

Functionality/Description:

                                  No KEEPALIVEs sent

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.8. NOTIFICATION Message Format / Section 4.5 [RFC4271]

3.8.29. NOTIFICATION Message

Functionality/Description: Does your implementation support the NOTIFICATION Message as described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9. Path Attributes /Section 5 [RFC4271]

3.9.30. Path Attributes

Functionality/Description: Does your implementation support the path attributes as described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.31. Well-Known Attributes

Functionality/Description:

Recognized by all BGP implementations

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.32. Mandatory Attributes

Functionality/Description: Included in every UPDATE message that contains NLRI

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.33/34. Discretionary Attributes

Functionality/Description:

Sent in a particular UPDATE message

RFC2119:

MAY or MAY NOT

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.35. Well-Known Attributes

Functionality/Description: Passed along (after proper updating, if necessary) to other BGP peers

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.36. Optional Attributes

Functionality/Description: In addition to well-known attributes, each path MAY contain one or more optional attributes

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.9.37.  Unrecognized Transitive Optional Attributes

Functionality/Description:

Accepted

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.38. Partial Bit for Unrecognized Transitive Optional Attributes

Functionality/Description: Set to 1 if the attribute is accepted and passed to other BGP speakers

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.9.39.  Unrecognized Non-Transitive Optional Attributes

Functionality/Description: Quietly ignored and not passed along to other BGP peers

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.9.40.  New Transitive Optional Attributes

Functionality/Description: Attached to the path by the originator or by any other BGP speaker in the path

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.41. Optional Attributes

Functionality/Description:

Updated by BGP speakers in the path

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.42. Path Attributes

Functionality/Description: Ordered in ascending order of attribute type

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    All attributes are ordered in
                                    ascending order except Extended
                                    Community, which is type 16 but we
                                    send it out after community
                                    attribute.
       Laurel  Y/N/O/Comments: Y    except for MBGP which is always last
       NextHop Y/N/O/Comments: Y

3.9.43. Out of Order Received Path Attributes

Functionality/Description:

Receiver MUST be able to handle

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.9.44. Mandatory Attributes

Functionality/Description: Present in all exchanges if NLRI are contained in the UPDATE message

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.10. ORIGIN / Section 5.1.1 [RFC4271]

   3.10.45.  ORIGIN

Functionality/Description: Value SHOULD NOT be changed by any speaker, except the originator

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.11. AS_PATH / Section 5.1.2 [RFC4271]

   3.11.46.  AS_PATH

Functionality/Description: Not modified when advertising a route to an internal peer

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.11.47. Segment Overflow

Functionality/Description: If the act of prepending will cause an overflow in the AS_PATH segment, i.e., more than 255 ASs, it SHOULD prepend a new segment of type AS_SEQUENCE and prepend its own AS number to this new segment

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.11.48.  Prepending

Functionality/Description: The local system MAY include/prepend more than one instance of its own AS number in the AS_PATH attribute

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12. NEXT_HOP / Section 5.1.3 [RFC4271]

   3.12.49.  NEXT_HOP

Functionality/Description: Used as the next hop to the destinations listed in the UPDATE message

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.12.50.  NEXT_HOP

Functionality/Description: When sending a message to an internal peer, if the route is not locally originated, the BGP speaker SHOULD NOT modify the NEXT_HOP attribute, unless it has been explicitly configured to announce its own IP address as the NEXT_HOP

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.12.51.  NEXT_HOP

Functionality/Description: When announcing a locally originated route to an internal peer, the BGP speaker SHOULD use as the NEXT_HOP the interface address of the router through which the announced network is reachable for the speaker

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.12.52.  NEXT_HOP

Functionality/Description: If the route is directly connected to the speaker, or the interface address of the router through which the announced network is reachable for the speaker is the internal peer's address, then the BGP speaker SHOULD use for the NEXT_HOP attribute its own IP address (the address of the interface that is used to reach the peer)

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12.53. "First Party" NEXT_HOP

Functionality/Description: If the external peer to which the route is being advertised shares a common subnet with one of the interfaces of the announcing BGP speaker, the speaker MAY use the IP address associated with such an interface in the NEXT_HOP attribute

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12.54. Default NEXT_HOP

Functionality/Description: IP address of the interface that the speaker uses to establish the BGP connection to peer X

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12.55. NEXT_HOP Propagation

Functionality/Description: The speaker MAY be configured to propagate the NEXT_HOP attribute. In this case when advertising a route that the speaker learned from one of its peers, the NEXT_HOP attribute of the advertised route is exactly the same as the NEXT_HOP attribute of the learned route (the speaker just doesn't modify the NEXT_HOP attribute)

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: O
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12.56. Third Party NEXT_HOP

Functionality/Description:

MUST be able to support disabling it

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.12.57.  NEXT_HOP

Functionality/Description: A route originated by a BGP speaker SHALL NOT be advertised to a peer using an address of that peer as NEXT_HOP

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.12.58.  NEXT_HOP

Functionality/Description: A BGP speaker SHALL NOT install a route with itself as the next hop

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.12.59.  NEXT_HOP

Functionality/Description: Used to determine the actual outbound interface and immediate next-hop address that SHOULD be used to forward transit packets to the associated destinations

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12.60. Resolved NEXT_HOP IP Address

Functionality/Description: If the entry specifies an attached subnet, but does not specify a next-hop address, then the address in the NEXT_HOP attribute SHOULD be used as the immediate next-hop address

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.12.61. Resolved NEXT_HOP IP Address

Functionality/Description: If the entry also specifies the next-hop address, this address SHOULD be used as the immediate next-hop address for packet forwarding

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC4271]

3.13.62. Preferred Metric

Functionality/Description:

                                  Lowest value

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.13.63.  MULTI_EXIT_DISC

Functionality/Description: If received over EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other BGP speakers within the same AS

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.13.64.  MULTI_EXIT_DISC

Functionality/Description: If received from a neighboring AS, it MUST NOT be propagated to other neighboring ASes

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.13.65. Remove MULTI_EXIT_DISC

Functionality/Description: Local configuration mechanism to remove the attribute from a route

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.13.66. Remove MULTI_EXIT_DISC

Functionality/Description: Done prior to determining the degree of preference of the route and performing route selection

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.13.67. MULTI_EXIT_DISC Alteration

Functionality/Description: An implementation MAY also (based on local configuration) alter the value of the MULTI_EXIT_DISC attribute received over EBGP

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: O
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.13.68. MULTI_EXIT_DISC Alteration

Functionality/Description: Done prior to determining the degree of preference of the route and performing route selection

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.14. LOCAL_PREF / Section 5.1.5 [RFC4271]

   3.14.69.  LOCAL_PREF

Functionality/Description: Included in all UPDATE messages that a given BGP speaker sends to the other internal peers

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.14.70. Degree of Preference

Functionality/Description: Calculated for each external route based on the locally configured policy, and included when advertising a route to its internal peers

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.14.71.  LOCAL_PREF

Functionality/Description: Higher degree of preference MUST be preferred

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.14.72.  LOCAL_PREF

Functionality/Description: Not included in UPDATE messages sent to external peers, except for the case of BGP Confederations [RFC3065]

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.14.73.  LOCAL_PREF

Functionality/Description: Ignored if received from an external peer, except for the case of BGP Confederations [RFC3065]

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC4271]

   3.15.74.  ATOMIC_AGGREGATE

Functionality/Description: Included if an aggregate excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated as a result of dropping the AS_SET

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.15.75. Received ATOMIC_AGGREGATE

Functionality/Description: BGP speaker SHOULD NOT remove the attribute from the route when propagating it to other speakers

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.15.76. Received ATOMIC_AGGREGATE

Functionality/Description: BGP speaker MUST NOT make any NLRI of that route more specific (as defined in 9.1.4)

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.16. AGGREGATOR / Section 5.1.7 [RFC4271]

   3.16.77.  AGGREGATOR

Functionality/Description: Included in updates which are formed by aggregation (see Section 9.2.2.2)

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.16.78.  AGGREGATOR

Functionality/Description: Added by the BGP speaker performing route aggregation

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.16.79.  AGGREGATOR

Functionality/Description: Contain local AS number and IP address

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y    Default behavior.  Can be configured
                                    different from BGP ID.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.16.80. AGGREGATOR IP Address

Functionality/Description: The same as the BGP Identifier of the speaker

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.17. BGP Error Handling / Section 6 [RFC4271]

3.17.81. Error Handling

Functionality/Description: Is your implementation compatible with the error handling procedures described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.17.82. Error Subcode

       Functionality/Description: Zero, if it is not specified

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.18. Message Header Error Handling / Section 6.1 [RFC4271]

3.18.83. Message Header Errors

Functionality/Description: Indicated by sending the NOTIFICATION message with Error Code Message Header Error

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.18.84. Synchronization Error

Functionality/Description: Error Subcode MUST be set to Connection Not Synchronized

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.18.85. Message Length

Functionality/Description: Use the Bad Message Length Error Subcode to indicate an incorrect message length

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.18.86. Bad Message Length

Functionality/Description: The Data field MUST contain the erroneous Length field

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.18.87. Type Field

Functionality/Description: If the Type field of the message header is not recognized, then the Error Subcode MUST be set to

       Bad Message Type

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.18.88. Bad Message Type

Functionality/Description: The Data field MUST contain the erroneous Type field

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19. OPEN Message Error Handling / Section 6.2 [RFC4271]

3.19.89. OPEN Message Errors

Functionality/Description: Indicated by sending the NOTIFICATION message with Error Code OPEN Message Error

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.90. Version Number Not Supported

Functionality/Description: The Error Subcode MUST be set to Unsupported Version Number

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.91. Unacceptable Autonomous System Field

Functionality/Description: The Error Subcode MUST be set to Bad Peer AS

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.92. Unacceptable Hold Time Error Subcode

Functionality/Description: Used if the Hold Time field of the OPEN message is unacceptable

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.93. Hold Time Rejection

Functionality/Description:

Values of one or two seconds

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.94. Hold Time Rejection

Functionality/Description: An implementation may reject any proposed Hold Time

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y

3.19.95. Hold Time

Functionality/Description: If accepted, then the negotiated value MUST be used

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.96. Syntactically Incorrect BGP Identifier

Functionality/Description: The Error Subcode MUST be set to Bad BGP Identifier

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.97. Not Recognized Optional Parameters

Functionality/Description: The Error Subcode MUST be set to Unsupported Optional Parameters

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We may fix this.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.19.98. Recognized but Malformed Optional Parameters

Functionality/Description: The Error Subcode MUST be set to 0 (Unspecific)

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20. UPDATE Message Error Handling / Section 6.3 [RFC4271]

3.20.99. UPDATE Message Errors

Functionality/Description: Indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error

RFC2119:

               MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.100. Too Large

Functionality/Description: If the Withdrawn Routes Length or Total Attribute Length is too large, then the Error Subcode MUST be set to Malformed Attribute List

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.101. Conflicting Flags

Functionality/Description: If any recognized attribute has Attribute Flags that conflict with the Attribute Type Code, then the Error Subcode MUST be set to Attribute Flags Error

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.102. Conflicting Flags

Functionality/Description: The Data field MUST contain the erroneous attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.103. Conflicting Length

Functionality/Description: If any recognized attribute has Attribute Length that conflicts with the expected length, then the Error Subcode MUST be set to Attribute Length Error

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.104. Conflicting Length

Functionality/Description: The Data field MUST contain the erroneous attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.20.105.  Missing Mandatory Well-Known Attributes

Functionality/Description: The Error Subcode MUST be set to Missing Well-known Attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.20.106.  Missing Mandatory Well-Known Attributes

Functionality/Description: The Data field MUST contain the Attribute Type Code of the missing well-known attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We plan to fix this in future.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.20.107.  Unrecognized Mandatory Well-Known Attributes

Functionality/Description: The Error Subcode MUST be set to Unrecognized Well-known Attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We set error subcode to Attribute
                                    Flags Error, but we intend to
                                    correct this soon.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.20.108.  Unrecognized Mandatory Well-Known Attributes

Functionality/Description: The Data field MUST contain the unrecognized attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.109. Undefined ORIGIN

Functionality/Description: The Error Sub-code MUST be set to Invalid Origin Attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.110. Undefined ORIGIN

Functionality/Description: The Data field MUST contain the unrecognized attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.111. Syntactically Incorrect NEXT_HOP

Functionality/Description: The Error Subcode MUST be set to Invalid NEXT_HOP Attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    Ignores the prefix in case of
                                    martian nexthop, and in case of
                                    length not equal to IPv4
                                    address-length, we send
                                    NOTIFICATION with error subcode
                                    Attribute Length error.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.112. Syntactically Incorrect NEXT_HOP

Functionality/Description: The Data field MUST contain the incorrect attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.113. NEXT_HOP Semantic Correctness

Functionality/Description: NEXT_HOP is checked for semantic correctness against the criteria in this section

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.114. NEXT_HOP Semantic Correctness

Functionality/Description: Not be the IP address of the receiving speaker

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.115. NEXT_HOP Semantic Correctness

Functionality/Description: In the case of an EBGP where the sender and receiver are one IP hop away from each other, either the IP address in the NEXT_HOP MUST be the sender's IP address (that is used to establish the BGP connection), or the interface associated with the NEXT_HOP IP address MUST share a common subnet with the receiving BGP speaker

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.116. Semantically Incorrect NEXT_HOP

Functionality/Description:

                                  Error logged

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.117. Semantically Incorrect NEXT_HOP

Functionality/Description:

                                  Route Ignored

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y

3.20.118. Semantically Incorrect NEXT_HOP

Functionality/Description:

                                  NOTIFICATION not sent

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.119. Semantically Incorrect NEXT_HOP

Functionality/Description:

                                  Connection not closed

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.120. Syntactically Incorrect AS_PATH

Functionality/Description: The Error Subcode MUST be set to Malformed AS_PATH

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.121. First Neighbor in AS_PATH Check

Functionality/Description: If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y

3.20.122. First Neighbor in AS_PATH Check

Functionality/Description: If the check determines that this is not the case, the Error Subcode MUST be set to Malformed AS_PATH

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.20.123. Optional Attributes

Functionality/Description: Value MUST be checked if the attribute is recognized

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.124. Optional Attribute Error

Functionality/Description:

The attribute MUST be discarded

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.125. Optional Attribute Error

Functionality/Description: The Error Subcode MUST be set to Optional Attribute Error

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N   What exactly is optional attribute
                                   e.g., If error is flag related, we
                                   send update flag error subcode, if it
                                   is length related, we send update
                                   length error subcode.  These granular
                                   subcodes are better in terms of
                                   debugging than optional attribute
                                   error.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y   Only optional attribute error that
                                   doesn't have a more specific error,
                                   is the version 3 to version 4 error
                                   for the atomic aggregate.  All others
                                   default to more specific error codes
                                   if implementation.

3.20.126. Optional Attribute Error

Functionality/Description: The Data field MUST contain the attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.127. Duplicate Attributes

Functionality/Description: If any attribute appears more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.128. Syntactically Incorrect NLRI Field

Functionality/Description: The Error Subcode MUST be set to Invalid Network Field

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.129. Semantically Incorrect NLRI Field

Functionality/Description:

An error SHOULD be logged locally

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.130. Semantically Incorrect NLRI Field

Functionality/Description:

The prefix SHOULD be ignored

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.20.131. UPDATE with no NLRI

Functionality/Description: An UPDATE message that contains correct path attributes, but no NLRI, SHALL be treated as a valid UPDATE message

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.21. NOTIFICATION Message Error Handling / Section 6.4 [RFC4271]

3.21.132. Error in NOTIFICATION Message

Functionality/Description: Noticed, logged locally, and brought to the attention of the administration of the peer

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.22. Hold Timer Expired Error Handling / Section 6.5 [RFC4271]

3.22.133. Hold Timer Expired

Functionality/Description: Is your implementation compatible with the error handling procedures described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.23. Finite State Machine Error Handling / Section 6.6 [RFC4271]

3.23.134. Finite State Machine Errors

Functionality/Description: Is your implementation compatible with the error handling procedures described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.24. Cease / Section 6.7 [RFC4271]

3.24.135. Cease NOTIFICATION

Functionality/Description: Used in absence of any fatal errors if a BGP peer chooses at any given time to close its BGP connection

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We close the TCP session without
                                    CEASE NOTIFICATION.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.24.136. Cease NOTIFICATION

Functionality/Description:

Not used for specified fatal errors

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.24.137. Upper bound on the number of address prefixes the speaker

is willing to accept from a neighbor

       Functionality/Description: Support by local configuration

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.24.138. Upper bound on the number of address prefixes the speaker

is willing to accept from a neighbor

Functionality/Description: If exceeded and the BGP speaker decides to terminate its BGP connection, the Cease NOTIFICATION MUST be used

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We don't send CEASE but we plan to
                                    correct that soon.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y    No termination of peers is supported
                                    We are considering support with the
                                    maximum prefix document for later
                                    releases.

3.24.139. Upper bound on the number of address prefixes the speaker

is willing to accept from a neighbor

Functionality/Description:

                                  Log locally

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.25. BGP Connection Collision Detection / Section 6.8 [RFC4271]

3.25.140. Connection Collision

Functionality/Description:

One of the connections MUST be closed

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.25.141. Receipt of an OPEN Message

Functionality/Description: The local system MUST examine all of its connections that are in the OpenConfirm state

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    We detect collision through some
                                    other implementation specific way
                                    and resolve by method specified in
                                    the document.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.25.142. Receipt of an OPEN Message

Functionality/Description: Examine connections in an OpenSent state if it knows the BGP Identifier of the peer by means outside of the protocol

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.26. BGP Version Negotiation / Section 7 [RFC4271]

3.26.143. Version Negotiation

Functionality/Description: Multiple attempts to open a BGP connection, starting with the highest version number each supports

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: N    Supports only version 4
       Cisco   Y/N/O/Comments: O    We resolve it through config. If
                                    Config is for version 3, and we get
                                    version 4, OPEN will always fail.
                                    Similarly, if configed (default) is
                                    version 4 and peers configured is 3,
                                    we don't try to negotiate version 3
                                    unless we have configured it.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: N    Supports only version 4.

3.26.144. Future Versions of BGP

Functionality/Description: MUST retain the format of the OPEN and NOTIFICATION messages

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.27. BGP Finite State Machine (FSM) / Section 8 [RFC4271]

   3.27.145.  FSM

Functionality/Description: Is your implementation compatible with the conceptual FSM described in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28. Administrative Events / Section 8.1.2 [RFC4271]

3.28.146. Optional Session Attribute Settings

Functionality/Description: Each event has an indication of what optional session attributes SHOULD be set at each stage

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    Its rather vague.  We have an option
                                    Of manually starting or stopping
                                    sessions but not an option for all
                                    optional session attributes that are
                                    listed in the document.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y    The following optional attributes
                                    are implied in this implementation:
                                    1) Automatic start, 2) Automatic
                                    Stop, 3)

3.28.147. Event1: ManualStart

Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.148. Event3: AutomaticStart

Functionality/Description: The AllowAutomaticStart attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.149. Event3: AutomaticStart

Functionality/Description: The PassiveTcpEstablishment optional session attribute SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.150. Event3: AutomaticStart

Functionality/Description: DampPeerOscillations SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    Don't support DampPeerOscillations
                                    attribute, so it is always FALSE.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.151. Event4: ManualStart_with_PassiveTcpEstablishment

Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    We wait for some fixed time before
                                    initiating OPEN.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.152. Event4: ManualStart_with_PassiveTcpEstablishment

Functionality/Description: The DampPeerOscillations attribute SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    Don't support DampPeerOscillations
                                    attribute so it is FALSE.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    We don't support DampPeerOscilation
                                    attribute with a setting of off, and
                                    hence Event 4.  Future version will
                                    support Event 4

3.28.153. Event5: AutomaticStart_with_PassiveTcpEstablishment

Functionality/Description: The AllowAutomaticStart attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.154. Event5: AutomaticStart_with_PassiveTcpEstablishment

Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.155. Event5: AutomaticStart_with_PassiveTcpEstablishment

Functionality/Description: The DampPeerOscillations SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    Don't support DampPeerOscillations
                                    attribute, so always FALSE.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    We don't support DampPeerOscilation
                                    attribute with a setting of off, and
                                    hence Event 5.  Future version will
                                    support Event 5

3.28.156. Event6: AutomaticStart_with_DampPeerOscillations

Functionality/Description: The AllowAutomaticStart attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute.
       Laurel  Y/N/O/Comments: Y
       
       NextHop Y/N/O/Comments: Y

3.28.157. Event6: AutomaticStart_with_DampPeerOscillations

Functionality/Description: The DampPeerOscillations attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: N    Don't support DampPeerOscillations
                                    attribute.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.158. Event6: AutomaticStart_with_DampPeerOscillations

Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute and hence Event6.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.159. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Functionality/Description: The AllowAutomaticStart attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute and hence Event7
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.160. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Functionality/Description: The DampPeerOscillations attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute and hence Event7
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.161. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute and hence Event7
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.28.162. Event8: AutomaticStop

Functionality/Description: The AllowAutomaticStop attribute SHOULD be TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.29. Timer Events / Section 8.1.3 [RFC4271]

3.29.163. Event12: DelayOpenTimer_Expires

Functionality/Description: DelayOpen attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.29.164. Event12: DelayOpenTimer_Expires

Functionality/Description: DelayOpenTime attribute SHOULD be supported

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.29.165. Event12: DelayOpenTimer_Expires

       Functionality/Description: DelayOpenTimer SHOULD be supported

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.29.166. Event13: IdleHoldTimer_Expires

Functionality/Description: DampPeerOscillations attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute and hence Event13
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.29.167. Event13: IdleHoldTimer_Expires

Functionality/Description: IdleHoldTimer SHOULD have just expired

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    Don't support DampPeerOscillations
                                    attribute and hence Event13
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.30. TCP Connection-Based Events / Section 8.1.4 [RFC4271]

3.30.168. Event14: TcpConnection_Valid

Functionality/Description: BGP's destination port SHOULD be port 179

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.30.169. Event14: TcpConnection_Valid

Functionality/Description: The TrackTcpState attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    GateD NGC 2.0  provides hooks for
                                    the TCP state tracking, but use of
                                    this option depends OS support.
                                    Future versions will have additional
                                    hooks.

3.30.170. Event15: Tcp_CR_Invalid

Functionality/Description: BGP destination port number SHOULD be 179

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    GateD NGC 2.0  provides hooks for
                                    the TCP state tracking, but use of
                                    this option depends OS support.
                                    Future versions will have additional
                                    hooks.

3.31. BGP Messages-Based Events / Section 8.1.5 [RFC4271]

3.31.171. Event19: BGPOpen

Functionality/Description: The DelayOpen optional attribute SHOULD be set to FALSE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.31.172. Event19: BGPOpen

Functionality/Description: The DelayOpenTimer SHOULD not be running

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.31.173. Event20: BGPOpen with DelayOpenTimer Running

Functionality/Description: The DelayOpen attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N    Not applicable
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.31.174. Event20: BGPOpen with DelayOpenTimer Running

Functionality/Description:

The DelayOpenTimer SHOULD be running

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: n/a
       NextHop Y/N/O/Comments: Y

3.31.175. Event23: OpenCollisionDump

Functionality/Description: If the state machine is to process this event in Established state, the CollisionDetectEstablishedState optional attribute SHOULD be set to TRUE

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y    Collision detection event is logged.
       Cisco   Y/N/O/Comments: O    We always detect collision before we
                                    go to established state.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    GateD NGC 2.0 does not support
                                    Collision Detection in Established
                                    state.  This option attribute  is
                                    always set to FALSE.

3.32. FSM Definition / Section 8.2.1 [RFC4271]

   3.32.176.  FSM

Functionality/Description:

Separate FSM for each configured peer

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.32.177. TCP Port 179

Functionality/Description: A BGP implementation MUST connect to and listen on TCP port 179 for incoming connections in addition to trying to connect to peers

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.32.178. Incoming Connections

Functionality/Description:

A state machine MUST be instantiated

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC4271]

3.33.179. Connection Collision

Functionality/Description: The corresponding FSM for the connection that is closed SHOULD be disposed of

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.34. FSM Event numbers / Section 8.2.1.4 [RFC4271]

3.34.180. Event Numbers

Functionality/Description: Used to provide network management information

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y    Not visible to operator.
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: N    Future Release of GateD NGC may
                                    support event numbers.

3.35. Finite State Machine / Section 8.2.2 [RFC4271]

   3.35.181.  ConnectRetryTimer

Functionality/Description: Sufficiently large to allow TCP initialization

RFC2119:

               SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.35.182. Second Connection Tracking

Functionality/Description: In response to a TCP connection succeeds [Event 16 or Event 17], the 2nd connection SHALL be tracked until it sends an OPEN message

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.36. UPDATE Message Handling / Section 9 [RFC4271]

3.36.183. UPDATE Message Handling

Functionality/Description: Does your implementation handle UPDATE messages in a manner compatible to the description in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.36.184. WITHDRAWN ROUTES

Functionality/Description: Any previously advertised routes whose destinations are contained in this field SHALL be removed from the Adj-RIB-In

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.36.185. WITHDRAWN ROUTES

Functionality/Description: The BGP speaker SHALL run its Decision Process since the previously advertised route is no longer available for use

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.36.186. Implicit Withdraw

Functionality/Description: If an UPDATE message contains a feasible route, and the NLRI of the new route is identical to the one of a route currently stored in the Adj-RIB-In, then the new route SHALL replace the older route

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.36.187. Other Feasible Routes

Functionality/Description: If an UPDATE message contains a feasible route, and the NLRI of the new route is not identical to the one of any route currently stored in the Adj-RIB-In, then the new route SHALL be placed in the Adj-RIB-In

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.36.188. Adj-RIB-In Update

Functionality/Description: Once a BGP speaker updates the Adj-RIB-In, it SHALL run its Decision Process

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.37. Decision Process / Section 9.1 [RFC4271]

3.37.189. Decision Process

Functionality/Description: Is your implementation compatible with the description in this section?

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.37.190. Degree of Preference

Functionality/Description: SHALL NOT use as its inputs any of the following: the existence of other routes, the non-existence of other routes, or the path attributes of other routes

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.38. Phase 1: Calculation of Degree of Preference / Section 9.1.1

[RFC4271]

3.38.191. Ineligible Degree of Preference

Functionality/Description: The route MAY NOT serve as an input to the next phase of route selection

RFC2119:

                MAY NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.38.192. Eligible Degree of Preference

Functionality/Description: Used as the LOCAL_PREF value in any IBGP re-advertisement

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.39. Phase 2: Route Selection / Section 9.1.2 [RFC4271]

3.39.193. Unresolvable NEXT_HOP

Functionality/Description: If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or it would become unresolvable if the route was installed in the routing table the BGP route MUST be excluded

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.39.194.  Routes Installed in LOC-RIB

Functionality/Description: The route in the Adj-RIBs-In identified as the best (see section 9.1.2) is installed in the Loc-RIB, replacing any route to the same destination that is currently being held in the Loc-RIB

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.39.195. Immediate Next-Hop Address

Functionality/Description: MUST be determined from the NEXT_HOP attribute of the selected route (see Section 5.1.3)

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.39.196.  Phase 2: Route Selection

Functionality/Description: Performed again if either the immediate next hop or the IGP cost to the NEXT_HOP changes

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.39.197. Immediate Next-Hop Address

   Functionality/Description: Used for packet forwarding

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.39.198. Unresolvable Routes

Functionality/Description: Removed from the Loc-RIB and the routing table

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.39.199. Unresolvable Routes

       Functionality/Description: Kept in the corresponding Adj-RIBs-In

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.40. Route Resolvability Condition / Section 9.1.2.1 [RFC4271]

3.40.200. Unresolvable Routes

Functionality/Description:

Excluded from the Phase 2 decision

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.40.201. Multiple Matching Routes

Functionality/Description: Only the longest matching route SHOULD be considered

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.40.202. Mutual Recursion

Functionality/Description: If a route fails the resolvability check because of mutual recursion, an error message SHOULD be logged

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    We have checks that disallow mutual
                                    recursion, so this won't happen.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271]

3.41.203. Tie-Breaking Criteria

Functionality/Description:

Applied in the order specified

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.41.204. Algorithm Used

Functionality/Description: BGP implementations MAY use any algorithm which produces the same results as those described here

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.41.205. MULTI_EXIT_DISC Removal

Functionality/Description: If done before re-advertising a route into IBGP, then comparison based on the received EBGP MULTI_EXIT_DISC attribute MAY still be performed

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.41.206. MULTI_EXIT_DISC Removal

Functionality/Description: The optional comparison on MULTI_EXIT_DISC if performed at all MUST be performed only among EBGP learned routes

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.41.207. MULTI_EXIT_DISC Comparison

Functionality/Description:

Performed for IBGP learned routes

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC4271]

3.42.208. Policy for processing routes from the Loc-RIB into

              Adj-RIBs-Out

Functionality/Description: Exclude a route in the Loc-RIB from being installed in a particular Adj-RIB-Out

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.42.209. Adj-Rib-Out Route Installation

Functionality/Description: Not unless the destination and NEXT_HOP described by this route may be forwarded appropriately by the Routing Table

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.42.210. Withdraw Routes

Functionality/Description: If a route in Loc-RIB is excluded from a particular Adj-RIB-Out the previously advertised route in that Adj-RIB-Out MUST be withdrawn from service by means of an UPDATE message (see 9.2)

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.43. Overlapping Routes / Section 9.1.4 [RFC4271]

3.43.211. Overlapping Routes

Functionality/Description: Consider both routes based on the configured acceptance policy

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.43.212. Accepted Overlapping Routes

Functionality/Description: The Decision Process MUST either install both routes or...

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.43.213. Accepted Overlapping Routes

Functionality/Description: Aggregate the two routes and install the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We install both in Local RIB.
       Laurel  Y/N/O/Comments: N    no automatic aggregation
       NextHop Y/N/O/Comments: N    no automatic aggregation
   
   3.43.214.  Aggregation

Functionality/Description: Either include all ASs used to form the aggregate in an AS_SET or add the ATOMIC_AGGREGATE attribute to the route

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.43.215.  De-Aggregation
   
       Functionality/Description: Routes SHOULD NOT be de-aggregated

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.43.216. Route with the ATOMIC_AGGREGATE Attribute

Functionality/Description:

                                  Not de-aggregated

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44. Update-Send Process / Section 9.2 [RFC4271]

3.44.217. UPDATE Message Received from an Internal Peer

Functionality/Description: Not re-distribute the routing information to other internal peers, unless the speaker acts as a BGP Route Reflector [RFC2796]

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44.218. No Replacement Route

Functionality/Description: All newly installed routes and all newly unfeasible routes for which there is no replacement route SHALL be advertised to its peers by means of an UPDATE message

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44.219. Previously Advertised Routes

Functionality/Description: A BGP speaker SHOULD NOT advertise a given feasible BGP route if it would produce an UPDATE message containing the same BGP route as was previously advertised

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44.220. Unfeasible Routes

       Functionality/Description: Removed from the Loc-RIB

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44.221. Changes to Reachable Destinations

Functionality/Description: Changes to the reachable destinations within its own autonomous system SHALL also be advertised in an UPDATE message

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44.222. A single route doesn't fit into the UPDATE message

Functionality/Description:

                                  Don't advertise

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.44.223. A single route doesn't fit into the UPDATE message

       Functionality/Description: Log an error local

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC4271]

   3.45.224.  MinRouteAdvertisementIntervalTimer

Functionality/Description: Minimum separation between two UPDATE messages sent by a BGP speaker to a peer that advertise feasible routes and/or withdrawal of unfeasible routes to some common set of destinations

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.45.225. Fast Convergence

Functionality/Description: MinRouteAdvertisementIntervalTimer used for internal peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer used for external peers, or

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: O    Configurable on per peer basis.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N    they are same for ebgp and ibgp
       NextHop Y/N/O/Comments: Y    Configuration option allows to set
                                    the time per peer.

3.45.226. Fast Convergence

Functionality/Description: The procedure describes in this section SHOULD NOT apply for routes sent to internal peers

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: O    Operator has to ensure that through
                                    configuration.
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y    Default setting is off for BGP
                                    peers.
   
   3.45.227.  MinRouteAdvertisementIntervalTimer

Functionality/Description: The last route selected SHALL be advertised at the end of MinRouteAdvertisementIntervalTimer

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46. Aggregating Routing Information / Section 9.2.2.2 [RFC4271]

   3.46.228.  MULTI_EXIT_DISC

Functionality/Description: Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be aggregated

RFC2119:

                SHALL NOT
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y

3.46.229. AS_SET as the First Element

Functionality/Description: If the aggregated route has an AS_SET as the first element in its AS_PATH attribute, then the router that originates the route SHOULD NOT advertise the MULTI_EXIT_DISC attribute with this route

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.46.230.  NEXT_HOP

Functionality/Description: When aggregating routes that have different NEXT_HOP attribute, the NEXT_HOP attribute of the aggregated route SHALL identify an interface on the BGP speaker that performs the aggregation

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.231. ORIGIN INCOMPLETE

Functionality/Description: Used if at least one route among routes that are aggregated has ORIGIN with the value INCOMPLETE

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.232. ORIGIN EGP

Functionality/Description: Used if at least one route among routes that are aggregated has ORIGIN with the value EGP

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.233. Routes to be aggregated have different AS_PATH attributes

Functionality/Description: The aggregated AS_PATH attribute SHALL satisfy all of the following conditions: ...

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.234. Routes to be aggregated have different AS_PATH attributes

Functionality/Description: All tuples of type AS_SEQUENCE in the aggregated AS_PATH SHALL appear in all of the AS_PATH in the initial set of routes to be aggregated

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.235. Routes to be aggregated have different AS_PATH attributes

Functionality/Description: All tuples of type AS_SET in the aggregated AS_PATH SHALL appear in at least one of the AS_PATH in the initial set

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.236. Routes to be aggregated have different AS_PATH attributes

Functionality/Description: For any tuple X of type AS_SEQUENCE in the aggregated AS_PATH which precedes tuple Y in the aggregated AS_PATH, X precedes Y in each AS_PATH in the initial set which contains Y, regardless of the type of Y

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.237. Routes to be aggregated have different AS_PATH attributes

Functionality/Description: No tuple of type AS_SET with the same value SHALL appear more than once in the aggregated AS_PATH

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.46.238. Routes to be aggregated have different AS_PATH attributes

Functionality/Description: Multiple tuples of type AS_SEQUENCE with the same value may appear in the aggregated AS_PATH only when adjacent to another tuple of the same type and value

RFC2119:

                N/A
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: Y

3.46.239. AS_PATH Aggregation Algorithm

Functionality/Description: Able to perform the (minimum) algorithm described in 9.2.2.2.

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N    We don't do merging.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.46.240.  ATOMIC_AGGREGATE

Functionality/Description: The aggregated route SHALL have this attribute if at least one of the routes to be aggregated has it

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.46.241.  AGGREGATOR

Functionality/Description: Attribute from routes to be aggregated MUST NOT be included in aggregated route

RFC2119:

                MUST NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.46.242.  AGGREGATOR

Functionality/Description: Attach a new one when aggregating (see Section 5.1.7)

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.47. Route Selection Criteria / Section 9.3 [RFC4271]

3.47.243. Unstable Routes

Functionality/Description:

                                  Avoid using them

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.47.244. Route Changes

Functionality/Description: SHOULD NOT make rapid spontaneous changes to the choice of route

RFC2119:

                SHOULD NOT
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.48. Originating BGP Routes / Section 9.4 [RFC4271]

3.48.245. Non-BGP Acquired Routes

Functionality/Description: Distributed to other BGP speakers within the local AS as part of the update process (see Section 9.2)

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.48.246. Non-BGP Acquired Routes

       Functionality/Description: Distribution controlled via
       configuration

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.49. BGP Timers / Section 10 [RFC4271]

3.49.247. Optional Timers

Functionality/Description: Two optional timers MAY be supported: DelayOpenTimer, IdleHoldTimer by BGP

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: O    We support DelayOpenTimer but not
                                    IdleHoldTimer
       Laurel  Y/N/O/Comments: Y    support IdleHoldTimer but not the
                                    DelayOpenTimer
       NextHop Y/N/O/Comments: Y

3.49.248. Hold Time

Functionality/Description:

Configurable on a per peer basis

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.49.249.  Timers

Functionality/Description: Allow the other timers to be configurable

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.49.250.  Jitter

Functionality/Description: Applied to the timers associated with MinASOriginationInterval, KeepAlive, MinRouteAdvertisementInterval, and ConnectRetry

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: O    We only apply to ConnectRetry.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y
   
   3.49.251.  Jitter

Functionality/Description: Apply the same jitter to each of these quantities regardless of the destinations to which the updates are being sent; that is, jitter need not be configured on a "per peer" basis

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y    We apply same only for connectretry.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.49.252. Default Amount of jitter

Functionality/Description: Determined by multiplying the base value of the appropriate timer by a random factor which is uniformly distributed in the range from 0.75 to 1.0

RFC2119:

                SHALL
       
       Alcatel Y/N/O/Comments: Y    Range is 0.9 to 1.1
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.49.253. Default Amount of jitter

Functionality/Description: New random value picked each time the timer is set

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

3.49.254. Jitter Random Value Range

Functionality/Description:

                                  Configurable

RFC2119:

                MAY
       
       Alcatel Y/N/O/Comments: N
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: N

3.50. TCP Options that May Be Used with BGP / Appendix E [RFC4271]

3.50.255. TCP PUSH Function Supported

Functionality/Description: Each BGP message SHOULD be transmitted with PUSH flag set

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    Depends on the TCP stack support.
                                    GateD 10, NGC can run over
                                    multiple stacks.

3.50.256. Differentiated Services Code Point (DSCP) Field Support

Functionality/Description: TCP connections opened with bits 0-2 of the DSCP field set to 110 (binary)

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: O    Depends on the TCP stack support.
                                    GateD 10, NGC can run over
                                    multiple stacks.

3.51. Reducing Route Flapping / Appendix F.2 [RFC4271]

3.51.257. Avoid Excessive Route Flapping

Functionality/Description: A BGP speaker which needs to withdraw a destination and send an update about a more specific or less specific route SHOULD combine them into the same UPDATE message

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: N

3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC4271]

3.52.258. Multiple Instances in AS_PATH

Functionality/Description: The last instance (rightmost occurrence) of that AS number is kept

RFC2119:

                SHOULD
       
       Alcatel Y/N/O/Comments: N    We use algorithm in 9.2.2.2
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: N
       NextHop Y/N/O/Comments: N

3.53. Security Considerations [RFC4271]

3.53.259. Authentication Mechanism

Functionality/Description: A BGP implementation MUST support the authentication mechanism specified in RFC 2385 [RFC2385].

RFC2119:

                MUST
       
       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

4. Additional BGP Implementations Information

Three implementations responded to a call (5/20/04-6/2/04) for information on those implementations that had a BGP implementation, but did not complete the full survey. The responses for the call for additional information are below.

4.1. Avici

If you have an implementation of BGP and you did not send in an implementation report (answering the 259 questions), could you send me the answer the following questions:

  1. BGP product Contributor (your name):Curtis Villamizar [[email protected]] Company: Avici name of product: IPriori (TM) minor version: No interoperability problems with any version.

Current deployed versions are 5.x and 6.0.x.

Version 6.1 and beyond are tested against the

latest BGP specification [RFC4271].

  1. What other implementations you interoperate with.
         Cisco: IOS 12.0(22)
         Juniper: JUNOS (version not given)
  1. Do you inter-operate with:
      1) Alcatel BGP (release) - not tested
      2) cisco BGP IOS 12.0(27)s - not tested
            tested with IOS 12.0(22); BGP is the same
      3) laurel BGP (specify release) - not tested
      4) NextHop GateD - not tested
  1. Did the length of the survey for BGP cause you to not submit the BGP implementation report?
      yes

4.2. Data Connection Ltd.

If you have an implementation of BGP and you did not send in an implementation report (answering the 259 questions), could you send me the answer the following questions:

  1. BGP product Contributor (your name): Mike Dell Company: Data Connection Ltd. name of product: DC-BGP version and minor of software: v1.1 release date: April 2003
  1. What other implementations you interoperate with.

Cisco (12.0(26)S)
Alcatal (7770 0BX)
Agilent (Router Tester)
Ixia (1600T)
Netplane (Powercode)
Nortel (Shasta 5000 BSN)
Redback (SmartEdge 800)
Riverstone (RS8000)
Spirent (AX4000)
IP Infusion (ZebOs)
Nokia (IP400)
Juniper (M5)

   3) Do you inter-operate with
   
      1) Alcatel BGP (release)      YES
      2) cisco BGP IOS 12.0(27)s
            Unknown, but we do inter-operate with v12.0(26)s
      3) laurel BGP (specify release)  Unknown
      4) NextHop GateD           YES
  1. Did the length of the survey for BGP cause you to not submit the BGP implementation report?
         YES

4.3. Nokia

If you have an implementation of BGP and you did not send in an implementation report (answering the 259 questions), could you send me the answer the following questions:

  1. BGP product
    Contributor (your name):Rahul Bahadur
                           ([email protected])
    Company:                      Nokia
    Name of product:              IP Security Platforms
    Version and minor of software IPSO 3.8 Build031
    Release date                  May 24, 2004
  1. What other implementations you interoperate with.
          Cisco: IOS 12.3(1)
          Extreme: Extremeware Version 6.1.7 (Build 9)
          Foundry: SW Version 07.5.05iT53
          Juniper: JUNOS 5.3R1.2
          Nortel: BayRS 15.4.0.1
          GNU Zebra: zebra-0.92a
   
   3) Do you inter-operate with

1) Alcatel BGP (release) - not tested
2) cisco BGP IOS 12.0(27)s - yes
3) laurel BGP (specify release) - not tested
4) NextHop GateD - not tested

  1. Did the length of the survey for BGP cause you to not submit the BGP implementation report?

Yes - lack of resources to help with task.

5. Security Considerations

This document does not address any security issues.

6. Normative References

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.
   
   [RFC1771]  Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
              4)", RFC 1771, March 1995.
   
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
   
   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.
   
   [RFC2796]  Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection
              - An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
   
   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
              September 2000.
   
   [RFC3065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
              System Confederations for BGP", RFC 3065, February 2001.

7. Acknowledgements

   Alcatel responses provided by:
   Contact Name: Devendra Raut
   Contact EMail: [email protected]
   
   Cisco Systems responses provided by:
   Contact Name: Himanshu Shah, Ruchi Kapoor
   Contact EMail: [email protected], [email protected]
   
   Laurel responses provided by:
   Contact Name: Manish Vora
   Contact EMail: [email protected]
   
   NextHop responses provided by:
   Contact Name: Susan Hares
   Contact EMail: [email protected]
   Additional Help:  Matt Richardson, Shane Wright.

Authors' Addresses

Susan Hares
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108

   Phone: 734.222.1610
   EMail: [email protected]

Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709

   Phone: 919 392 2061
   EMail: [email protected]

Full Copyright Statement

Copyright © The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [email protected].

Acknowledgement

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).