RFC 4276: BGP-4 Implementation Report

RFC Home	Full RFC Index	Recent RFCs	RFC Standards	Best Current Practice	RFC Errata	1 April RFC

IETF RFC 4276

BGP-4 Implementation Report

Last modified on Thursday, January 12th, 2006

Permanent link to RFC 4276

Search GitHub Wiki for RFC 4276

Show other RFCs mentioning RFC 4276 Network Working Group S. Hares Request for Comments: 4276 NextHop Category: Informational 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 [RFC 4271] .................7 3.1. Routes: Advertisement and Storage / Section 3.1 [RFC 4271] ..8 3.2. Routing Information Bases / Section 3.2 [RFC 4271] ..........9 3.3. Message Formats / Section 4 [RFC 4271] ......................9 3.4. Message Header Format / Section 4.1 [RFC 4271] .............10 Hares & Retana Informational PAGE 1 RFC 4276 BGP-4 Implementation Report January 2006 3.5. OPEN Message / Section 4.2 [RFC 4271] ......................11 3.6. UPDATE Message Format / Section 4.3 [RFC 4271] .............12 3.7. KEEPALIVE Message Format / Section 4.4 [RFC 4271] ..........16 3.8. NOTIFICATION Message Format / Section 4.5 [RFC 4271] .......17 3.9. Path Attributes /Section 5 [RFC 4271] ......................17 3.10. ORIGIN / Section 5.1.1 [RFC 4271] .........................22 3.11. AS_PATH / Section 5.1.2 [RFC 4271] ........................22 3.12. NEXT_HOP / Section 5.1.3 [RFC 4271] .......................23 3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC 4271] ................27 3.14. LOCAL_PREF / Section 5.1.5 [RFC 4271] .....................30 3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC 4271] ...............31 3.16. AGGREGATOR / Section 5.1.7 [RFC 4271] .....................32 3.17. BGP Error Handling / Section 6 [RFC 4271] .................34 3.18. Message Header Error Handling / Section 6.1 [RFC 4271] ....34 3.19. OPEN Message Error Handling / Section 6.2 [RFC 4271] ......36 3.20. UPDATE Message Error Handling / Section 6.3 [RFC 4271] ....40 3.21. NOTIFICATION Message Error Handling / Section 6.4 [RFC 4271] ................................................50 3.22. Hold Timer Expired Error Handling / Section 6.5 [RFC 4271] ................................................51 3.23. Finite State Machine Error Handling / Section 6.6 [RFC 4271] ................................................51 3.24. Cease / Section 6.7 [RFC 4271] ............................51 3.25. BGP Connection Collision Detection / Section 6.8 [RFC 4271] ................................................53 3.26. BGP Version Negotiation / Section 7 [RFC 4271] ............54 3.27. BGP Finite State Machine (FSM) / Section 8 [RFC 4271] .....55 3.28. Administrative Events / Section 8.1.2 [RFC 4271] ..........55 3.29. Timer Events / Section 8.1.3 [RFC 4271] ...................61 3.30. TCP Connection-Based Events / Section 8.1.4 [RFC 4271] ....62 3.31. BGP Messages-Based Events / Section 8.1.5 [RFC 4271] ......63 3.32. FSM Definition / Section 8.2.1 [RFC 4271] .................65 3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC 4271] ..66 3.34. FSM Event numbers / Section 8.2.1.4 [RFC 4271] ............66 3.35. Finite State Machine / Section 8.2.2 [RFC 4271] ...........67 3.36. UPDATE Message Handling / Section 9 [RFC 4271] ............67 3.37. Decision Process / Section 9.1 [RFC 4271] .................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 [RFC 4271] .......71 3.40. Route Resolvability Condition / Section 9.1.2.1 [RFC 4271] ................................................73 3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC 4271] ......74 3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC 4271] ...76 3.43. Overlapping Routes / Section 9.1.4 [RFC 4271] .............77 3.44. Update-Send Process / Section 9.2 [RFC 4271] ..............79 3.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC 4271] ........................................81 Hares & Retana Informational PAGE 2 RFC 4276 BGP-4 Implementation Report January 2006 3.46. Aggregating Routing Information / Section 9.2.2.2 [RFC 4271] ................................................82 3.47. Route Selection Criteria / Section 9.3 [RFC 4271] .........87 3.48. Originating BGP Routes / Section 9.4 [RFC 4271] ...........88 3.49. BGP Timers / Section 10 [RFC 4271] ........................88 3.50. TCP Options that May Be Used with BGP / Appendix E [RFC 4271] ..............................................91 3.51. Reducing Route Flapping / Appendix F.2 [RFC 4271] .........92 3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC 4271] .....92 3.53. Security Considerations [RFC 4271] ........................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 [RFC 4271]. RFC 4271 is in alignment with current deployments of BGP-4 and obsoletes the BGP standard [RFC 1771]. 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 [RFC 2385], BGP Route Reflectors [RFC 2796], BGP Confederations [RFC 3065], and BGP Route Refresh [RFC 2918]. The BGP-4 implementation survey had 259 detailed questions about compliance with [RFC 4271]. 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. Hares & Retana Informational PAGE 3 RFC 4276 BGP-4 Implementation Report January 2006 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 [RFC 2119]. 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 [RFC 2119] language in [RFC 4271]. 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, [RFC 4271]) 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.) Hares & Retana Informational PAGE 4 RFC 4276 BGP-4 Implementation Report January 2006 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, [RFC 4271]) Text: The last instance (rightmost occurrence) of that AS number is kept. (Appendix F.6, [RFC 4271]) 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, [RFC 4271]) 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, [RFC 4271]) 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 Hares & Retana Informational PAGE 5 RFC 4276 BGP-4 Implementation Report January 2006 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 Hares & Retana Informational PAGE 6 RFC 4276 BGP-4 Implementation Report January 2006 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: Devendra.raut@Alcatel.com 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: vora@laurelnetworks.com 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 [RFC 2119] 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 [RFC 4271] 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 [RFC 4271] 3.0.1. Base Behavior Functionality/Description: Is your implementation compatible with the base behavior described in this section? RFC 2119: 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 Hares & Retana Informational PAGE 7 RFC 4276 BGP-4 Implementation Report January 2006 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 [RFC 2918] RFC 2119: 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 [RFC 4271] 3.1.3. Withdraw Routes from Service Functionality/Description: Does your implementation support the three methods described in this section? RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 8 RFC 4276 BGP-4 Implementation Report January 2006 3.2. Routing Information Bases / Section 3.2 [RFC 4271] 3.2.5. Routing Information Bases Functionality/Description: Is your implementation compatible with the RIB structure described in this section? RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.3.7. Message Size Functionality/Description: Does your implementation support the message sizes described in this section? RFC 2119: 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 Hares & Retana Informational PAGE 9 RFC 4276 BGP-4 Implementation Report January 2006 3.4. Message Header Format / Section 4.1 [RFC 4271] 3.4.8. Marker Functionality/Description: MUST be set to all ones RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 10 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 [RFC 4271] 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 11 RFC 4276 BGP-4 Implementation Report January 2006 3.5.14. Connection Rejection Functionality/Description: Based on the Hold Time RFC 2119: 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 [RFC 4271] 3.6.15. UPDATE Functionality/Description: Simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 12 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 13 RFC 4276 BGP-4 Implementation Report January 2006 3.6.20. NEXT_HOP Functionality/Description: Used as the next hop to the destinations listed in the NLRI field of the UPDATE message RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 14 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 15 RFC 4276 BGP-4 Implementation Report January 2006 3.7. KEEPALIVE Message Format / Section 4.4 [RFC 4271] 3.7.26. Maximum KEEPALIVE Frequency Functionality/Description: Not greater than one second RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 16 RFC 4276 BGP-4 Implementation Report January 2006 3.8. NOTIFICATION Message Format / Section 4.5 [RFC 4271] 3.8.29. NOTIFICATION Message Functionality/Description: Does your implementation support the NOTIFICATION Message as described in this section? RFC 2119: 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 [RFC 4271] 3.9.30. Path Attributes Functionality/Description: Does your implementation support the path attributes as described in this section? RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 17 RFC 4276 BGP-4 Implementation Report January 2006 3.9.32. Mandatory Attributes Functionality/Description: Included in every UPDATE message that contains NLRI RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 18 RFC 4276 BGP-4 Implementation Report January 2006 3.9.36. Optional Attributes Functionality/Description: In addition to well-known attributes, each path MAY contain one or more optional attributes RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 19 RFC 4276 BGP-4 Implementation Report January 2006 3.9.39. Unrecognized Non-Transitive Optional Attributes Functionality/Description: Quietly ignored and not passed along to other BGP peers RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 20 RFC 4276 BGP-4 Implementation Report January 2006 3.9.42. Path Attributes Functionality/Description: Ordered in ascending order of attribute type RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 21 RFC 4276 BGP-4 Implementation Report January 2006 3.10. ORIGIN / Section 5.1.1 [RFC 4271] 3.10.45. ORIGIN Functionality/Description: Value SHOULD NOT be changed by any speaker, except the originator RFC 2119: 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 [RFC 4271] 3.11.46. AS_PATH Functionality/Description: Not modified when advertising a route to an internal peer RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 22 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 [RFC 4271] 3.12.49. NEXT_HOP Functionality/Description: Used as the next hop to the destinations listed in the UPDATE message RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 23 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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) RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 24 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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) RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 25 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 26 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.13.62. Preferred Metric Functionality/Description: Lowest value RFC 2119: 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 Hares & Retana Informational PAGE 27 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 28 RFC 4276 BGP-4 Implementation Report January 2006 3.13.66. Remove MULTI_EXIT_DISC Functionality/Description: Done prior to determining the degree of preference of the route and performing route selection RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 29 RFC 4276 BGP-4 Implementation Report January 2006 3.14. LOCAL_PREF / Section 5.1.5 [RFC 4271] 3.14.69. LOCAL_PREF Functionality/Description: Included in all UPDATE messages that a given BGP speaker sends to the other internal peers RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 30 RFC 4276 BGP-4 Implementation Report January 2006 3.14.72. LOCAL_PREF Functionality/Description: Not included in UPDATE messages sent to external peers, except for the case of BGP Confederations [RFC 3065] RFC 2119: 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 [RFC 3065] RFC 2119: 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 [RFC 4271] 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 RFC 2119: 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 Hares & Retana Informational PAGE 31 RFC 4276 BGP-4 Implementation Report January 2006 3.15.75. Received ATOMIC_AGGREGATE Functionality/Description: BGP speaker SHOULD NOT remove the attribute from the route when propagating it to other speakers RFC 2119: 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) RFC 2119: 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 [RFC 4271] 3.16.77. AGGREGATOR Functionality/Description: Included in updates which are formed by aggregation (see Section 9.2.2.2) RFC 2119: 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 Hares & Retana Informational PAGE 32 RFC 4276 BGP-4 Implementation Report January 2006 3.16.78. AGGREGATOR Functionality/Description: Added by the BGP speaker performing route aggregation RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 33 RFC 4276 BGP-4 Implementation Report January 2006 3.17. BGP Error Handling / Section 6 [RFC 4271] 3.17.81. Error Handling Functionality/Description: Is your implementation compatible with the error handling procedures described in this section? RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.18.83. Message Header Errors Functionality/Description: Indicated by sending the NOTIFICATION message with Error Code Message Header Error RFC 2119: 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 Hares & Retana Informational PAGE 34 RFC 4276 BGP-4 Implementation Report January 2006 3.18.84. Synchronization Error Functionality/Description: Error Subcode MUST be set to Connection Not Synchronized RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 35 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.19.89. OPEN Message Errors Functionality/Description: Indicated by sending the NOTIFICATION message with Error Code OPEN Message Error RFC 2119: 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 Hares & Retana Informational PAGE 36 RFC 4276 BGP-4 Implementation Report January 2006 3.19.90. Version Number Not Supported Functionality/Description: The Error Subcode MUST be set to Unsupported Version Number RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 37 RFC 4276 BGP-4 Implementation Report January 2006 3.19.93. Hold Time Rejection Functionality/Description: Values of one or two seconds RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 38 RFC 4276 BGP-4 Implementation Report January 2006 3.19.96. Syntactically Incorrect BGP Identifier Functionality/Description: The Error Subcode MUST be set to Bad BGP Identifier RFC 2119: 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 RFC 2119: 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) RFC 2119: 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 Hares & Retana Informational PAGE 39 RFC 4276 BGP-4 Implementation Report January 2006 3.20. UPDATE Message Error Handling / Section 6.3 [RFC 4271] 3.20.99. UPDATE Message Errors Functionality/Description: Indicated by sending the NOTIFICATION message with Error Code UPDATE Message Error RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 40 RFC 4276 BGP-4 Implementation Report January 2006 3.20.102. Conflicting Flags Functionality/Description: The Data field MUST contain the erroneous attribute RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 41 RFC 4276 BGP-4 Implementation Report January 2006 3.20.105. Missing Mandatory Well-Known Attributes Functionality/Description: The Error Subcode MUST be set to Missing Well-known Attribute RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 42 RFC 4276 BGP-4 Implementation Report January 2006 3.20.108. Unrecognized Mandatory Well-Known Attributes Functionality/Description: The Data field MUST contain the unrecognized attribute RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 43 RFC 4276 BGP-4 Implementation Report January 2006 3.20.111. Syntactically Incorrect NEXT_HOP Functionality/Description: The Error Subcode MUST be set to Invalid NEXT_HOP Attribute RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 44 RFC 4276 BGP-4 Implementation Report January 2006 3.20.114. NEXT_HOP Semantic Correctness Functionality/Description: Not be the IP address of the receiving speaker RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 45 RFC 4276 BGP-4 Implementation Report January 2006 3.20.117. Semantically Incorrect NEXT_HOP Functionality/Description: Route Ignored RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 46 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 47 RFC 4276 BGP-4 Implementation Report January 2006 3.20.124. Optional Attribute Error Functionality/Description: The attribute MUST be discarded RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 48 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 49 RFC 4276 BGP-4 Implementation Report January 2006 3.20.130. Semantically Incorrect NLRI Field Functionality/Description: The prefix SHOULD be ignored RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.21.132. Error in NOTIFICATION Message Functionality/Description: Noticed, logged locally, and brought to the attention of the administration of the peer RFC 2119: 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 Hares & Retana Informational PAGE 50 RFC 4276 BGP-4 Implementation Report January 2006 3.22. Hold Timer Expired Error Handling / Section 6.5 [RFC 4271] 3.22.133. Hold Timer Expired Functionality/Description: Is your implementation compatible with the error handling procedures described in this section? RFC 2119: 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 [RFC 4271] 3.23.134. Finite State Machine Errors Functionality/Description: Is your implementation compatible with the error handling procedures described in this section? RFC 2119: 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 [RFC 4271] 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 RFC 2119: 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 Hares & Retana Informational PAGE 51 RFC 4276 BGP-4 Implementation Report January 2006 3.24.136. Cease NOTIFICATION Functionality/Description: Not used for specified fatal errors RFC 2119: 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 RFC 2119: 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 RFC 2119: 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. Hares & Retana Informational PAGE 52 RFC 4276 BGP-4 Implementation Report January 2006 3.24.139. Upper bound on the number of address prefixes the speaker is willing to accept from a neighbor Functionality/Description: Log locally RFC 2119: 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 [RFC 4271] 3.25.140. Connection Collision Functionality/Description: One of the connections MUST be closed RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 53 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 [RFC 4271] 3.26.143. Version Negotiation Functionality/Description: Multiple attempts to open a BGP connection, starting with the highest version number each supports RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 54 RFC 4276 BGP-4 Implementation Report January 2006 3.27. BGP Finite State Machine (FSM) / Section 8 [RFC 4271] 3.27.145. FSM Functionality/Description: Is your implementation compatible with the conceptual FSM described in this section? RFC 2119: 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 [RFC 4271] 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 55 RFC 4276 BGP-4 Implementation Report January 2006 3.28.148. Event3: AutomaticStart Functionality/Description: The AllowAutomaticStart attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 56 RFC 4276 BGP-4 Implementation Report January 2006 3.28.151. Event4: ManualStart_with_PassiveTcpEstablishment Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 57 RFC 4276 BGP-4 Implementation Report January 2006 3.28.154. Event5: AutomaticStart_with_PassiveTcpEstablishment Functionality/Description: The PassiveTcpEstablishment attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 58 RFC 4276 BGP-4 Implementation Report January 2006 3.28.157. Event6: AutomaticStart_with_DampPeerOscillations Functionality/Description: The DampPeerOscillations attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 59 RFC 4276 BGP-4 Implementation Report January 2006 3.28.160. Event7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment Functionality/Description: The DampPeerOscillations attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 60 RFC 4276 BGP-4 Implementation Report January 2006 3.29. Timer Events / Section 8.1.3 [RFC 4271] 3.29.163. Event12: DelayOpenTimer_Expires Functionality/Description: DelayOpen attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 61 RFC 4276 BGP-4 Implementation Report January 2006 3.29.166. Event13: IdleHoldTimer_Expires Functionality/Description: DampPeerOscillations attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.30.168. Event14: TcpConnection_Valid Functionality/Description: BGP's destination port SHOULD be port 179 RFC 2119: 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 Hares & Retana Informational PAGE 62 RFC 4276 BGP-4 Implementation Report January 2006 3.30.169. Event14: TcpConnection_Valid Functionality/Description: The TrackTcpState attribute SHOULD be set to TRUE RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.31.171. Event19: BGPOpen Functionality/Description: The DelayOpen optional attribute SHOULD be set to FALSE RFC 2119: 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 Hares & Retana Informational PAGE 63 RFC 4276 BGP-4 Implementation Report January 2006 3.31.172. Event19: BGPOpen Functionality/Description: The DelayOpenTimer SHOULD not be running RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 64 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 [RFC 4271] 3.32.176. FSM Functionality/Description: Separate FSM for each configured peer RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 65 RFC 4276 BGP-4 Implementation Report January 2006 3.32.178. Incoming Connections Functionality/Description: A state machine MUST be instantiated RFC 2119: 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 [RFC 4271] 3.33.179. Connection Collision Functionality/Description: The corresponding FSM for the connection that is closed SHOULD be disposed of RFC 2119: 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 [RFC 4271] 3.34.180. Event Numbers Functionality/Description: Used to provide network management information RFC 2119: 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. Hares & Retana Informational PAGE 66 RFC 4276 BGP-4 Implementation Report January 2006 3.35. Finite State Machine / Section 8.2.2 [RFC 4271] 3.35.181. ConnectRetryTimer Functionality/Description: Sufficiently large to allow TCP initialization RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.36.183. UPDATE Message Handling Functionality/Description: Does your implementation handle UPDATE messages in a manner compatible to the description in this section? RFC 2119: 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 Hares & Retana Informational PAGE 67 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 68 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.37.189. Decision Process Functionality/Description: Is your implementation compatible with the description in this section? RFC 2119: 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 Hares & Retana Informational PAGE 69 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 [RFC 4271] 3.38.191. Ineligible Degree of Preference Functionality/Description: The route MAY NOT serve as an input to the next phase of route selection RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 70 RFC 4276 BGP-4 Implementation Report January 2006 3.39. Phase 2: Route Selection / Section 9.1.2 [RFC 4271] 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 RFC 2119: 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 RFC 2119: 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) RFC 2119: 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 Hares & Retana Informational PAGE 71 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 72 RFC 4276 BGP-4 Implementation Report January 2006 3.39.199. Unresolvable Routes Functionality/Description: Kept in the corresponding Adj-RIBs-In RFC 2119: 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 [RFC 4271] 3.40.200. Unresolvable Routes Functionality/Description: Excluded from the Phase 2 decision RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 73 RFC 4276 BGP-4 Implementation Report January 2006 3.40.202. Mutual Recursion Functionality/Description: If a route fails the resolvability check because of mutual recursion, an error message SHOULD be logged RFC 2119: 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 [RFC 4271] 3.41.203. Tie-Breaking Criteria Functionality/Description: Applied in the order specified RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 74 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 75 RFC 4276 BGP-4 Implementation Report January 2006 3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC 4271] 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 RFC 2119: 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 RFC 2119: 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) RFC 2119: 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 Hares & Retana Informational PAGE 76 RFC 4276 BGP-4 Implementation Report January 2006 3.43. Overlapping Routes / Section 9.1.4 [RFC 4271] 3.43.211. Overlapping Routes Functionality/Description: Consider both routes based on the configured acceptance policy RFC 2119: 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... RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 77 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 78 RFC 4276 BGP-4 Implementation Report January 2006 3.44. Update-Send Process / Section 9.2 [RFC 4271] 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 [RFC 2796] RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 79 RFC 4276 BGP-4 Implementation Report January 2006 3.44.220. Unfeasible Routes Functionality/Description: Removed from the Loc-RIB RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 80 RFC 4276 BGP-4 Implementation Report January 2006 3.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC 4271] 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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. Hares & Retana Informational PAGE 81 RFC 4276 BGP-4 Implementation Report January 2006 3.45.227. MinRouteAdvertisementIntervalTimer Functionality/Description: The last route selected SHALL be advertised at the end of MinRouteAdvertisementIntervalTimer RFC 2119: 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 [RFC 4271] 3.46.228. MULTI_EXIT_DISC Functionality/Description: Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be aggregated RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 82 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 83 RFC 4276 BGP-4 Implementation Report January 2006 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: ... RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 84 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 85 RFC 4276 BGP-4 Implementation Report January 2006 3.46.239. AS_PATH Aggregation Algorithm Functionality/Description: Able to perform the (minimum) algorithm described in 9.2.2.2. RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 86 RFC 4276 BGP-4 Implementation Report January 2006 3.46.242. AGGREGATOR Functionality/Description: Attach a new one when aggregating (see Section 5.1.7) RFC 2119: 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 [RFC 4271] 3.47.243. Unstable Routes Functionality/Description: Avoid using them RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 87 RFC 4276 BGP-4 Implementation Report January 2006 3.48. Originating BGP Routes / Section 9.4 [RFC 4271] 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) RFC 2119: 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 RFC 2119: 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 [RFC 4271] 3.49.247. Optional Timers Functionality/Description: Two optional timers MAY be supported: DelayOpenTimer, IdleHoldTimer by BGP RFC 2119: 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 Hares & Retana Informational PAGE 88 RFC 4276 BGP-4 Implementation Report January 2006 3.49.248. Hold Time Functionality/Description: Configurable on a per peer basis RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 89 RFC 4276 BGP-4 Implementation Report January 2006 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 RFC 2119: 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 RFC 2119: 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 RFC 2119: 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 Hares & Retana Informational PAGE 90 RFC 4276 BGP-4 Implementation Report January 2006 3.49.254. Jitter Random Value Range Functionality/Description: Configurable RFC 2119: 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 [RFC 4271] 3.50.255. TCP PUSH Function Supported Functionality/Description: Each BGP message SHOULD be transmitted with PUSH flag set RFC 2119: 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) RFC 2119: 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. Hares & Retana Informational PAGE 91 RFC 4276 BGP-4 Implementation Report January 2006 3.51. Reducing Route Flapping / Appendix F.2 [RFC 4271] 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 RFC 2119: 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 [RFC 4271] 3.52.258. Multiple Instances in AS_PATH Functionality/Description: The last instance (rightmost occurrence) of that AS number is kept RFC 2119: 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 [RFC 4271] 3.53.259. Authentication Mechanism Functionality/Description: A BGP implementation MUST support the authentication mechanism specified in RFC 2385 [RFC 2385]. RFC 2119: 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 Hares & Retana Informational PAGE 92 RFC 4276 BGP-4 Implementation Report January 2006 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 [curtis@fictitious.org] 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 [RFC 4271]. 2) What other implementations you interoperate with. Cisco: IOS 12.0(22) Juniper: JUNOS (version not given) 3) 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 4) Did the length of the survey for BGP cause you to not submit the BGP implementation report? yes Hares & Retana Informational PAGE 93 RFC 4276 BGP-4 Implementation Report January 2006 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 2) 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 4) 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: Hares & Retana Informational PAGE 94 RFC 4276 BGP-4 Implementation Report January 2006 1) BGP product Contributor (your name):Rahul Bahadur (rahul.bahadur@nokia.com) Company: Nokia Name of product: IP Security Platforms Version and minor of software IPSO 3.8 Build031 Release date May 24, 2004 2) 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 4) 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 [RFC 4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC 1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 4)", RFC 1771, March 1995. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. Hares & Retana Informational PAGE 95 RFC 4276 BGP-4 Implementation Report January 2006 [RFC 2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [RFC 2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [RFC 3065] 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: Devendra.raut@Alcatel.com Cisco Systems responses provided by: Contact Name: Himanshu Shah, Ruchi Kapoor Contact EMail: hhshah@cisco.com, ruchi@cisco.com Laurel responses provided by: Contact Name: Manish Vora Contact EMail: vora@laurelnetworks.com NextHop responses provided by: Contact Name: Susan Hares Contact EMail: skh@nexthop.com 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: skh@nexthop.com Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 Phone: 919 392 2061 EMail: aretana@cisco.com Hares & Retana Informational PAGE 96 RFC 4276 BGP-4 Implementation Report January 2006 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 ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Hares & Retana Informational PAGE 97 BGP-4 Implementation Report RFC TOTAL SIZE: 132864 bytes PUBLICATION DATE: Thursday, January 12th, 2006 LEGAL RIGHTS: The IETF Trust (see BCP 78)

RFC-ARCHIVE.ORG

© RFC 4276: The IETF Trust, Thursday, January 12th, 2006
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen