Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4276

BGP-4 Implementation Report

Pages: 97
Informational
Part 1 of 4 – Pages 1 to 7
None   None   Next

Top   ToC   RFC4276 - Page 1
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
Top   ToC   RFC4276 - Page 2
      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
Top   ToC   RFC4276 - Page 3
      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.
Top   ToC   RFC4276 - Page 4
   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.)
Top   ToC   RFC4276 - Page 5
      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
Top   ToC   RFC4276 - Page 6
      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
Top   ToC   RFC4276 - Page 7

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


(page 7 continued on part 2)

Next Section