[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 4276

   Interdomain Working Group
   Internet Draft                                         S. Hares
   Document: draft-ietf-idr-bgp-implementation-01.txt      NextHop
                                                         A. Retana
                                                             Cisco
   Expires: August 2004                                  July 2004


                        BGP 4 Implementation Report


Status of this Memo


     By submitting this Internet-Draft, we certify that any applicable
     patent or other IPR claims of which we are aware have been
     disclosed, or will be disclosed, and any of which we become aware
     will be disclosed, in accordance with RFC 3668.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress".

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt .

     This document may not be modified, and derivative works of it may
     not be created, except to publish it as an RFC and to translate it
     into languages other than English.

Abstract

   This document provides a survey of the BGP-4 implementation draft-
   ietf-idr-bgp4-24.txt.  After a brief summary, each response is
   listed. The editor makes no claim as to the accuracy of the
   information provided.



Conventions used in this document





Hares & RetanaExpires - November !Undefined Bookmark, SAVEDATE[Page 1]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

   TABLE of CONTENTS


   1. Introduction...................................................3
   2. Results of Survey..............................................4
      2.1 Differences................................................5
      2.2 Implementations and interoperability.......................6
      2.3 BGP Implementation Identification..........................7
   3. BGP4 Implementation Report.....................................7
      2.0 Summary of Operation / Section 3...........................7
      3.1 Routes: Advertisement and Storage / Section 3.1............8
      3.2 Routing Information Bases / Section 3.2....................9
      3.3 Message Formats / Section 4................................9
      3.4 Message Header Format / Section 4.1........................9
      3.5 OPEN Message / Section 4.2................................11
      3.6 UPDATE Message Format / Section 4.3.......................11
      3.7 KEEPALIVE Message Format / Section 4.4....................15
      3.8 NOTIFICATION Message Format / Section 4.5.................15
      3.9 Path Attributes /Section 5................................16
      3.10 ORIGIN / Section 5.1.1...................................19
      3.11 AS_PATH / Section 5.1.2..................................20
      3.12 NEXT_HOP / Section 5.1.3.................................21
      3.13 MULTI_EXIT_DISC / Section 5.1.4..........................24
      3.14 LOCAL_PREF / Section 5.1.5...............................26
      3.15 ATOMIC_AGGREGATE / Section 5.1.6.........................28
      3.16 AGGREGATOR / Section 5.1.7...............................29
      3.17 BGP Error Handling / Section 6...........................30
      3.18 Message Header Error Handling / Section 6.1..............30
      3.19 OPEN message error handling / Section 6.2................32
      3.20 UPDATE message error handling / Section 6.3..............35
      3.21 NOTIFICATION message error handling / Section 6.4........44
      3.22 Hold Timer Expired error handling / Section 6.5..........44
      3.23 Finite State Machine error handling / Section 6.6........45
      3.24 Cease / Section 6.7......................................45
      3.25 BGP connection collision detection / Section 6.8.........46
      3.26 BGP Version Negotiation / Section 7......................47
      3.27 BGP Finite State machine (FSM) / Section 8...............48
      3.28 Administrative Events / Section 8.1.2....................48
      3.29 Timer Events / Section 8.1.3.............................53
      3.30 TCP Connection based Events / Section 8.1.4..............55
      3.31 BGP Messages based Events / Seciton 8.1.5................56
      3.32 FSM Definition / Section 8.2.1...........................57
      3.33 FSM and collision detection / Section 8.2.1.2............58
      3.34 FSM Event numbers / Section 8.2.1.4......................58
      3.35 Finite State Machine / Section 8.2.2.....................59


Hares & Retana          Expires - January 2005                [Page 2]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


      3.36 UPDATE Message Handling / Section 9......................59
      3.37 Decision Process / Section 9.1...........................61
      3.38 Phase 1: Calculation of Degree of Preference / Section 9.1.1
      ..............................................................62
      3.39 Phase 2: Route Selection / Section 9.1.2.................62
      3.40 Route Resolvability Condition / Section 9.1.2.1..........64
      3.41 Breaking Ties (Phase 2) / Section 9.1.2.2................65
      3.42 Phase 3: Route Dissemination / Section 9.1.3.............66
      3.43 Overlapping Routes / Section 9.1.4.......................67
      3.44 Update-Send Process / Section 9.2........................69
      3.45 Frequency of Route Advertisement / Section 9.2.1.1.......71
      3.46 Aggregating Routing Information / Section 9.2.2.2........72
      3.47 Route Selection Criteria / Section 9.3...................76
      3.48 Originating BGP routes / Section 9.4.....................77
      3.49 BGP Timers / Section 10..................................77
      3.50 TCP options that may be used with BGP / Appendix E.......80
      3.51 Reducing route flapping / Appendix F.2...................80
      3.52 Complex AS_PATH aggregation / Appendix F.6...............81
      3.53 Security Considerations..................................81
   4. Additional BGP implementations Information....................81
      4.1 Avici.....................................................81
      4.2 Data Connection Ltd.......................................82
      4.3 Nokia BGP.................................................83
   Security Considerations..........................................84
   Normative References.............................................84
   Acknowledgments..................................................85
   Authors' Addresses...............................................85
   Copyright Statement..............................................86



1. Introduction

    This revision of the BGP-4 standard [BGP4] updates the BGP standard
    [RFC1771] to be in alignment with the deployments of the BGP-4
    protocols.   BGP-4 as deployed in the Internet encompasses both this
    base specification and additional specifications such as TCP MD5
    [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations
    [RFC3065], and BGP Route Refresh [RFC 2918].

    BGP as a widely deployed cornerstone of Internet technology
    continues to add additional functionality as the needs within the
    Internet requires. This survey has 259 detailed questions on the
    compliance with the revised standard.  4 implementers (Alcatel,
    Cisco, Laurel, NextHop) sent in implementation reports.  Section 2
    provides a compilation of those results.

    Section 1.3 provides the quick survey results on inter-operability.
    Section 1.4 provides an inter-operability of the 4 implementations.


Hares & Retana          Expires - January 2005                [Page 3]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



    Due to the large number of BGP implementations and the small number
    of responses, the editors took an informal survey to determine if
    the length of survey was an issue.  Three implementers responded,
    and all indicated the length of the survey was the issue. Section 3
    gives this informal survey results.

    The editors have compiled the submitted survey results and the
    informal survey results.  We do not guarantee the accuracy of the
    responses.


2. Results of Survey

    Significant Differences

    For every item listed (259 questions), the respondents indicated
    whether their implementation supports the Functionality/Description
    or not (Y/N) indicated by the RFC2199 [RFC2119] language. Of the 259
    questions in the survey, had two implementations giving an
    affirmative response(two "y" or "y" and "O") except the following:


      a) Must - Linked questions 212/213, regarding section 9.1.4

         The linking of the questions lead to question 213 having three
         vendors (Cisco, Laurel, and NextHop) give a "no" as the second
         half of a question due to the format of the survey question.
         (See the next section for details).


      b) SHALL NOT - Question 228, regarding section 9.2.2.2

         Three vendors (Alcatel, Cisco, 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.

      c) SHOULD - 2 in appendix F (questions 257, 258)

         Three vendors said no, one vendor said yes to question 257.
         All four vendors indicated no to question 258. (Please note
         that Appendix F is text section for optional support.

       Text:   Section F.2 - A BGP speaker which needs to withdraw a
               destination and send an update about a more specific or



Hares & Retana          Expires - January 2005                [Page 4]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


               less specific route SHOULD combine them into the same
               UPDATE message.

       Text:   Section F.6: The last instance (rightmost occurrence) of
               that AS number is kept.


      d) MAY - 1 in section 8.1.2.4, 1 in Section 10 (question 254)


      Section 8: 3 "No", 1 yes

         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."


         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.


      Section 10: 3 "no"
          Three vendors answered "no" configurable jitter time values.
          One vendor indicated a configurable jitter timer value.

      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.

               Question: Is the jitter range configurable?



2.1 Differences

    The following section provides a list of sections where all answers
    were not "yes". This section is provided to allow the reader a short
    cut to the interesting points.

    Differences are found in Subsections:




Hares & Retana          Expires - January 2005                [Page 5]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


     MUST
     97, 106, 107, 111, 122, 125, 138, 141, 213

     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

         Question 213 about the aggregation of routes had 3 "N" and 1
         "Y".   Questions 212 and 213 are grouped together.

         Question 212 states:
            "The decision process MUST either install both routes" or
         Question 213:
            "Aggregate the two routes and install the aggregated route,
            provided that both routes have the same value of the
            NEXT_HOP attribute"

         The four respondents that said "Y" to question 212, said "N" to
         questions 213.  Given the context of the question, the "N" to
         question 213 is appropriate.


2.2 Implementations and interoperability

                    Alcatel Cisco Laurel NextHop
       Alcatel         Y     Y
       Cisco                 Y
       Laurel                Y      Y
       NextHop               Y             Y



Hares & Retana          Expires - January 2005                [Page 6]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004





2.3 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. BGP4 Implementation Report

   For every item listed, the respondents indicated whether their
   implementation supports the Functionality/Description or not (Y/N)
   according to the RFC2119 [2] 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 [BGP4]
   for additional details.



2.0 Summary of Operation / Section 3

   2.0.1 Base Behavior

   Functionality/Description: Is your implementation compatible with
   the base behavior described in this section?

       RFC2119: N/A



Hares & Retana          Expires - January 2005                [Page 7]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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

   2.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


   2.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          Expires - January 2005                [Page 8]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




3.2 Routing Information Bases / Section 3.2

   2.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


   2.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

   2.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


3.4 Message Header Format / Section 4.1

   2.4.8 Marker


Hares & Retana          Expires - January 2005                [Page 9]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 10]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




3.5 OPEN Message / Section 4.2

   2.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


   2.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


   2.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

   2.6.15 UPDATE

       Functionality/Description: Simultaneously advertise a feasible
       route and withdraw multiple unfeasible routes from service



Hares & Retana          Expires - January 2005               [Page 11]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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



Hares & Retana          Expires - January 2005               [Page 12]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



   2.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


   2.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


   2.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


   2.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.


Hares & Retana          Expires - January 2005               [Page 13]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.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          Expires - January 2005               [Page 14]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


3.7 KEEPALIVE Message Format / Section 4.4

   2.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


   2.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


   2.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


3.8 NOTIFICATION Message Format / Section 4.5

   2.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


Hares & Retana          Expires - January 2005               [Page 15]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


3.9 Path Attributes /Section 5

   2.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


   2.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


   2.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


   2.9.33/34 Discretionary Attributes

       Functionality/Description: Sent in a particular UPDATE message



Hares & Retana          Expires - January 2005               [Page 16]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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


   2.9.38 Partial Bit for unrecognized transitive optional attributes

       Functionality/Description: Set to 1 if the attribute is accepted


Hares & Retana          Expires - January 2005               [Page 17]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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


   2.9.42 Path Attributes


Hares & Retana          Expires - January 2005               [Page 18]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


3.10 ORIGIN / Section 5.1.1

   2.10.45 ORIGIN

       Functionality/Description: Value SHOULD NOT be changed by any
       speaker, except the originator

       RFC2119: SHOULD NOT


Hares & Retana          Expires - January 2005               [Page 19]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       Alcatel 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

   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 20]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




3.12 NEXT_HOP / Section 5.1.3

   2.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


   2.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


   2.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


   2.12.52 NEXT_HOP


Hares & Retana          Expires - January 2005               [Page 21]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


   2.12.55 NEXT_HOP Propagation

       Functionality/Description: The speaker MAY be configured to
       propagate the NEXT_HOP attribute. In this case when advertising


Hares & Retana          Expires - January 2005               [Page 22]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 23]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.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

   2.13.62 Preferred metric


Hares & Retana          Expires - January 2005               [Page 24]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


   2.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          Expires - January 2005               [Page 25]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




   2.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


   2.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


   2.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


3.14 LOCAL_PREF / Section 5.1.5

   2.14.69 LOCAL_PREF

       Functionality/Description: Included in all UPDATE messages that
       a given BGP speaker sends to the other internal peers



Hares & Retana          Expires - January 2005               [Page 26]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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




Hares & Retana          Expires - January 2005               [Page 27]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


   2.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

   2.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


   2.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


   2.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



Hares & Retana          Expires - January 2005               [Page 28]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Alcatel 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

   2.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


   2.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


   2.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


   2.16.80 AGGREGATOR IP Address


Hares & Retana          Expires - January 2005               [Page 29]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


3.17 BGP Error Handling / Section 6

   2.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


   2.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

   2.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


Hares & Retana          Expires - January 2005               [Page 30]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.18.86 Bad Message Length

       Functionality/Description: The Data field MUST contain the
       erroneous Lentgh 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


   2.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


Hares & Retana          Expires - January 2005               [Page 31]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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

   2.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


   2.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



Hares & Retana          Expires - January 2005               [Page 32]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



   2.19.91 Unnacceptable 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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 33]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.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


   2.19.98 Recognized but Malformed Optional Parameters

       Functionality/Description: The Error Subcode MUST be set to 0
       (Unspecific)

       RFC2119: MUST



Hares & Retana          Expires - January 2005               [Page 34]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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.20 UPDATE message error handling / Section 6.3

   2.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


   2.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


   2.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          Expires - January 2005               [Page 35]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


   2.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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 36]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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

   2.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


   2.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


   2.20.109 Undefined ORIGIN

       Functionality/Description: The Error Sub-code MUST be set to
       Invalid Origin Attribute



Hares & Retana          Expires - January 2005               [Page 37]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 38]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.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


   2.20.116 Semantically incorrect NEXT_HOP

       Functionality/Description: Error logged


Hares & Retana          Expires - January 2005               [Page 39]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


   2.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


   2.20.120 Syntactically Incorrect AS_PATH

       Functionality/Description: The Error Subcode MUST be set to
       Malformed AS_PATH


Hares & Retana          Expires - January 2005               [Page 40]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


   2.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          Expires - January 2005               [Page 41]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



   2.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


   2.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.


   2.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          Expires - January 2005               [Page 42]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




   2.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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 43]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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

   2.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


3.22 Hold Timer Expired error handling / Section 6.5

   2.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





Hares & Retana          Expires - January 2005               [Page 44]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


3.23 Finite State Machine error handling / Section 6.6

   2.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

   2.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


   2.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


   2.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



Hares & Retana          Expires - January 2005               [Page 45]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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 draft for later
                                    releases.


   2.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

   2.25.140 Connection Collision

       Functionality/Description: One of the connections MUST be closed

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y


Hares & Retana          Expires - January 2005               [Page 46]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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
                                    draft.
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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

   2.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.


Hares & Retana          Expires - January 2005               [Page 47]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


                                    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.


   2.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


3.27 BGP Finite State machine (FSM) / Section 8

   2.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

   2.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


Hares & Retana          Expires - January 2005               [Page 48]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


                                    optional session attributes that are
                                    listed in draft.
       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)


   2.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


   2.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


   2.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


   2.28.150 Event3: AutomaticStart


Hares & Retana          Expires - January 2005               [Page 49]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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


   2.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


   2.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


   2.28.153 Event5: AutomaticStart_with_PassiveTcpEstablishment

       Functionality/Description: The AllowAutomaticStart attribute
       SHOULD be set to TRUE



Hares & Retana          Expires - January 2005               [Page 50]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 51]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.28.159 Event 7:
   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


   2.28.160 Event 7:
   AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment



Hares & Retana          Expires - January 2005               [Page 52]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.28.161 Event 7:
   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


   2.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


3.29 Timer Events / Section 8.1.3

   2.29.163 Event12: DelayOpenTimer_Expires

       Functionality/Description: DelayOpen attribute SHOULD be set to
       TRUE

       RFC2119: SHOULD



Hares & Retana          Expires - January 2005               [Page 53]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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


   2.29.167 Event13: IdleHoldTimer_Expires

       Functionality/Description: IdleHoldTimer SHOULD have just
       expired


Hares & Retana          Expires - January 2005               [Page 54]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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

   2.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


   2.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.


   2.30.170 Event15: Tcp_CR_Invalid

       Functionality/Description: BGP destination port number SHOULD be
       179

       RFC2119: SHOULD



Hares & Retana          Expires - January 2005               [Page 55]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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 / Seciton 8.1.5

   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 56]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




   2.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


   2.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

   2.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


   2.32.177 TCP Port 179



Hares & Retana          Expires - January 2005               [Page 57]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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

   2.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

   2.34.180 Event Numbers

       Functionality/Description: Used to provide network management
       information

       RFC2119: MAY

       Alcatel Y/N/O/Comments: Y    Not visible to operator.


Hares & Retana          Expires - January 2005               [Page 58]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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.



3.35 Finite State Machine / Section 8.2.2

   2.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


   2.35.182 2nd 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

   2.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


Hares & Retana          Expires - January 2005               [Page 59]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.36.187 Other feasible routes

       Functionality/Description: If an UPDATE message contains a


Hares & Retana          Expires - January 2005               [Page 60]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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

   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 61]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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

   2.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


   2.38.192 Eligible degree of preference

       Functionality/Description: Used as the LOCAL_PREF value in any
       IBGP readvertisement

       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 Phase 2: Route Selection / Section 9.1.2

   2.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



Hares & Retana          Expires - January 2005               [Page 62]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



   2.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


   2.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


   2.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


   2.39.197 Immediate next-hop address

       Functionality/Description: Used for packet forwarding

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y


Hares & Retana          Expires - January 2005               [Page 63]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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


   2.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

   2.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


   2.40.201 Multiple Matching Routes

       Functionality/Description: Only the longest matching route
       SHOULD be considered



Hares & Retana          Expires - January 2005               [Page 64]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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

   2.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


   2.41.204 Algorithm used

       Functionality/Description: BGP implementations MAY use any
       algorithm which produces the same results asthose 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          Expires - January 2005               [Page 65]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



   2.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


   2.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


   2.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


3.42 Phase 3: Route Dissemination / Section 9.1.3

   2.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



Hares & Retana          Expires - January 2005               [Page 66]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


3.43 Overlapping Routes / Section 9.1.4

   2.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


Hares & Retana          Expires - January 2005               [Page 67]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.43.214 Aggregation

       Functionality/Description: Either include all ASs used to form
       the aggreagate 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


   2.43.215 De-aggregation

       Functionality/Description: Routes SHOULD NOT be de-aggregated

       RFC2119: SHOULD NOT


Hares & Retana          Expires - January 2005               [Page 68]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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


3.44 Update-Send Process / Section 9.2

   2.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


   2.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




Hares & Retana          Expires - January 2005               [Page 69]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


   2.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


   2.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


   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 70]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: Y


   2.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


3.45 Frequency of Route Advertisement / Section 9.2.1.1

   2.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


   2.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.


   2.45.226 Fast Convergence



Hares & Retana          Expires - January 2005               [Page 71]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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.



   2.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

   2.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


   2.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



Hares & Retana          Expires - January 2005               [Page 72]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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


   2.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          Expires - January 2005               [Page 73]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


   2.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


   2.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


   2.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

   2.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



Hares & Retana          Expires - January 2005               [Page 74]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y


   2.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


   2.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


   2.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


   2.46.240 ATOMIC_AGGREGATE

       Functionality/Description: The aggregated route SHALL have this


Hares & Retana          Expires - January 2005               [Page 75]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       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


   2.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


   2.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

   2.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



Hares & Retana          Expires - January 2005               [Page 76]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



   2.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


3.48 Originating BGP routes / Section 9.4

   2.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


   2.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

   2.49.247 Optional Timers

       Functionality/Description: Two optional timers MAY be supported:
       DelayOpenTimer, IdleHoldTimer by BGP


Hares & Retana          Expires - January 2005               [Page 77]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004



       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

   2.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


   2.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


   2.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          Expires - January 2005               [Page 78]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


   2.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

   2.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

   2.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


   2.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


Hares & Retana          Expires - January 2005               [Page 79]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


       NextHop Y/N/O/Comments: N


3.50 TCP options that may be used with BGP / Appendix E

   2.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.


   2.50.256 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.


3.51 Reducing route flapping / Appendix F.2

   2.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


Hares & Retana          Expires - January 2005               [Page 80]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004




3.52 Complex AS_PATH aggregation / Appendix F.6

   2.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

   2.53.259 Authentication Mechanism

       Functionality/Description: 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


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.


Hares & Retana          Expires - January 2005               [Page 81]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


                Current deployed versions are 5.x and 6.0.x.
                Version 6.1 and beyond are tested against the
                latest BGP draft soon to replace rfc1771.

     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



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)


Hares & Retana          Expires - January 2005               [Page 82]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


         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 BGP

   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):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



Hares & Retana          Expires - January 2005               [Page 83]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


     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.



Security Considerations

   This document does not address any security issues.


Normative References


   [BGP4] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 4
     (BGP-4)", draft-ietf-idr-bgp4-24.txt, June 2004

   [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4
      (BGP-4)", RFC1771, March 1995

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, March 1997

   [RFC2385] A. Heffernan, "Protection of BGP Session via a TCP MD5
      Signature", RFC2385, August 1998

   [RFC2796] Bates, T., Chandra, R., Chen, E., "BGP Route Reflection -
      an Alternative to Full Mesh IBGP", RFC 2796, April 2000

   [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC2918,
      September 2000

   [RFC3065] Traina, P., McPherson, D., Scudder, J., "Autonomous
      Confederations for BGP", RFC 3065, February 2001

   [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
      February 2004

   [RFC3668] Bradner, S. "Intellectual Property Rights in IETF
      Technology", BCP 79, February 2004










Hares & Retana          Expires - January 2005               [Page 84]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


Acknowledgments

   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 e-mail Address: hhshah@cisco.com, ruchi@cisco.com

   Laurel Responses provided by:
   Contact Name: Manish Vora
   Contact e-mail Address: vora@laurelnetworks.com

   NextHop Responses provided by:
   Contact Name: Susan Hares
   Contact e-mail Address: skh@nexthop.com
   Additional Help:  Matt Richardson, Shane Wright.


Authors' Addresses

   Susan Hares
   NextHop Technologies
   825 Victors Way, Suite 100
   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
   e-mail: aretana@cisco.com



Intellectual Property Statement

      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.




Hares & Retana          Expires - January 2005               [Page 85]

^L
                 draft-ietf-idr-bgp-implementation-01        July 2004


      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.

   Disclaimer of Validity

   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.


Copyright Statement

     Copyright (C) The Internet Society (2004). 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.






















Hares & Retana          Expires - January 2005               [Page 86]
^L


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/