GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4276

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4276.txt · Last modified: 2006/01/12 22:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki