diff options
Diffstat (limited to 'doc/rfc/rfc4276.txt')
| -rw-r--r-- | doc/rfc/rfc4276.txt | 5435 |
1 files changed, 5435 insertions, 0 deletions
diff --git a/doc/rfc/rfc4276.txt b/doc/rfc/rfc4276.txt new file mode 100644 index 0000000..983464d --- /dev/null +++ b/doc/rfc/rfc4276.txt @@ -0,0 +1,5435 @@ + + + + + + +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 (C) The Internet Society (2006). + +Abstract + + This document reports the results of the BGP-4 implementation survey. + The survey had 259 questions about implementations' support of BGP-4 + as specified in RFC 4271. After a brief summary of the results, each + response is listed. This document contains responses from the four + implementers that completed the survey (Alcatel, Cisco, Laurel, and + NextHop) and brief information from three that did not (Avici, Data + Connection Ltd., and Nokia). + + The editors did not use exterior means to verify the accuracy of the + information submitted by the respondents. The respondents are + experts with the products they reported on. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 2. Results of Survey ...............................................4 + 2.1. Significant Differences ....................................4 + 2.2. Overview of Differences ....................................5 + 2.3. Implementations and Interoperability .......................6 + 2.4. BGP Implementation Identification ..........................7 + 3. BGP-4 Implementation Report .....................................7 + 3.0. Summary of Operation / Section 3 [RFC4271] .................7 + 3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271] ..8 + 3.2. Routing Information Bases / Section 3.2 [RFC4271] ..........9 + 3.3. Message Formats / Section 4 [RFC4271] ......................9 + 3.4. Message Header Format / Section 4.1 [RFC4271] .............10 + + + +Hares & Retana Informational [Page 1] + +RFC 4276 BGP-4 Implementation Report January 2006 + + + 3.5. OPEN Message / Section 4.2 [RFC4271] ......................11 + 3.6. UPDATE Message Format / Section 4.3 [RFC4271] .............12 + 3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271] ..........16 + 3.8. NOTIFICATION Message Format / Section 4.5 [RFC4271] .......17 + 3.9. Path Attributes /Section 5 [RFC4271] ......................17 + 3.10. ORIGIN / Section 5.1.1 [RFC4271] .........................22 + 3.11. AS_PATH / Section 5.1.2 [RFC4271] ........................22 + 3.12. NEXT_HOP / Section 5.1.3 [RFC4271] .......................23 + 3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC4271] ................27 + 3.14. LOCAL_PREF / Section 5.1.5 [RFC4271] .....................30 + 3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC4271] ...............31 + 3.16. AGGREGATOR / Section 5.1.7 [RFC4271] .....................32 + 3.17. BGP Error Handling / Section 6 [RFC4271] .................34 + 3.18. Message Header Error Handling / Section 6.1 [RFC4271] ....34 + 3.19. OPEN Message Error Handling / Section 6.2 [RFC4271] ......36 + 3.20. UPDATE Message Error Handling / Section 6.3 [RFC4271] ....40 + 3.21. NOTIFICATION Message Error Handling / Section 6.4 + [RFC4271] ................................................50 + 3.22. Hold Timer Expired Error Handling / Section 6.5 + [RFC4271] ................................................51 + 3.23. Finite State Machine Error Handling / Section 6.6 + [RFC4271] ................................................51 + 3.24. Cease / Section 6.7 [RFC4271] ............................51 + 3.25. BGP Connection Collision Detection / Section 6.8 + [RFC4271] ................................................53 + 3.26. BGP Version Negotiation / Section 7 [RFC4271] ............54 + 3.27. BGP Finite State Machine (FSM) / Section 8 [RFC4271] .....55 + 3.28. Administrative Events / Section 8.1.2 [RFC4271] ..........55 + 3.29. Timer Events / Section 8.1.3 [RFC4271] ...................61 + 3.30. TCP Connection-Based Events / Section 8.1.4 [RFC4271] ....62 + 3.31. BGP Messages-Based Events / Section 8.1.5 [RFC4271] ......63 + 3.32. FSM Definition / Section 8.2.1 [RFC4271] .................65 + 3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC4271] ..66 + 3.34. FSM Event numbers / Section 8.2.1.4 [RFC4271] ............66 + 3.35. Finite State Machine / Section 8.2.2 [RFC4271] ...........67 + 3.36. UPDATE Message Handling / Section 9 [RFC4271] ............67 + 3.37. Decision Process / Section 9.1 [RFC4271] .................69 + 3.38. Phase 1: Calculation of Degree of Preference / + Section 9.1.1 ............................................70 + 3.39. Phase 2: Route Selection / Section 9.1.2 [RFC4271] .......71 + 3.40. Route Resolvability Condition / Section 9.1.2.1 + [RFC4271] ................................................73 + 3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271] ......74 + 3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC4271] ...76 + 3.43. Overlapping Routes / Section 9.1.4 [RFC4271] .............77 + 3.44. Update-Send Process / Section 9.2 [RFC4271] ..............79 + 3.45. Frequency of Route Advertisement / Section + 9.2.1.1 [RFC4271] ........................................81 + + + +Hares & Retana Informational [Page 2] + +RFC 4276 BGP-4 Implementation Report January 2006 + + + 3.46. Aggregating Routing Information / Section 9.2.2.2 + [RFC4271] ................................................82 + 3.47. Route Selection Criteria / Section 9.3 [RFC4271] .........87 + 3.48. Originating BGP Routes / Section 9.4 [RFC4271] ...........88 + 3.49. BGP Timers / Section 10 [RFC4271] ........................88 + 3.50. TCP Options that May Be Used with BGP / Appendix + E [RFC4271] ..............................................91 + 3.51. Reducing Route Flapping / Appendix F.2 [RFC4271] .........92 + 3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC4271] .....92 + 3.53. Security Considerations [RFC4271] ........................92 + 4. Additional BGP Implementations Information .....................93 + 4.1. Avici .....................................................93 + 4.2. Data Connection Ltd. ......................................94 + 4.3. Nokia .....................................................94 + 5. Security Considerations ........................................95 + 6. Normative References ...........................................95 + 7. Acknowledgements ...............................................96 + +1. Introduction + + This document reports results from a survey of implementations of + BGP-4 as specified in [RFC4271]. RFC 4271 is in alignment with + current deployments of BGP-4 and obsoletes the BGP standard + [RFC1771]. BGP is a widely deployed cornerstone of Internet + technology that continues to add additional functionality as the + needs of the Internet evolve. As deployed in the Internet, BGP-4 + encompasses both this base specification and additional + specifications such as TCP MD5 [RFC2385], BGP Route Reflectors + [RFC2796], BGP Confederations [RFC3065], and BGP Route Refresh + [RFC2918]. + + The BGP-4 implementation survey had 259 detailed questions about + compliance with [RFC4271]. Four implementers (Alcatel, Cisco, + Laurel, and NextHop) completed the survey. Section 3 provides a + compilation of those results. + + Section 2.1 highlights significant differences and Section 2.2 + provides an overview of the differences between the four + implementations. Section 2.3 provides interoperability information. + + Due to the large number of BGP implementations and the small number + of respondents, the editors took an informal survey to determine if + the length of the original survey caused implementers not to submit + it. Three implementers responded, and all indicated the length of + the survey was the issue. Section 4 gives the results of this + informal survey. + + + + + +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 [RFC2119]. + +2. Results of Survey + + The respondents replied "Y" (yes) or "N" (no) to the survey's 259 + questions to indicate whether their implementation supports the + Functionality/Description of the [RFC2119] language in [RFC4271]. + The respondents replied "O" (other) to indicate that the support is + neither "Y" nor "N" (for example, an alternate behavior). + +2.1. Significant Differences + + Each question received affirmative responses from at least two + implementers (i.e., two "Y" responses, or one "Y" and one "O"), + except the following questions: + + a) MUST - Linked Questions 212/213, regarding Section 9.1.4 + + Due to the format of the linked questions, three vendors (Cisco, + Laurel, and NextHop) replied "N" to Question 213. (See Section + 2.2 for details.) + + b) SHALL NOT - Question 228, regarding Section 9.2.2.2 + + Three vendors (Alcatel, Cisco, and Laurel) answered "N" to SHALL + NOT (meaning they did). One vendor (NextHop) indicated "O" + matching the specification. + + Text: Routes that have different MULTI_EXIT_DISC attribute SHALL + NOT be aggregated. (Section 9.2.2.2, [RFC4271]) + + c) SHOULD - Questions 257 and 258, regarding Appendix F + + Three vendors answered "N" and one vendor answered "Y" to Question + 257. All four vendors answered "N" to Question 258. (Please note + that support of Appendix F, "Implementation Recommendations", is + optional.) + + + + + + + +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, [RFC4271]) + + Text: The last instance (rightmost occurrence) of that AS number + is kept. (Appendix F.6, [RFC4271]) + + d) MAY - Questions 180 and 254, regarding Sections 8.1.2.4 and 10 + + Three vendors answered "N", and 1 replied "Y" to Question 180. + + Text: The Event numbers (1-28) utilized in this state machine + description aid in specifying the behavior of the BGP state + machine. Implementations MAY use these numbers to provide + network management information. The exact form of a FSM or + the FSM events are specific to each implementation. + (Section 8.1.2.4, [RFC4271]) + + Editors' note: Section 8.1.2.4 was written to allow existing + implementations to transition to the new event + numbering. It was expected over time (3 years) + that the FSM event numbering would be updated to + the new numbering. + + Three vendors answered "N" and one answered "Y" to Question 254 + about configurable jitter time values. + + Text: A given BGP speaker MAY apply the same jitter to each of + these quantities regardless of the destinations to which + the updates are being sent; that is, jitter need not be + configured on a "per peer" basis. (Section 10, [RFC4271]) + + Question: Is the jitter range configurable? + +2.2. Overview of Differences + + This section provides the reader with a shortcut to the points where + the four implementations differ. + + The following questions were not answered "Y" by all four respondents + (Note that the question numbers correspond to the final digit of + subsection numbers of Section 3): + + MUST + 97, 106, 107, 111, 122, 125, 138, 141, 213 + + + + + +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 [RFC2119] language indicated. Any respondent + comments are included. If appropriate, the respondents indicated + with "O" the fact that the support is neither Y/N (an alternate + behavior, for example). Refer to the appropriate sections in + [RFC4271] for additional details. Note that the last digit of the + subsection number is the number of the survey question. + +3.0. Summary of Operation / Section 3 [RFC4271] + + 3.0.1. Base Behavior + + Functionality/Description: Is your implementation compatible + with the base behavior described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + +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 + [RFC2918] + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271] + + 3.1.3. Withdraw Routes from Service + + Functionality/Description: Does your implementation support the + three methods described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.1.4. Path Attributes + + Functionality/Description: Added to or modified before + advertising the route + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + +Hares & Retana Informational [Page 8] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.2. Routing Information Bases / Section 3.2 [RFC4271] + + 3.2.5. Routing Information Bases + + Functionality/Description: Is your implementation compatible + with the RIB structure described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.2.6. Next Hop Resolution + + Functionality/Description: The next hop for each route in the + Loc-RIB MUST be resolvable via the local BGP speaker's Routing + Table + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.3. Message Formats / Section 4 [RFC4271] + + 3.3.7. Message Size + + Functionality/Description: Does your implementation support the + message sizes described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + +Hares & Retana Informational [Page 9] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.4. Message Header Format / Section 4.1 [RFC4271] + + + 3.4.8. Marker + + Functionality/Description: MUST be set to all ones + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.4.9. Length + + Functionality/Description: MUST always be at least 19 and no + greater than 4096 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.4.10. Length + + Functionality/Description: MAY be further constrained, depending + on the message type + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.5. OPEN Message / Section 4.2 [RFC4271] + + 3.5.12. Hold Timer Calculation + + Functionality/Description: Use the smaller of its configured + Hold Time and the Hold Time received in the OPEN message + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.5.13. Minimum Hold Time + + Functionality/Description: MUST be either zero or at least three + seconds + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y Sends notification. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.6. UPDATE Message Format / Section 4.3 [RFC4271] + + 3.6.15. UPDATE + + Functionality/Description: Simultaneously advertise a feasible + route and withdraw multiple unfeasible routes from service + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: O We have capability to process this + functionality on receiving end but + we don't send feasible & unfeasible + simultaneously. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.16. Transitive Bit Setting + + Functionality/Description: For well-known attributes, the + Transitive bit MUST be set to 1 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.18. Attribute Flags Octet Sending + + Functionality/Description: Lower-order four bits set to zero + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.19. Attribute Flags Octet Receiving + + Functionality/Description: Lower-order four bits ignored + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.21. MULTI_EXIT_DISC + + Functionality/Description: Used by a BGP speaker's decision + process to discriminate among multiple entry points to a + neighboring autonomous system + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.22. AGGREGATOR IP Address + + Functionality/Description: Same address as the one used for the + BGP Identifier of the speaker + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y Default behavior. Can be configured + different from BGP ID. + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.24. UPDATE messages that include the same address prefix in the + WITHDRAWN ROUTES and Network Layer Reachability Information + fields + + Functionality/Description: The BGP speaker MUST be able to handle + them + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.6.25. UPDATE messages that include the same address prefix in the + WITHDRAWN ROUTES and Network Layer Reachability Information + fields + + Functionality/Description: Treated as if the WITHDRAWN ROUTES + doesn't contain the address prefix + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y Withdrawn routes are processed + before NLRI fields. Hence we get + the desired behavior. + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + +Hares & Retana Informational [Page 15] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271] + + 3.7.26. Maximum KEEPALIVE Frequency + + Functionality/Description: Not greater than one second + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.7.27. KEEPALIVE Messages Rate + + Functionality/Description: Adjusted as a function of the Hold + Time interval + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.7.28. Negotiated Hold Time of 0 + + Functionality/Description: No KEEPALIVEs sent + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +Hares & Retana Informational [Page 16] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.8. NOTIFICATION Message Format / Section 4.5 [RFC4271] + + 3.8.29. NOTIFICATION Message + + Functionality/Description: Does your implementation support the + NOTIFICATION Message as described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.9. Path Attributes /Section 5 [RFC4271] + + 3.9.30. Path Attributes + + Functionality/Description: Does your implementation support the + path attributes as described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.31. Well-Known Attributes + + Functionality/Description: Recognized by all BGP implementations + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.33/34. Discretionary Attributes + + Functionality/Description: Sent in a particular UPDATE message + + RFC2119: MAY or MAY NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.35. Well-Known Attributes + + Functionality/Description: Passed along (after proper updating, + if necessary) to other BGP peers + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.37. Unrecognized Transitive Optional Attributes + + Functionality/Description: Accepted + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.38. Partial Bit for Unrecognized Transitive Optional Attributes + + Functionality/Description: Set to 1 if the attribute is accepted + and passed to other BGP speakers + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.40. New Transitive Optional Attributes + + Functionality/Description: Attached to the path by the + originator or by any other BGP speaker in the path + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.41. Optional Attributes + + Functionality/Description: Updated by BGP speakers in the path + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: O All attributes are ordered in + ascending order except Extended + Community, which is type 16 but we + send it out after community + attribute. + Laurel Y/N/O/Comments: Y except for MBGP which is always last + NextHop Y/N/O/Comments: Y + + + 3.9.43. Out of Order Received Path Attributes + + Functionality/Description: Receiver MUST be able to handle + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.9.44. Mandatory Attributes + + Functionality/Description: Present in all exchanges if NLRI are + contained in the UPDATE message + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +Hares & Retana Informational [Page 21] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.10. ORIGIN / Section 5.1.1 [RFC4271] + + 3.10.45. ORIGIN + + Functionality/Description: Value SHOULD NOT be changed by any + speaker, except the originator + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.11. AS_PATH / Section 5.1.2 [RFC4271] + + 3.11.46. AS_PATH + + Functionality/Description: Not modified when advertising a route + to an internal peer + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.11.47. Segment Overflow + + Functionality/Description: If the act of prepending will cause + an overflow in the AS_PATH segment, i.e., more than 255 ASs, it + SHOULD prepend a new segment of type AS_SEQUENCE and prepend its + own AS number to this new segment + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.12. NEXT_HOP / Section 5.1.3 [RFC4271] + + 3.12.49. NEXT_HOP + + Functionality/Description: Used as the next hop to the + destinations listed in the UPDATE message + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.50. NEXT_HOP + + Functionality/Description: When sending a message to an internal + peer, if the route is not locally originated, the BGP speaker + SHOULD NOT modify the NEXT_HOP attribute, unless it has been + explicitly configured to announce its own IP address as the + NEXT_HOP + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.52. NEXT_HOP + + Functionality/Description: If the route is directly connected to + the speaker, or the interface address of the router through + which the announced network is reachable for the speaker is the + internal peer's address, then the BGP speaker SHOULD use for the + NEXT_HOP attribute its own IP address (the address of the + interface that is used to reach the peer) + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.53. "First Party" NEXT_HOP + + Functionality/Description: If the external peer to which the + route is being advertised shares a common subnet with one of the + interfaces of the announcing BGP speaker, the speaker MAY use + the IP address associated with such an interface in the NEXT_HOP + attribute + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.55. NEXT_HOP Propagation + + Functionality/Description: The speaker MAY be configured to + propagate the NEXT_HOP attribute. In this case when advertising + a route that the speaker learned from one of its peers, the + NEXT_HOP attribute of the advertised route is exactly the same + as the NEXT_HOP attribute of the learned route (the speaker just + doesn't modify the NEXT_HOP attribute) + + RFC2119: MAY + + Alcatel Y/N/O/Comments: O + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.56. Third Party NEXT_HOP + + Functionality/Description: MUST be able to support disabling it + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.58. NEXT_HOP + + Functionality/Description: A BGP speaker SHALL NOT install a + route with itself as the next hop + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.59. NEXT_HOP + + Functionality/Description: Used to determine the actual outbound + interface and immediate next-hop address that SHOULD be used to + forward transit packets to the associated destinations + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.12.61. Resolved NEXT_HOP IP Address + + Functionality/Description: If the entry also specifies the + next-hop address, this address SHOULD be used as the immediate + next-hop address for packet forwarding + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC4271] + + 3.13.62. Preferred Metric + + Functionality/Description: Lowest value + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.13.64. MULTI_EXIT_DISC + + Functionality/Description: If received from a neighboring AS, it + MUST NOT be propagated to other neighboring ASes + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.13.65. Remove MULTI_EXIT_DISC + + Functionality/Description: Local configuration mechanism to + remove the attribute from a route + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.13.67. MULTI_EXIT_DISC Alteration + + Functionality/Description: An implementation MAY also (based on + local configuration) alter the value of the MULTI_EXIT_DISC + attribute received over EBGP + + RFC2119: MAY + + Alcatel Y/N/O/Comments: O + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.13.68. MULTI_EXIT_DISC Alteration + + Functionality/Description: Done prior to determining the degree + of preference of the route and performing route selection + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +Hares & Retana Informational [Page 29] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.14. LOCAL_PREF / Section 5.1.5 [RFC4271] + + 3.14.69. LOCAL_PREF + + Functionality/Description: Included in all UPDATE messages that + a given BGP speaker sends to the other internal peers + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.14.70. Degree of Preference + + Functionality/Description: Calculated for each external route + based on the locally configured policy, and included when + advertising a route to its internal peers + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.14.71. LOCAL_PREF + + Functionality/Description: Higher degree of preference MUST be + preferred + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + [RFC3065] + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + 3.14.73. LOCAL_PREF + + Functionality/Description: Ignored if received from an external + peer, except for the case of BGP Confederations [RFC3065] + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC4271] + + 3.15.74. ATOMIC_AGGREGATE + + Functionality/Description: Included if an aggregate excludes at + least some of the AS numbers present in the AS_PATH of the + routes that are aggregated as a result of dropping the AS_SET + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.15.76. Received ATOMIC_AGGREGATE + + Functionality/Description: BGP speaker MUST NOT make any NLRI of + that route more specific (as defined in 9.1.4) + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.16. AGGREGATOR / Section 5.1.7 [RFC4271] + + 3.16.77. AGGREGATOR + + Functionality/Description: Included in updates which are formed + by aggregation (see Section 9.2.2.2) + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.16.79. AGGREGATOR + + Functionality/Description: Contain local AS number and IP + address + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y Default behavior. Can be configured + different from BGP ID. + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.16.80. AGGREGATOR IP Address + + Functionality/Description: The same as the BGP Identifier of the + speaker + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +Hares & Retana Informational [Page 33] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.17. BGP Error Handling / Section 6 [RFC4271] + + 3.17.81. Error Handling + + Functionality/Description: Is your implementation compatible + with the error handling procedures described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.17.82. Error Subcode + + Functionality/Description: Zero, if it is not specified + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.18. Message Header Error Handling / Section 6.1 [RFC4271] + + 3.18.83. Message Header Errors + + Functionality/Description: Indicated by sending the NOTIFICATION + message with Error Code Message Header Error + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.18.85. Message Length + + Functionality/Description: Use the Bad Message Length Error + Subcode to indicate an incorrect message length + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.18.86. Bad Message Length + + Functionality/Description: The Data field MUST contain the + erroneous Length field + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.18.88. Bad Message Type + + Functionality/Description: The Data field MUST contain the + erroneous Type field + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.19. OPEN Message Error Handling / Section 6.2 [RFC4271] + + 3.19.89. OPEN Message Errors + + Functionality/Description: Indicated by sending the NOTIFICATION + message with Error Code OPEN Message Error + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.19.91. Unacceptable Autonomous System Field + + Functionality/Description: The Error Subcode MUST be set to Bad + Peer AS + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.19.92. Unacceptable Hold Time Error Subcode + + Functionality/Description: Used if the Hold Time field of the + OPEN message is unacceptable + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.19.94. Hold Time Rejection + + Functionality/Description: An implementation may reject any + proposed Hold Time + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: Y + + + 3.19.95. Hold Time + + Functionality/Description: If accepted, then the negotiated + value MUST be used + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.19.97. Not Recognized Optional Parameters + + Functionality/Description: The Error Subcode MUST be set to + Unsupported Optional Parameters + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We may fix this. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.19.98. Recognized but Malformed Optional Parameters + + Functionality/Description: The Error Subcode MUST be set to 0 + (Unspecific) + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +Hares & Retana Informational [Page 39] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.20. UPDATE Message Error Handling / Section 6.3 [RFC4271] + + 3.20.99. UPDATE Message Errors + + Functionality/Description: Indicated by sending the + NOTIFICATION message with Error Code UPDATE Message Error + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.100. Too Large + + Functionality/Description: If the Withdrawn Routes Length or + Total Attribute Length is too large, then the Error Subcode MUST + be set to Malformed Attribute List + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.101. Conflicting Flags + + Functionality/Description: If any recognized attribute has + Attribute Flags that conflict with the Attribute Type Code, then + the Error Subcode MUST be set to Attribute Flags Error + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.103. Conflicting Length + + Functionality/Description: If any recognized attribute has + Attribute Length that conflicts with the expected length, then + the Error Subcode MUST be set to Attribute Length Error + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.104. Conflicting Length + + Functionality/Description: The Data field MUST contain the + erroneous attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.106. Missing Mandatory Well-Known Attributes + + Functionality/Description: The Data field MUST contain the + Attribute Type Code of the missing well-known attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We plan to fix this in future. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + 3.20.107. Unrecognized Mandatory Well-Known Attributes + + Functionality/Description: The Error Subcode MUST be set to + Unrecognized Well-known Attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We set error subcode to Attribute + Flags Error, but we intend to + correct this soon. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.109. Undefined ORIGIN + + Functionality/Description: The Error Sub-code MUST be set to + Invalid Origin Attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.110. Undefined ORIGIN + + Functionality/Description: The Data field MUST contain the + unrecognized attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N Ignores the prefix in case of + martian nexthop, and in case of + length not equal to IPv4 + address-length, we send + NOTIFICATION with error subcode + Attribute Length error. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.112. Syntactically Incorrect NEXT_HOP + + Functionality/Description: The Data field MUST contain the + incorrect attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.113. NEXT_HOP Semantic Correctness + + Functionality/Description: NEXT_HOP is checked for semantic + correctness against the criteria in this section + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + +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 + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.115. NEXT_HOP Semantic Correctness + + Functionality/Description: In the case of an EBGP where the + sender and receiver are one IP hop away from each other, either + the IP address in the NEXT_HOP MUST be the sender's IP address + (that is used to establish the BGP connection), or the interface + associated with the NEXT_HOP IP address MUST share a common + subnet with the receiving BGP speaker + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.116. Semantically Incorrect NEXT_HOP + + Functionality/Description: Error logged + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +Hares & Retana Informational [Page 45] + +RFC 4276 BGP-4 Implementation Report January 2006 + + + 3.20.117. Semantically Incorrect NEXT_HOP + + Functionality/Description: Route Ignored + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: Y + + + 3.20.118. Semantically Incorrect NEXT_HOP + + Functionality/Description: NOTIFICATION not sent + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.119. Semantically Incorrect NEXT_HOP + + Functionality/Description: Connection not closed + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.120. Syntactically Incorrect AS_PATH + + Functionality/Description: The Error Subcode MUST be set to + Malformed AS_PATH + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: Y + + + 3.20.122. First Neighbor in AS_PATH Check + + Functionality/Description: If the check determines that this is + not the case, the Error Subcode MUST be set to Malformed AS_PATH + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + 3.20.123. Optional Attributes + + Functionality/Description: Value MUST be checked if the + attribute is recognized + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.125. Optional Attribute Error + + Functionality/Description: The Error Subcode MUST be set to + Optional Attribute Error + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N What exactly is optional attribute + e.g., If error is flag related, we + send update flag error subcode, if it + is length related, we send update + length error subcode. These granular + subcodes are better in terms of + debugging than optional attribute + error. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y Only optional attribute error that + doesn't have a more specific error, + is the version 3 to version 4 error + for the atomic aggregate. All others + default to more specific error codes + if implementation. + + + 3.20.126. Optional Attribute Error + + Functionality/Description: The Data field MUST contain the + attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.128. Syntactically Incorrect NLRI Field + + Functionality/Description: The Error Subcode MUST be set to + Invalid Network Field + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.129. Semantically Incorrect NLRI Field + + Functionality/Description: An error SHOULD be logged locally + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.20.131. UPDATE with no NLRI + + Functionality/Description: An UPDATE message that contains + correct path attributes, but no NLRI, SHALL be treated as a + valid UPDATE message + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.21. NOTIFICATION Message Error Handling / Section 6.4 [RFC4271] + + 3.21.132. Error in NOTIFICATION Message + + Functionality/Description: Noticed, logged locally, and brought + to the attention of the administration of the peer + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +Hares & Retana Informational [Page 50] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.22. Hold Timer Expired Error Handling / Section 6.5 [RFC4271] + + 3.22.133. Hold Timer Expired + + Functionality/Description: Is your implementation compatible + with the error handling procedures described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.23. Finite State Machine Error Handling / Section 6.6 [RFC4271] + + 3.23.134. Finite State Machine Errors + + Functionality/Description: Is your implementation compatible + with the error handling procedures described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.24. Cease / Section 6.7 [RFC4271] + + 3.24.135. Cease NOTIFICATION + + Functionality/Description: Used in absence of any fatal errors + if a BGP peer chooses at any given time to close its BGP + connection + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We close the TCP session without + CEASE NOTIFICATION. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + +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 + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.24.137. Upper bound on the number of address prefixes the speaker + is willing to accept from a neighbor + + Functionality/Description: Support by local configuration + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.24.138. Upper bound on the number of address prefixes the speaker + is willing to accept from a neighbor + + Functionality/Description: If exceeded and the BGP speaker + decides to terminate its BGP connection, the Cease NOTIFICATION + MUST be used + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We don't send CEASE but we plan to + correct that soon. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y No termination of peers is supported + We are considering support with the + maximum prefix document for later + releases. + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.25. BGP Connection Collision Detection / Section 6.8 [RFC4271] + + 3.25.140. Connection Collision + + Functionality/Description: One of the connections MUST be closed + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.25.141. Receipt of an OPEN Message + + Functionality/Description: The local system MUST examine all of + its connections that are in the OpenConfirm state + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: O We detect collision through some + other implementation specific way + and resolve by method specified in + the document. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.26. BGP Version Negotiation / Section 7 [RFC4271] + + 3.26.143. Version Negotiation + + Functionality/Description: Multiple attempts to open a BGP + connection, starting with the highest version number each + supports + + RFC2119: MAY + + Alcatel Y/N/O/Comments: N Supports only version 4 + Cisco Y/N/O/Comments: O We resolve it through config. If + Config is for version 3, and we get + version 4, OPEN will always fail. + Similarly, if configed (default) is + version 4 and peers configured is 3, + we don't try to negotiate version 3 + unless we have configured it. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: N Supports only version 4. + + + 3.26.144. Future Versions of BGP + + Functionality/Description: MUST retain the format of the OPEN + and NOTIFICATION messages + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + +Hares & Retana Informational [Page 54] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.27. BGP Finite State Machine (FSM) / Section 8 [RFC4271] + + 3.27.145. FSM + + Functionality/Description: Is your implementation compatible + with the conceptual FSM described in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.28. Administrative Events / Section 8.1.2 [RFC4271] + + 3.28.146. Optional Session Attribute Settings + + Functionality/Description: Each event has an indication of what + optional session attributes SHOULD be set at each stage + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: O Its rather vague. We have an option + Of manually starting or stopping + sessions but not an option for all + optional session attributes that are + listed in the document. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y The following optional attributes + are implied in this implementation: + 1) Automatic start, 2) Automatic + Stop, 3) + + + 3.28.147. Event1: ManualStart + + Functionality/Description: The PassiveTcpEstablishment attribute + SHOULD be set to FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.149. Event3: AutomaticStart + + Functionality/Description: The PassiveTcpEstablishment optional + session attribute SHOULD be set to FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.150. Event3: AutomaticStart + + Functionality/Description: DampPeerOscillations SHOULD be set to + FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations + attribute, so it is always FALSE. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y We wait for some fixed time before + initiating OPEN. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.152. Event4: ManualStart_with_PassiveTcpEstablishment + + Functionality/Description: The DampPeerOscillations attribute + SHOULD be set to FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations + attribute so it is FALSE. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O We don't support DampPeerOscilation + attribute with a setting of off, and + hence Event 4. Future version will + support Event 4 + + + 3.28.153. Event5: AutomaticStart_with_PassiveTcpEstablishment + + Functionality/Description: The AllowAutomaticStart attribute + SHOULD be set to TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.155. Event5: AutomaticStart_with_PassiveTcpEstablishment + + Functionality/Description: The DampPeerOscillations SHOULD be + set to FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations + attribute, so always FALSE. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O We don't support DampPeerOscilation + attribute with a setting of off, and + hence Event 5. Future version will + support Event 5 + + + 3.28.156. Event6: AutomaticStart_with_DampPeerOscillations + + Functionality/Description: The AllowAutomaticStart attribute + SHOULD be set to TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute. + Laurel Y/N/O/Comments: Y + + NextHop Y/N/O/Comments: Y + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: N Don't support DampPeerOscillations + attribute. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.158. Event6: AutomaticStart_with_DampPeerOscillations + + Functionality/Description: The PassiveTcpEstablishment attribute + SHOULD be set to FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute and hence Event6. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.159. Event7: + AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment + + Functionality/Description: The AllowAutomaticStart attribute + SHOULD be set to TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute and hence Event7 + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute and hence Event7 + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.161. Event7: + AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment + + Functionality/Description: The PassiveTcpEstablishment attribute + SHOULD be set to TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute and hence Event7 + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.28.162. Event8: AutomaticStop + + Functionality/Description: The AllowAutomaticStop attribute + SHOULD be TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +Hares & Retana Informational [Page 60] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.29. Timer Events / Section 8.1.3 [RFC4271] + + 3.29.163. Event12: DelayOpenTimer_Expires + + Functionality/Description: DelayOpen attribute SHOULD be set to + TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + 3.29.164. Event12: DelayOpenTimer_Expires + + Functionality/Description: DelayOpenTime attribute SHOULD be + supported + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + 3.29.165. Event12: DelayOpenTimer_Expires + + Functionality/Description: DelayOpenTimer SHOULD be supported + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute and hence Event13 + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.29.167. Event13: IdleHoldTimer_Expires + + Functionality/Description: IdleHoldTimer SHOULD have just + expired + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O Don't support DampPeerOscillations + attribute and hence Event13 + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.30. TCP Connection-Based Events / Section 8.1.4 [RFC4271] + + 3.30.168. Event14: TcpConnection_Valid + + Functionality/Description: BGP's destination port SHOULD be port + 179 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O GateD NGC 2.0 provides hooks for + the TCP state tracking, but use of + this option depends OS support. + Future versions will have additional + hooks. + + + 3.30.170. Event15: Tcp_CR_Invalid + + Functionality/Description: BGP destination port number SHOULD be + 179 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O GateD NGC 2.0 provides hooks for + the TCP state tracking, but use of + this option depends OS support. + Future versions will have additional + hooks. + + +3.31. BGP Messages-Based Events / Section 8.1.5 [RFC4271] + + 3.31.171. Event19: BGPOpen + + Functionality/Description: The DelayOpen optional attribute + SHOULD be set to FALSE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.31.173. Event20: BGPOpen with DelayOpenTimer Running + + Functionality/Description: The DelayOpen attribute SHOULD be set + to TRUE + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N Not applicable + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + 3.31.174. Event20: BGPOpen with DelayOpenTimer Running + + Functionality/Description: The DelayOpenTimer SHOULD be running + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: n/a + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y Collision detection event is logged. + Cisco Y/N/O/Comments: O We always detect collision before we + go to established state. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O GateD NGC 2.0 does not support + Collision Detection in Established + state. This option attribute is + always set to FALSE. + + +3.32. FSM Definition / Section 8.2.1 [RFC4271] + + 3.32.176. FSM + + Functionality/Description: Separate FSM for each configured peer + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.32.177. TCP Port 179 + + + Functionality/Description: A BGP implementation MUST connect to + and listen on TCP port 179 for incoming connections in addition + to trying to connect to peers + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC4271] + + 3.33.179. Connection Collision + + Functionality/Description: The corresponding FSM for the + connection that is closed SHOULD be disposed of + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.34. FSM Event numbers / Section 8.2.1.4 [RFC4271] + + 3.34.180. Event Numbers + + Functionality/Description: Used to provide network management + information + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y Not visible to operator. + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: N Future Release of GateD NGC may + support event numbers. + + + + + + + + + + +Hares & Retana Informational [Page 66] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.35. Finite State Machine / Section 8.2.2 [RFC4271] + + 3.35.181. ConnectRetryTimer + + Functionality/Description: Sufficiently large to allow TCP + initialization + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.35.182. Second Connection Tracking + + Functionality/Description: In response to a TCP connection + succeeds [Event 16 or Event 17], the 2nd connection SHALL be + tracked until it sends an OPEN message + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.36. UPDATE Message Handling / Section 9 [RFC4271] + + 3.36.183. UPDATE Message Handling + + Functionality/Description: Does your implementation handle + UPDATE messages in a manner compatible to the description in + this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + +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 + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.36.185. WITHDRAWN ROUTES + + Functionality/Description: The BGP speaker SHALL run its + Decision Process since the previously advertised route is no + longer available for use + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.36.186. Implicit Withdraw + + Functionality/Description: If an UPDATE message contains a + feasible route, and the NLRI of the new route is identical to + the one of a route currently stored in the Adj-RIB-In, then the + new route SHALL replace the older route + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.36.188. Adj-RIB-In Update + + Functionality/Description: Once a BGP speaker updates the + Adj-RIB-In, it SHALL run its Decision Process + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.37. Decision Process / Section 9.1 [RFC4271] + + 3.37.189. Decision Process + + Functionality/Description: Is your implementation compatible + with the description in this section? + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.38. Phase 1: Calculation of Degree of Preference / Section 9.1.1 + [RFC4271] + + 3.38.191. Ineligible Degree of Preference + + Functionality/Description: The route MAY NOT serve as an input + to the next phase of route selection + + RFC2119: MAY NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.38.192. Eligible Degree of Preference + + Functionality/Description: Used as the LOCAL_PREF value in any + IBGP re-advertisement + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +Hares & Retana Informational [Page 70] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.39. Phase 2: Route Selection / Section 9.1.2 [RFC4271] + + 3.39.193. Unresolvable NEXT_HOP + + Functionality/Description: If the NEXT_HOP attribute of a BGP + route depicts an address that is not resolvable, or it would + become unresolvable if the route was installed in the routing + table the BGP route MUST be excluded + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.39.194. Routes Installed in LOC-RIB + + Functionality/Description: The route in the Adj-RIBs-In + identified as the best (see section 9.1.2) is installed in the + Loc-RIB, replacing any route to the same destination that is + currently being held in the Loc-RIB + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.39.195. Immediate Next-Hop Address + + Functionality/Description: MUST be determined from the NEXT_HOP + attribute of the selected route (see Section 5.1.3) + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.39.197. Immediate Next-Hop Address + + + Functionality/Description: Used for packet forwarding + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.39.198. Unresolvable Routes + + Functionality/Description: Removed from the Loc-RIB and the + routing table + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.40. Route Resolvability Condition / Section 9.1.2.1 [RFC4271] + + 3.40.200. Unresolvable Routes + + Functionality/Description: Excluded from the Phase 2 decision + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.40.201. Multiple Matching Routes + + Functionality/Description: Only the longest matching route + SHOULD be considered + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: O We have checks that disallow mutual + recursion, so this won't happen. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271] + + 3.41.203. Tie-Breaking Criteria + + Functionality/Description: Applied in the order specified + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.41.204. Algorithm Used + + Functionality/Description: BGP implementations MAY use any + algorithm which produces the same results as those described + here + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.41.206. MULTI_EXIT_DISC Removal + + Functionality/Description: The optional comparison on + MULTI_EXIT_DISC if performed at all MUST be performed only among + EBGP learned routes + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.41.207. MULTI_EXIT_DISC Comparison + + Functionality/Description: Performed for IBGP learned routes + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +Hares & Retana Informational [Page 75] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC4271] + + 3.42.208. Policy for processing routes from the Loc-RIB into + Adj-RIBs-Out + + Functionality/Description: Exclude a route in the Loc-RIB from + being installed in a particular Adj-RIB-Out + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.42.209. Adj-Rib-Out Route Installation + + Functionality/Description: Not unless the destination and + NEXT_HOP described by this route may be forwarded appropriately + by the Routing Table + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.42.210. Withdraw Routes + + Functionality/Description: If a route in Loc-RIB is excluded + from a particular Adj-RIB-Out the previously advertised route in + that Adj-RIB-Out MUST be withdrawn from service by means of an + UPDATE message (see 9.2) + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + +Hares & Retana Informational [Page 76] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.43. Overlapping Routes / Section 9.1.4 [RFC4271] + + 3.43.211. Overlapping Routes + + Functionality/Description: Consider both routes based on the + configured acceptance policy + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.43.212. Accepted Overlapping Routes + + Functionality/Description: The Decision Process MUST either + install both routes or... + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.43.213. Accepted Overlapping Routes + + Functionality/Description: Aggregate the two routes and install + the aggregated route, provided that both routes have the same + value of the NEXT_HOP attribute + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We install both in Local RIB. + Laurel Y/N/O/Comments: N no automatic aggregation + NextHop Y/N/O/Comments: N no automatic aggregation + + + + + + + + + + + +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 + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.43.215. De-Aggregation + + Functionality/Description: Routes SHOULD NOT be de-aggregated + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.43.216. Route with the ATOMIC_AGGREGATE Attribute + + Functionality/Description: Not de-aggregated + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + + +Hares & Retana Informational [Page 78] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.44. Update-Send Process / Section 9.2 [RFC4271] + + 3.44.217. UPDATE Message Received from an Internal Peer + + Functionality/Description: Not re-distribute the routing + information to other internal peers, unless the speaker acts as + a BGP Route Reflector [RFC2796] + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.44.218. No Replacement Route + + Functionality/Description: All newly installed routes and all + newly unfeasible routes for which there is no replacement route + SHALL be advertised to its peers by means of an UPDATE message + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.44.219. Previously Advertised Routes + + Functionality/Description: A BGP speaker SHOULD NOT advertise a + given feasible BGP route if it would produce an UPDATE message + containing the same BGP route as was previously advertised + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + +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 + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.44.221. Changes to Reachable Destinations + + Functionality/Description: Changes to the reachable destinations + within its own autonomous system SHALL also be advertised in an + UPDATE message + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.44.222. A single route doesn't fit into the UPDATE message + + Functionality/Description: Don't advertise + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.44.223. A single route doesn't fit into the UPDATE message + + Functionality/Description: Log an error local + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + +Hares & Retana Informational [Page 80] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC4271] + + 3.45.224. MinRouteAdvertisementIntervalTimer + + Functionality/Description: Minimum separation between two UPDATE + messages sent by a BGP speaker to a peer that advertise feasible + routes and/or withdrawal of unfeasible routes to some common set + of destinations + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.45.225. Fast Convergence + + Functionality/Description: MinRouteAdvertisementIntervalTimer + used for internal peers SHOULD be shorter than the + MinRouteAdvertisementIntervalTimer used for external peers, or + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: O Configurable on per peer basis. + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: N they are same for ebgp and ibgp + NextHop Y/N/O/Comments: Y Configuration option allows to set + the time per peer. + + + 3.45.226. Fast Convergence + + Functionality/Description: The procedure describes in this + section SHOULD NOT apply for routes sent to internal peers + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: O Operator has to ensure that through + configuration. + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: Y Default setting is off for BGP + peers. + + + + + + +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 + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.46. Aggregating Routing Information / Section 9.2.2.2 [RFC4271] + + 3.46.228. MULTI_EXIT_DISC + + Functionality/Description: Routes that have different + MULTI_EXIT_DISC attribute SHALL NOT be aggregated + + RFC2119: SHALL NOT + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: Y + + + 3.46.229. AS_SET as the First Element + + Functionality/Description: If the aggregated route has an AS_SET + as the first element in its AS_PATH attribute, then the router + that originates the route SHOULD NOT advertise the + MULTI_EXIT_DISC attribute with this route + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + +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 + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.231. ORIGIN INCOMPLETE + + Functionality/Description: Used if at least one route among + routes that are aggregated has ORIGIN with the value INCOMPLETE + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.232. ORIGIN EGP + + Functionality/Description: Used if at least one route among + routes that are aggregated has ORIGIN with the value EGP + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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: ... + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.234. Routes to be aggregated have different AS_PATH attributes + + Functionality/Description: All tuples of type AS_SEQUENCE in the + aggregated AS_PATH SHALL appear in all of the AS_PATH in the + initial set of routes to be aggregated + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.235. Routes to be aggregated have different AS_PATH attributes + + Functionality/Description: All tuples of type AS_SET in the + aggregated AS_PATH SHALL appear in at least one of the AS_PATH + in the initial set + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + +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 + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.237. Routes to be aggregated have different AS_PATH attributes + + Functionality/Description: No tuple of type AS_SET with the same + value SHALL appear more than once in the aggregated AS_PATH + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.238. Routes to be aggregated have different AS_PATH attributes + + Functionality/Description: Multiple tuples of type AS_SEQUENCE + with the same value may appear in the aggregated AS_PATH only + when adjacent to another tuple of the same type and value + + RFC2119: N/A + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: Y + + + + + + + + + + + +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. + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N We don't do merging. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.240. ATOMIC_AGGREGATE + + Functionality/Description: The aggregated route SHALL have this + attribute if at least one of the routes to be aggregated has it + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.46.241. AGGREGATOR + + Functionality/Description: Attribute from routes to be + aggregated MUST NOT be included in aggregated route + + RFC2119: MUST NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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) + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.47. Route Selection Criteria / Section 9.3 [RFC4271] + + 3.47.243. Unstable Routes + + Functionality/Description: Avoid using them + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.47.244. Route Changes + + Functionality/Description: SHOULD NOT make rapid spontaneous + changes to the choice of route + + RFC2119: SHOULD NOT + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +Hares & Retana Informational [Page 87] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.48. Originating BGP Routes / Section 9.4 [RFC4271] + + 3.48.245. Non-BGP Acquired Routes + + Functionality/Description: Distributed to other BGP speakers + within the local AS as part of the update process + (see Section 9.2) + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.48.246. Non-BGP Acquired Routes + + Functionality/Description: Distribution controlled via + configuration + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + +3.49. BGP Timers / Section 10 [RFC4271] + + 3.49.247. Optional Timers + + Functionality/Description: Two optional timers MAY be supported: + DelayOpenTimer, IdleHoldTimer by BGP + + RFC2119: MAY + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: O We support DelayOpenTimer but not + IdleHoldTimer + Laurel Y/N/O/Comments: Y support IdleHoldTimer but not the + DelayOpenTimer + NextHop Y/N/O/Comments: Y + + + + + + + +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 + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.49.249. Timers + + Functionality/Description: Allow the other timers to be + configurable + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + 3.49.250. Jitter + + Functionality/Description: Applied to the timers associated with + MinASOriginationInterval, KeepAlive, + MinRouteAdvertisementInterval, and ConnectRetry + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: O We only apply to ConnectRetry. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + + +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 + + RFC2119: MAY + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y We apply same only for connectretry. + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + 3.49.252. Default Amount of jitter + + Functionality/Description: Determined by multiplying the base + value of the appropriate timer by a random factor which is + uniformly distributed in the range from 0.75 to 1.0 + + RFC2119: SHALL + + Alcatel Y/N/O/Comments: Y Range is 0.9 to 1.1 + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + 3.49.253. Default Amount of jitter + + Functionality/Description: New random value picked each time the + timer is set + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + + + + + + + +Hares & Retana Informational [Page 90] + +RFC 4276 BGP-4 Implementation Report January 2006 + + + 3.49.254. Jitter Random Value Range + + Functionality/Description: Configurable + + RFC2119: MAY + + Alcatel Y/N/O/Comments: N + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: N + + +3.50. TCP Options that May Be Used with BGP / Appendix E [RFC4271] + + 3.50.255. TCP PUSH Function Supported + + Functionality/Description: Each BGP message SHOULD be + transmitted with PUSH flag set + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O Depends on the TCP stack support. + GateD 10, NGC can run over + multiple stacks. + + + 3.50.256. Differentiated Services Code Point (DSCP) Field Support + + Functionality/Description: TCP connections opened with bits 0-2 + of the DSCP field set to 110 (binary) + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: O Depends on the TCP stack support. + GateD 10, NGC can run over + multiple stacks. + + + + + + + + + +Hares & Retana Informational [Page 91] + +RFC 4276 BGP-4 Implementation Report January 2006 + + +3.51. Reducing Route Flapping / Appendix F.2 [RFC4271] + + 3.51.257. Avoid Excessive Route Flapping + + Functionality/Description: A BGP speaker which needs to withdraw + a destination and send an update about a more specific or less + specific route SHOULD combine them into the same UPDATE message + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: N + + +3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC4271] + + 3.52.258. Multiple Instances in AS_PATH + + Functionality/Description: The last instance (rightmost + occurrence) of that AS number is kept + + RFC2119: SHOULD + + Alcatel Y/N/O/Comments: N We use algorithm in 9.2.2.2 + Cisco Y/N/O/Comments: N + Laurel Y/N/O/Comments: N + NextHop Y/N/O/Comments: N + + +3.53. Security Considerations [RFC4271] + + 3.53.259. Authentication Mechanism + + Functionality/Description: A BGP implementation MUST support + the authentication mechanism specified in RFC 2385 [RFC2385]. + + RFC2119: MUST + + Alcatel Y/N/O/Comments: Y + Cisco Y/N/O/Comments: Y + Laurel Y/N/O/Comments: Y + NextHop Y/N/O/Comments: Y + + + + + + + +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 [RFC4271]. + + 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 + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- + 4)", RFC 1771, March 1995. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 + Signature Option", RFC 2385, August 1998. + + + + +Hares & Retana Informational [Page 95] + +RFC 4276 BGP-4 Implementation Report January 2006 + + + [RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection + - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. + + [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, + September 2000. + + [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous + System Confederations for BGP", RFC 3065, February 2001. + +7. Acknowledgements + + Alcatel responses provided by: + Contact Name: Devendra Raut + Contact EMail: 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 (C) 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] + |