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]

mirror server hosted at Truenetwork, Russian Federation.