[RFCs/IDs] [Plain Text] [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]