Network Working Group S. Hares
Request for Comments: 4276 NextHop
Category: Informational A. Retana
Cisco
January 2006
BGP-4 Implementation Report
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document reports the results of the BGP-4 implementation survey.
The survey had 259 questions about implementations' support of BGP-4
as specified in RFC 4271. After a brief summary of the results, each
response is listed. This document contains responses from the four
implementers that completed the survey (Alcatel, Cisco, Laurel, and
NextHop) and brief information from three that did not (Avici, Data
Connection Ltd., and Nokia).
The editors did not use exterior means to verify the accuracy of the
information submitted by the respondents. The respondents are
experts with the products they reported on.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Results of Survey ...............................................4
2.1. Significant Differences ....................................4
2.2. Overview of Differences ....................................5
2.3. Implementations and Interoperability .......................6
2.4. BGP Implementation Identification ..........................7
3. BGP-4 Implementation Report .....................................7
3.0. Summary of Operation / Section 3 [RFC 4271] .................7
3.1. Routes: Advertisement and Storage / Section 3.1 [RFC 4271] ..8
3.2. Routing Information Bases / Section 3.2 [RFC 4271] ..........9
3.3. Message Formats / Section 4 [RFC 4271] ......................9
3.4. Message Header Format / Section 4.1 [RFC 4271] .............10
Hares & Retana Informational [Page 1]
RFC 4276 BGP-4 Implementation Report January 2006
3.5. OPEN Message / Section 4.2 [RFC 4271] ......................11
3.6. UPDATE Message Format / Section 4.3 [RFC 4271] .............12
3.7. KEEPALIVE Message Format / Section 4.4 [RFC 4271] ..........16
3.8. NOTIFICATION Message Format / Section 4.5 [RFC 4271] .......17
3.9. Path Attributes /Section 5 [RFC 4271] ......................17
3.10. ORIGIN / Section 5.1.1 [RFC 4271] .........................22
3.11. AS_PATH / Section 5.1.2 [RFC 4271] ........................22
3.12. NEXT_HOP / Section 5.1.3 [RFC 4271] .......................23
3.13. MULTI_EXIT_DISC / Section 5.1.4 [RFC 4271] ................27
3.14. LOCAL_PREF / Section 5.1.5 [RFC 4271] .....................30
3.15. ATOMIC_AGGREGATE / Section 5.1.6 [RFC 4271] ...............31
3.16. AGGREGATOR / Section 5.1.7 [RFC 4271] .....................32
3.17. BGP Error Handling / Section 6 [RFC 4271] .................34
3.18. Message Header Error Handling / Section 6.1 [RFC 4271] ....34
3.19. OPEN Message Error Handling / Section 6.2 [RFC 4271] ......36
3.20. UPDATE Message Error Handling / Section 6.3 [RFC 4271] ....40
3.21. NOTIFICATION Message Error Handling / Section 6.4
[RFC 4271] ................................................50
3.22. Hold Timer Expired Error Handling / Section 6.5
[RFC 4271] ................................................51
3.23. Finite State Machine Error Handling / Section 6.6
[RFC 4271] ................................................51
3.24. Cease / Section 6.7 [RFC 4271] ............................51
3.25. BGP Connection Collision Detection / Section 6.8
[RFC 4271] ................................................53
3.26. BGP Version Negotiation / Section 7 [RFC 4271] ............54
3.27. BGP Finite State Machine (FSM) / Section 8 [RFC 4271] .....55
3.28. Administrative Events / Section 8.1.2 [RFC 4271] ..........55
3.29. Timer Events / Section 8.1.3 [RFC 4271] ...................61
3.30. TCP Connection-Based Events / Section 8.1.4 [RFC 4271] ....62
3.31. BGP Messages-Based Events / Section 8.1.5 [RFC 4271] ......63
3.32. FSM Definition / Section 8.2.1 [RFC 4271] .................65
3.33. FSM and Collision Detection / Section 8.2.1.2 [RFC 4271] ..66
3.34. FSM Event numbers / Section 8.2.1.4 [RFC 4271] ............66
3.35. Finite State Machine / Section 8.2.2 [RFC 4271] ...........67
3.36. UPDATE Message Handling / Section 9 [RFC 4271] ............67
3.37. Decision Process / Section 9.1 [RFC 4271] .................69
3.38. Phase 1: Calculation of Degree of Preference /
Section 9.1.1 ............................................70
3.39. Phase 2: Route Selection / Section 9.1.2 [RFC 4271] .......71
3.40. Route Resolvability Condition / Section 9.1.2.1
[RFC 4271] ................................................73
3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC 4271] ......74
3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC 4271] ...76
3.43. Overlapping Routes / Section 9.1.4 [RFC 4271] .............77
3.44. Update-Send Process / Section 9.2 [RFC 4271] ..............79
3.45. Frequency of Route Advertisement / Section
9.2.1.1 [RFC 4271] ........................................81
Hares & Retana Informational [Page 2]
RFC 4276 BGP-4 Implementation Report January 2006
3.46. Aggregating Routing Information / Section 9.2.2.2
[RFC 4271] ................................................82
3.47. Route Selection Criteria / Section 9.3 [RFC 4271] .........87
3.48. Originating BGP Routes / Section 9.4 [RFC 4271] ...........88
3.49. BGP Timers / Section 10 [RFC 4271] ........................88
3.50. TCP Options that May Be Used with BGP / Appendix
E [RFC 4271] ..............................................91
3.51. Reducing Route Flapping / Appendix F.2 [RFC 4271] .........92
3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC 4271] .....92
3.53. Security Considerations [RFC 4271] ........................92
4. Additional BGP Implementations Information .....................93
4.1. Avici .....................................................93
4.2. Data Connection Ltd. ......................................94
4.3. Nokia .....................................................94
5. Security Considerations ........................................95
6. Normative References ...........................................95
7. Acknowledgements ...............................................96
1. Introduction
This document reports results from a survey of implementations of
BGP-4 as specified in [RFC 4271]. RFC 4271 is in alignment with
current deployments of BGP-4 and obsoletes the BGP standard
[RFC 1771]. BGP is a widely deployed cornerstone of Internet
technology that continues to add additional functionality as the
needs of the Internet evolve. As deployed in the Internet, BGP-4
encompasses both this base specification and additional
specifications such as TCP MD5 [RFC 2385], BGP Route Reflectors
[RFC 2796], BGP Confederations [RFC 3065], and BGP Route Refresh
[RFC 2918].
The BGP-4 implementation survey had 259 detailed questions about
compliance with [RFC 4271]. Four implementers (Alcatel, Cisco,
Laurel, and NextHop) completed the survey. Section 3 provides a
compilation of those results.
Section 2.1 highlights significant differences and Section 2.2
provides an overview of the differences between the four
implementations. Section 2.3 provides interoperability information.
Due to the large number of BGP implementations and the small number
of respondents, the editors took an informal survey to determine if
the length of the original survey caused implementers not to submit
it. Three implementers responded, and all indicated the length of
the survey was the issue. Section 4 gives the results of this
informal survey.
Hares & Retana Informational [Page 3]
RFC 4276 BGP-4 Implementation Report January 2006
In this document, the editors have compiled the results of the
implementation survey results and the informal survey.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Results of Survey
The respondents replied "Y" (yes) or "N" (no) to the survey's 259
questions to indicate whether their implementation supports the
Functionality/Description of the [RFC 2119] language in [RFC 4271].
The respondents replied "O" (other) to indicate that the support is
neither "Y" nor "N" (for example, an alternate behavior).
2.1. Significant Differences
Each question received affirmative responses from at least two
implementers (i.e., two "Y" responses, or one "Y" and one "O"),
except the following questions:
a) MUST - Linked Questions 212/213, regarding Section 9.1.4
Due to the format of the linked questions, three vendors (Cisco,
Laurel, and NextHop) replied "N" to Question 213. (See Section
2.2 for details.)
b) SHALL NOT - Question 228, regarding Section 9.2.2.2
Three vendors (Alcatel, Cisco, and Laurel) answered "N" to SHALL
NOT (meaning they did). One vendor (NextHop) indicated "O"
matching the specification.
Text: Routes that have different MULTI_EXIT_DISC attribute SHALL
NOT be aggregated. (Section 9.2.2.2, [RFC 4271])
c) SHOULD - Questions 257 and 258, regarding Appendix F
Three vendors answered "N" and one vendor answered "Y" to Question
257. All four vendors answered "N" to Question 258. (Please note
that support of Appendix F, "Implementation Recommendations", is
optional.)
Hares & Retana Informational [Page 4]
RFC 4276 BGP-4 Implementation Report January 2006
Text: A BGP speaker which needs to withdraw a destination and
send an update about a more specific or less specific route
SHOULD combine them into the same UPDATE message.
(Appendix F.2, [RFC 4271])
Text: The last instance (rightmost occurrence) of that AS number
is kept. (Appendix F.6, [RFC 4271])
d) MAY - Questions 180 and 254, regarding Sections 8.1.2.4 and 10
Three vendors answered "N", and 1 replied "Y" to Question 180.
Text: The Event numbers (1-28) utilized in this state machine
description aid in specifying the behavior of the BGP state
machine. Implementations MAY use these numbers to provide
network management information. The exact form of a FSM or
the FSM events are specific to each implementation.
(Section 8.1.2.4, [RFC 4271])
Editors' note: Section 8.1.2.4 was written to allow existing
implementations to transition to the new event
numbering. It was expected over time (3 years)
that the FSM event numbering would be updated to
the new numbering.
Three vendors answered "N" and one answered "Y" to Question 254
about configurable jitter time values.
Text: A given BGP speaker MAY apply the same jitter to each of
these quantities regardless of the destinations to which
the updates are being sent; that is, jitter need not be
configured on a "per peer" basis. (Section 10, [RFC 4271])
Question: Is the jitter range configurable?
2.2. Overview of Differences
This section provides the reader with a shortcut to the points where
the four implementations differ.
The following questions were not answered "Y" by all four respondents
(Note that the question numbers correspond to the final digit of
subsection numbers of Section 3):
MUST
97, 106, 107, 111, 122, 125, 138, 141, 213
Hares & Retana Informational [Page 5]
RFC 4276 BGP-4 Implementation Report January 2006
SHALL
233, 239
SHALL NOT
228
SHOULD
42, 117, 132, 146, 152, 155, 156, 157, 158, 159, 160, 161, 163,
164, 165, 169, 170, 171, 173, 174, 175, 202, 225, 250, 255, 256
SHOULD NOT
226
MAY
67, 94, 121, 143, 180, 223, 247, 254
Other
236, 238
Linked Questions
212/213
Three vendors answered "N" and one answered "Y" to Question 213
about the aggregation of routes. Questions 212 and 213 are
grouped together.
Question 212 states: "The decision process MUST either install
both routes or..."
Question 213 states: "Aggregate the two routes and install the
aggregated route, provided that both routes have the same value
of the NEXT_HOP attribute"
Of the four respondents that said "Y" to Question 212, three said
"N" to Question 213. Given the context of the question, answering
"N" to Question 213 is appropriate.
2.3. Implementations and Interoperability
Alcatel Cisco Laurel NextHop
Alcatel Y Y
Cisco Y
Laurel Y Y
NextHop Y Y
Hares & Retana Informational [Page 6]
RFC 4276 BGP-4 Implementation Report January 2006
2.4. BGP Implementation Identification
1.6.0 Alcatel
Implementation Name/Version:
Alcatel 7750 BGP Implementation Release 1.3
Date: July 2003
Contact Name: Devendra Raut
Contact Email: Devendra.raut@Alcatel.com
1.6.1 Cisco
Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S
Contact Name: Alvaro Retana
Date: 11/26/2003
1.6.2 Laurel
Implementation Name/Version: Laurel Networks 3.0
Contact Name: Manish Vora
Contact Email: vora@laurelnetworks.com
Date: 2/1/2004
1.6.3 NextHop Technologies
Implementation Name/Version: Gated NGC 2.0, 2.2
Date: January 2004
3. BGP-4 Implementation Report
For every item listed, the respondents indicated whether their
implementation supports the Functionality/Description or not (Y/N)
according to the [RFC 2119] 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
[RFC 4271] for additional details. Note that the last digit of the
subsection number is the number of the survey question.
3.0. Summary of Operation / Section 3 [RFC 4271]
3.0.1. Base Behavior
Functionality/Description: Is your implementation compatible
with the base behavior described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 7]
RFC 4276 BGP-4 Implementation Report January 2006
3.0.2. Local Policy Changes
Functionality/Description: To allow local policy changes to have
the correct effect without resetting any BGP connections, a BGP
speaker SHOULD either (a) retain the current version of the
routes advertised to it by all of its peers for the duration of
the connection, or (b) make use of the Route Refresh extension
[RFC 2918]
RFC 2119: 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 [RFC 4271]
3.1.3. Withdraw Routes from Service
Functionality/Description: Does your implementation support the
three methods described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.1.4. Path Attributes
Functionality/Description: Added to or modified before
advertising the route
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 8]
RFC 4276 BGP-4 Implementation Report January 2006
3.2. Routing Information Bases / Section 3.2 [RFC 4271]
3.2.5. Routing Information Bases
Functionality/Description: Is your implementation compatible
with the RIB structure described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.2.6. Next Hop Resolution
Functionality/Description: The next hop for each route in the
Loc-RIB MUST be resolvable via the local BGP speaker's Routing
Table
RFC 2119: MUST
Alcatel 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 [RFC 4271]
3.3.7. Message Size
Functionality/Description: Does your implementation support the
message sizes described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 9]
RFC 4276 BGP-4 Implementation Report January 2006
3.4. Message Header Format / Section 4.1 [RFC 4271]
3.4.8. Marker
Functionality/Description: MUST be set to all ones
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.4.9. Length
Functionality/Description: MUST always be at least 19 and no
greater than 4096
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.4.10. Length
Functionality/Description: MAY be further constrained, depending
on the message type
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 10]
RFC 4276 BGP-4 Implementation Report January 2006
3.4.11. Message "Padding"
Functionality/Description: No "padding" of extra data after the
message is allowed, so the Length field MUST have the smallest
value required given the rest of the message
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.5. OPEN Message / Section 4.2 [RFC 4271]
3.5.12. Hold Timer Calculation
Functionality/Description: Use the smaller of its configured
Hold Time and the Hold Time received in the OPEN message
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.5.13. Minimum Hold Time
Functionality/Description: MUST be either zero or at least three
seconds
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 11]
RFC 4276 BGP-4 Implementation Report January 2006
3.5.14. Connection Rejection
Functionality/Description: Based on the Hold Time
RFC 2119: 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 [RFC 4271]
3.6.15. UPDATE
Functionality/Description: Simultaneously advertise a feasible
route and withdraw multiple unfeasible routes from service
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We have capability to process this
functionality on receiving end but
we don't send feasible & unfeasible
simultaneously.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.16. Transitive Bit Setting
Functionality/Description: For well-known attributes, the
Transitive bit MUST be set to 1
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 12]
RFC 4276 BGP-4 Implementation Report January 2006
3.6.17. Partial Bit Setting
Functionality/Description: For well-known attributes and for
optional non-transitive attributes the Partial bit MUST be set
to 0
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.18. Attribute Flags Octet Sending
Functionality/Description: Lower-order four bits set to zero
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.19. Attribute Flags Octet Receiving
Functionality/Description: Lower-order four bits ignored
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 13]
RFC 4276 BGP-4 Implementation Report January 2006
3.6.20. NEXT_HOP
Functionality/Description: Used as the next hop to the
destinations listed in the NLRI field of the UPDATE message
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.21. MULTI_EXIT_DISC
Functionality/Description: Used by a BGP speaker's decision
process to discriminate among multiple entry points to a
neighboring autonomous system
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.22. AGGREGATOR IP Address
Functionality/Description: Same address as the one used for the
BGP Identifier of the speaker
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y Default behavior. Can be configured
different from BGP ID.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 14]
RFC 4276 BGP-4 Implementation Report January 2006
3.6.23. UPDATE messages that include the same address prefix in the
WITHDRAWN ROUTES and Network Layer Reachability Information
fields
Functionality/Description: UPDATE messages SHOULD NOT include
that information
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.24. UPDATE messages that include the same address prefix in the
WITHDRAWN ROUTES and Network Layer Reachability Information
fields
Functionality/Description: The BGP speaker MUST be able to handle
them
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.6.25. UPDATE messages that include the same address prefix in the
WITHDRAWN ROUTES and Network Layer Reachability Information
fields
Functionality/Description: Treated as if the WITHDRAWN ROUTES
doesn't contain the address prefix
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y Withdrawn routes are processed
before NLRI fields. Hence we get
the desired behavior.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 15]
RFC 4276 BGP-4 Implementation Report January 2006
3.7. KEEPALIVE Message Format / Section 4.4 [RFC 4271]
3.7.26. Maximum KEEPALIVE Frequency
Functionality/Description: Not greater than one second
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.7.27. KEEPALIVE Messages Rate
Functionality/Description: Adjusted as a function of the Hold
Time interval
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.7.28. Negotiated Hold Time of 0
Functionality/Description: No KEEPALIVEs sent
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 16]
RFC 4276 BGP-4 Implementation Report January 2006
3.8. NOTIFICATION Message Format / Section 4.5 [RFC 4271]
3.8.29. NOTIFICATION Message
Functionality/Description: Does your implementation support the
NOTIFICATION Message as described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9. Path Attributes /Section 5 [RFC 4271]
3.9.30. Path Attributes
Functionality/Description: Does your implementation support the
path attributes as described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.31. Well-Known Attributes
Functionality/Description: Recognized by all BGP implementations
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 17]
RFC 4276 BGP-4 Implementation Report January 2006
3.9.32. Mandatory Attributes
Functionality/Description: Included in every UPDATE message that
contains NLRI
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.33/34. Discretionary Attributes
Functionality/Description: Sent in a particular UPDATE message
RFC 2119: MAY or MAY NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.35. Well-Known Attributes
Functionality/Description: Passed along (after proper updating,
if necessary) to other BGP peers
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 18]
RFC 4276 BGP-4 Implementation Report January 2006
3.9.36. Optional Attributes
Functionality/Description: In addition to well-known attributes,
each path MAY contain one or more optional attributes
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.37. Unrecognized Transitive Optional Attributes
Functionality/Description: Accepted
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.38. Partial Bit for Unrecognized Transitive Optional Attributes
Functionality/Description: Set to 1 if the attribute is accepted
and passed to other BGP speakers
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 19]
RFC 4276 BGP-4 Implementation Report January 2006
3.9.39. Unrecognized Non-Transitive Optional Attributes
Functionality/Description: Quietly ignored and not passed along
to other BGP peers
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.40. New Transitive Optional Attributes
Functionality/Description: Attached to the path by the
originator or by any other BGP speaker in the path
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.41. Optional Attributes
Functionality/Description: Updated by BGP speakers in the path
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 20]
RFC 4276 BGP-4 Implementation Report January 2006
3.9.42. Path Attributes
Functionality/Description: Ordered in ascending order of
attribute type
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O All attributes are ordered in
ascending order except Extended
Community, which is type 16 but we
send it out after community
attribute.
Laurel Y/N/O/Comments: Y except for MBGP which is always last
NextHop Y/N/O/Comments: Y
3.9.43. Out of Order Received Path Attributes
Functionality/Description: Receiver MUST be able to handle
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.9.44. Mandatory Attributes
Functionality/Description: Present in all exchanges if NLRI are
contained in the UPDATE message
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 21]
RFC 4276 BGP-4 Implementation Report January 2006
3.10. ORIGIN / Section 5.1.1 [RFC 4271]
3.10.45. ORIGIN
Functionality/Description: Value SHOULD NOT be changed by any
speaker, except the originator
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.11. AS_PATH / Section 5.1.2 [RFC 4271]
3.11.46. AS_PATH
Functionality/Description: Not modified when advertising a route
to an internal peer
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.11.47. Segment Overflow
Functionality/Description: If the act of prepending will cause
an overflow in the AS_PATH segment, i.e., more than 255 ASs, it
SHOULD prepend a new segment of type AS_SEQUENCE and prepend its
own AS number to this new segment
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 22]
RFC 4276 BGP-4 Implementation Report January 2006
3.11.48. Prepending
Functionality/Description: The local system MAY include/prepend
more than one instance of its own AS number in the AS_PATH
attribute
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12. NEXT_HOP / Section 5.1.3 [RFC 4271]
3.12.49. NEXT_HOP
Functionality/Description: Used as the next hop to the
destinations listed in the UPDATE message
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.50. NEXT_HOP
Functionality/Description: When sending a message to an internal
peer, if the route is not locally originated, the BGP speaker
SHOULD NOT modify the NEXT_HOP attribute, unless it has been
explicitly configured to announce its own IP address as the
NEXT_HOP
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 23]
RFC 4276 BGP-4 Implementation Report January 2006
3.12.51. NEXT_HOP
Functionality/Description: When announcing a locally originated
route to an internal peer, the BGP speaker SHOULD use as the
NEXT_HOP the interface address of the router through which the
announced network is reachable for the speaker
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.52. NEXT_HOP
Functionality/Description: If the route is directly connected to
the speaker, or the interface address of the router through
which the announced network is reachable for the speaker is the
internal peer's address, then the BGP speaker SHOULD use for the
NEXT_HOP attribute its own IP address (the address of the
interface that is used to reach the peer)
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.53. "First Party" NEXT_HOP
Functionality/Description: If the external peer to which the
route is being advertised shares a common subnet with one of the
interfaces of the announcing BGP speaker, the speaker MAY use
the IP address associated with such an interface in the NEXT_HOP
attribute
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 24]
RFC 4276 BGP-4 Implementation Report January 2006
3.12.54. Default NEXT_HOP
Functionality/Description: IP address of the interface that the
speaker uses to establish the BGP connection to peer X
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.55. NEXT_HOP Propagation
Functionality/Description: The speaker MAY be configured to
propagate the NEXT_HOP attribute. In this case when advertising
a route that the speaker learned from one of its peers, the
NEXT_HOP attribute of the advertised route is exactly the same
as the NEXT_HOP attribute of the learned route (the speaker just
doesn't modify the NEXT_HOP attribute)
RFC 2119: MAY
Alcatel Y/N/O/Comments: O
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.56. Third Party NEXT_HOP
Functionality/Description: MUST be able to support disabling it
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 25]
RFC 4276 BGP-4 Implementation Report January 2006
3.12.57. NEXT_HOP
Functionality/Description: A route originated by a BGP speaker
SHALL NOT be advertised to a peer using an address of that peer
as NEXT_HOP
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.58. NEXT_HOP
Functionality/Description: A BGP speaker SHALL NOT install a
route with itself as the next hop
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.59. NEXT_HOP
Functionality/Description: Used to determine the actual outbound
interface and immediate next-hop address that SHOULD be used to
forward transit packets to the associated destinations
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 26]
RFC 4276 BGP-4 Implementation Report January 2006
3.12.60. Resolved NEXT_HOP IP Address
Functionality/Description: If the entry specifies an attached
subnet, but does not specify a next-hop address, then the
address in the NEXT_HOP attribute SHOULD be used as the
immediate next-hop address
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.12.61. Resolved NEXT_HOP IP Address
Functionality/Description: If the entry also specifies the
next-hop address, this address SHOULD be used as the immediate
next-hop address for packet forwarding
RFC 2119: 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 [RFC 4271]
3.13.62. Preferred Metric
Functionality/Description: Lowest value
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 27]
RFC 4276 BGP-4 Implementation Report January 2006
3.13.63. MULTI_EXIT_DISC
Functionality/Description: If received over EBGP, the
MULTI_EXIT_DISC attribute MAY be propagated over IBGP to other
BGP speakers within the same AS
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.13.64. MULTI_EXIT_DISC
Functionality/Description: If received from a neighboring AS, it
MUST NOT be propagated to other neighboring ASes
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.13.65. Remove MULTI_EXIT_DISC
Functionality/Description: Local configuration mechanism to
remove the attribute from a route
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 28]
RFC 4276 BGP-4 Implementation Report January 2006
3.13.66. Remove MULTI_EXIT_DISC
Functionality/Description: Done prior to determining the degree
of preference of the route and performing route selection
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.13.67. MULTI_EXIT_DISC Alteration
Functionality/Description: An implementation MAY also (based on
local configuration) alter the value of the MULTI_EXIT_DISC
attribute received over EBGP
RFC 2119: MAY
Alcatel Y/N/O/Comments: O
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.13.68. MULTI_EXIT_DISC Alteration
Functionality/Description: Done prior to determining the degree
of preference of the route and performing route selection
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 29]
RFC 4276 BGP-4 Implementation Report January 2006
3.14. LOCAL_PREF / Section 5.1.5 [RFC 4271]
3.14.69. LOCAL_PREF
Functionality/Description: Included in all UPDATE messages that
a given BGP speaker sends to the other internal peers
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.14.70. Degree of Preference
Functionality/Description: Calculated for each external route
based on the locally configured policy, and included when
advertising a route to its internal peers
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.14.71. LOCAL_PREF
Functionality/Description: Higher degree of preference MUST be
preferred
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 30]
RFC 4276 BGP-4 Implementation Report January 2006
3.14.72. LOCAL_PREF
Functionality/Description: Not included in UPDATE messages sent
to external peers, except for the case of BGP Confederations
[RFC 3065]
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.14.73. LOCAL_PREF
Functionality/Description: Ignored if received from an external
peer, except for the case of BGP Confederations [RFC 3065]
RFC 2119: MUST
Alcatel 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 [RFC 4271]
3.15.74. ATOMIC_AGGREGATE
Functionality/Description: Included if an aggregate excludes at
least some of the AS numbers present in the AS_PATH of the
routes that are aggregated as a result of dropping the AS_SET
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 31]
RFC 4276 BGP-4 Implementation Report January 2006
3.15.75. Received ATOMIC_AGGREGATE
Functionality/Description: BGP speaker SHOULD NOT remove the
attribute from the route when propagating it to other speakers
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.15.76. Received ATOMIC_AGGREGATE
Functionality/Description: BGP speaker MUST NOT make any NLRI of
that route more specific (as defined in 9.1.4)
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.16. AGGREGATOR / Section 5.1.7 [RFC 4271]
3.16.77. AGGREGATOR
Functionality/Description: Included in updates which are formed
by aggregation (see Section 9.2.2.2)
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 32]
RFC 4276 BGP-4 Implementation Report January 2006
3.16.78. AGGREGATOR
Functionality/Description: Added by the BGP speaker performing
route aggregation
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.16.79. AGGREGATOR
Functionality/Description: Contain local AS number and IP
address
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y Default behavior. Can be configured
different from BGP ID.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.16.80. AGGREGATOR IP Address
Functionality/Description: The same as the BGP Identifier of the
speaker
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 33]
RFC 4276 BGP-4 Implementation Report January 2006
3.17. BGP Error Handling / Section 6 [RFC 4271]
3.17.81. Error Handling
Functionality/Description: Is your implementation compatible
with the error handling procedures described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.17.82. Error Subcode
Functionality/Description: Zero, if it is not specified
RFC 2119: MUST
Alcatel 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 [RFC 4271]
3.18.83. Message Header Errors
Functionality/Description: Indicated by sending the NOTIFICATION
message with Error Code Message Header Error
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 34]
RFC 4276 BGP-4 Implementation Report January 2006
3.18.84. Synchronization Error
Functionality/Description: Error Subcode MUST be set to
Connection Not Synchronized
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.18.85. Message Length
Functionality/Description: Use the Bad Message Length Error
Subcode to indicate an incorrect message length
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.18.86. Bad Message Length
Functionality/Description: The Data field MUST contain the
erroneous Length field
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 35]
RFC 4276 BGP-4 Implementation Report January 2006
3.18.87. Type Field
Functionality/Description: If the Type field of the message
header is not recognized, then the Error Subcode MUST be set to
Bad Message Type
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.18.88. Bad Message Type
Functionality/Description: The Data field MUST contain the
erroneous Type field
RFC 2119: MUST
Alcatel 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 [RFC 4271]
3.19.89. OPEN Message Errors
Functionality/Description: Indicated by sending the NOTIFICATION
message with Error Code OPEN Message Error
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 36]
RFC 4276 BGP-4 Implementation Report January 2006
3.19.90. Version Number Not Supported
Functionality/Description: The Error Subcode MUST be set to
Unsupported Version Number
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.19.91. Unacceptable Autonomous System Field
Functionality/Description: The Error Subcode MUST be set to Bad
Peer AS
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.19.92. Unacceptable Hold Time Error Subcode
Functionality/Description: Used if the Hold Time field of the
OPEN message is unacceptable
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 37]
RFC 4276 BGP-4 Implementation Report January 2006
3.19.93. Hold Time Rejection
Functionality/Description: Values of one or two seconds
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.19.94. Hold Time Rejection
Functionality/Description: An implementation may reject any
proposed Hold Time
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
3.19.95. Hold Time
Functionality/Description: If accepted, then the negotiated
value MUST be used
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 38]
RFC 4276 BGP-4 Implementation Report January 2006
3.19.96. Syntactically Incorrect BGP Identifier
Functionality/Description: The Error Subcode MUST be set to Bad
BGP Identifier
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.19.97. Not Recognized Optional Parameters
Functionality/Description: The Error Subcode MUST be set to
Unsupported Optional Parameters
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We may fix this.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.19.98. Recognized but Malformed Optional Parameters
Functionality/Description: The Error Subcode MUST be set to 0
(Unspecific)
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 39]
RFC 4276 BGP-4 Implementation Report January 2006
3.20. UPDATE Message Error Handling / Section 6.3 [RFC 4271]
3.20.99. UPDATE Message Errors
Functionality/Description: Indicated by sending the
NOTIFICATION message with Error Code UPDATE Message Error
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.100. Too Large
Functionality/Description: If the Withdrawn Routes Length or
Total Attribute Length is too large, then the Error Subcode MUST
be set to Malformed Attribute List
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.101. Conflicting Flags
Functionality/Description: If any recognized attribute has
Attribute Flags that conflict with the Attribute Type Code, then
the Error Subcode MUST be set to Attribute Flags Error
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 40]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.102. Conflicting Flags
Functionality/Description: The Data field MUST contain the
erroneous attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.103. Conflicting Length
Functionality/Description: If any recognized attribute has
Attribute Length that conflicts with the expected length, then
the Error Subcode MUST be set to Attribute Length Error
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.104. Conflicting Length
Functionality/Description: The Data field MUST contain the
erroneous attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 41]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.105. Missing Mandatory Well-Known Attributes
Functionality/Description: The Error Subcode MUST be set to
Missing Well-known Attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.106. Missing Mandatory Well-Known Attributes
Functionality/Description: The Data field MUST contain the
Attribute Type Code of the missing well-known attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We plan to fix this in future.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.107. Unrecognized Mandatory Well-Known Attributes
Functionality/Description: The Error Subcode MUST be set to
Unrecognized Well-known Attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We set error subcode to Attribute
Flags Error, but we intend to
correct this soon.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 42]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.108. Unrecognized Mandatory Well-Known Attributes
Functionality/Description: The Data field MUST contain the
unrecognized attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.109. Undefined ORIGIN
Functionality/Description: The Error Sub-code MUST be set to
Invalid Origin Attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.110. Undefined ORIGIN
Functionality/Description: The Data field MUST contain the
unrecognized attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 43]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.111. Syntactically Incorrect NEXT_HOP
Functionality/Description: The Error Subcode MUST be set to
Invalid NEXT_HOP Attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N Ignores the prefix in case of
martian nexthop, and in case of
length not equal to IPv4
address-length, we send
NOTIFICATION with error subcode
Attribute Length error.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.112. Syntactically Incorrect NEXT_HOP
Functionality/Description: The Data field MUST contain the
incorrect attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.113. NEXT_HOP Semantic Correctness
Functionality/Description: NEXT_HOP is checked for semantic
correctness against the criteria in this section
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 44]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.114. NEXT_HOP Semantic Correctness
Functionality/Description: Not be the IP address of the
receiving speaker
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.115. NEXT_HOP Semantic Correctness
Functionality/Description: In the case of an EBGP where the
sender and receiver are one IP hop away from each other, either
the IP address in the NEXT_HOP MUST be the sender's IP address
(that is used to establish the BGP connection), or the interface
associated with the NEXT_HOP IP address MUST share a common
subnet with the receiving BGP speaker
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.116. Semantically Incorrect NEXT_HOP
Functionality/Description: Error logged
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 45]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.117. Semantically Incorrect NEXT_HOP
Functionality/Description: Route Ignored
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
3.20.118. Semantically Incorrect NEXT_HOP
Functionality/Description: NOTIFICATION not sent
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.119. Semantically Incorrect NEXT_HOP
Functionality/Description: Connection not closed
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.120. Syntactically Incorrect AS_PATH
Functionality/Description: The Error Subcode MUST be set to
Malformed AS_PATH
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 46]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.121. First Neighbor in AS_PATH Check
Functionality/Description: If the UPDATE message is received
from an external peer, the local system MAY check whether the
leftmost AS in the AS_PATH attribute is equal to the autonomous
system number of the peer that sent the message
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
3.20.122. First Neighbor in AS_PATH Check
Functionality/Description: If the check determines that this is
not the case, the Error Subcode MUST be set to Malformed AS_PATH
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
3.20.123. Optional Attributes
Functionality/Description: Value MUST be checked if the
attribute is recognized
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 47]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.124. Optional Attribute Error
Functionality/Description: The attribute MUST be discarded
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.125. Optional Attribute Error
Functionality/Description: The Error Subcode MUST be set to
Optional Attribute Error
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N What exactly is optional attribute
e.g., If error is flag related, we
send update flag error subcode, if it
is length related, we send update
length error subcode. These granular
subcodes are better in terms of
debugging than optional attribute
error.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y Only optional attribute error that
doesn't have a more specific error,
is the version 3 to version 4 error
for the atomic aggregate. All others
default to more specific error codes
if implementation.
3.20.126. Optional Attribute Error
Functionality/Description: The Data field MUST contain the
attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 48]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.127. Duplicate Attributes
Functionality/Description: If any attribute appears more than
once in the UPDATE message, then the Error Subcode MUST be set
to Malformed Attribute List
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.128. Syntactically Incorrect NLRI Field
Functionality/Description: The Error Subcode MUST be set to
Invalid Network Field
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.129. Semantically Incorrect NLRI Field
Functionality/Description: An error SHOULD be logged locally
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 49]
RFC 4276 BGP-4 Implementation Report January 2006
3.20.130. Semantically Incorrect NLRI Field
Functionality/Description: The prefix SHOULD be ignored
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.20.131. UPDATE with no NLRI
Functionality/Description: An UPDATE message that contains
correct path attributes, but no NLRI, SHALL be treated as a
valid UPDATE message
RFC 2119: 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 [RFC 4271]
3.21.132. Error in NOTIFICATION Message
Functionality/Description: Noticed, logged locally, and brought
to the attention of the administration of the peer
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 50]
RFC 4276 BGP-4 Implementation Report January 2006
3.22. Hold Timer Expired Error Handling / Section 6.5 [RFC 4271]
3.22.133. Hold Timer Expired
Functionality/Description: Is your implementation compatible
with the error handling procedures described in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.23. Finite State Machine Error Handling / Section 6.6 [RFC 4271]
3.23.134. Finite State Machine Errors
Functionality/Description: Is your implementation compatible
with the error handling procedures described in this section?
RFC 2119: 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 [RFC 4271]
3.24.135. Cease NOTIFICATION
Functionality/Description: Used in absence of any fatal errors
if a BGP peer chooses at any given time to close its BGP
connection
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We close the TCP session without
CEASE NOTIFICATION.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 51]
RFC 4276 BGP-4 Implementation Report January 2006
3.24.136. Cease NOTIFICATION
Functionality/Description: Not used for specified fatal errors
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.24.137. Upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor
Functionality/Description: Support by local configuration
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.24.138. Upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor
Functionality/Description: If exceeded and the BGP speaker
decides to terminate its BGP connection, the Cease NOTIFICATION
MUST be used
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We don't send CEASE but we plan to
correct that soon.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y No termination of peers is supported
We are considering support with the
maximum prefix document for later
releases.
Hares & Retana Informational [Page 52]
RFC 4276 BGP-4 Implementation Report January 2006
3.24.139. Upper bound on the number of address prefixes the speaker
is willing to accept from a neighbor
Functionality/Description: Log locally
RFC 2119: 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 [RFC 4271]
3.25.140. Connection Collision
Functionality/Description: One of the connections MUST be closed
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.25.141. Receipt of an OPEN Message
Functionality/Description: The local system MUST examine all of
its connections that are in the OpenConfirm state
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We detect collision through some
other implementation specific way
and resolve by method specified in
the document.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 53]
RFC 4276 BGP-4 Implementation Report January 2006
3.25.142. Receipt of an OPEN Message
Functionality/Description: Examine connections in an OpenSent
state if it knows the BGP Identifier of the peer by means
outside of the protocol
RFC 2119: 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 [RFC 4271]
3.26.143. Version Negotiation
Functionality/Description: Multiple attempts to open a BGP
connection, starting with the highest version number each
supports
RFC 2119: MAY
Alcatel Y/N/O/Comments: N Supports only version 4
Cisco Y/N/O/Comments: O We resolve it through config. If
Config is for version 3, and we get
version 4, OPEN will always fail.
Similarly, if configed (default) is
version 4 and peers configured is 3,
we don't try to negotiate version 3
unless we have configured it.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: N Supports only version 4.
3.26.144. Future Versions of BGP
Functionality/Description: MUST retain the format of the OPEN
and NOTIFICATION messages
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 54]
RFC 4276 BGP-4 Implementation Report January 2006
3.27. BGP Finite State Machine (FSM) / Section 8 [RFC 4271]
3.27.145. FSM
Functionality/Description: Is your implementation compatible
with the conceptual FSM described in this section?
RFC 2119: 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 [RFC 4271]
3.28.146. Optional Session Attribute Settings
Functionality/Description: Each event has an indication of what
optional session attributes SHOULD be set at each stage
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O Its rather vague. We have an option
Of manually starting or stopping
sessions but not an option for all
optional session attributes that are
listed in the document.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y The following optional attributes
are implied in this implementation:
1) Automatic start, 2) Automatic
Stop, 3)
3.28.147. Event1: ManualStart
Functionality/Description: The PassiveTcpEstablishment attribute
SHOULD be set to FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 55]
RFC 4276 BGP-4 Implementation Report January 2006
3.28.148. Event3: AutomaticStart
Functionality/Description: The AllowAutomaticStart attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.149. Event3: AutomaticStart
Functionality/Description: The PassiveTcpEstablishment optional
session attribute SHOULD be set to FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.150. Event3: AutomaticStart
Functionality/Description: DampPeerOscillations SHOULD be set to
FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations
attribute, so it is always FALSE.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 56]
RFC 4276 BGP-4 Implementation Report January 2006
3.28.151. Event4: ManualStart_with_PassiveTcpEstablishment
Functionality/Description: The PassiveTcpEstablishment attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y We wait for some fixed time before
initiating OPEN.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.152. Event4: ManualStart_with_PassiveTcpEstablishment
Functionality/Description: The DampPeerOscillations attribute
SHOULD be set to FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations
attribute so it is FALSE.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O We don't support DampPeerOscilation
attribute with a setting of off, and
hence Event 4. Future version will
support Event 4
3.28.153. Event5: AutomaticStart_with_PassiveTcpEstablishment
Functionality/Description: The AllowAutomaticStart attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 57]
RFC 4276 BGP-4 Implementation Report January 2006
3.28.154. Event5: AutomaticStart_with_PassiveTcpEstablishment
Functionality/Description: The PassiveTcpEstablishment attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.155. Event5: AutomaticStart_with_PassiveTcpEstablishment
Functionality/Description: The DampPeerOscillations SHOULD be
set to FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y Don't support DampPeerOscillations
attribute, so always FALSE.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O We don't support DampPeerOscilation
attribute with a setting of off, and
hence Event 5. Future version will
support Event 5
3.28.156. Event6: AutomaticStart_with_DampPeerOscillations
Functionality/Description: The AllowAutomaticStart attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 58]
RFC 4276 BGP-4 Implementation Report January 2006
3.28.157. Event6: AutomaticStart_with_DampPeerOscillations
Functionality/Description: The DampPeerOscillations attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: N Don't support DampPeerOscillations
attribute.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.158. Event6: AutomaticStart_with_DampPeerOscillations
Functionality/Description: The PassiveTcpEstablishment attribute
SHOULD be set to FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event6.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.159. Event7:
AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
Functionality/Description: The AllowAutomaticStart attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event7
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 59]
RFC 4276 BGP-4 Implementation Report January 2006
3.28.160. Event7:
AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
Functionality/Description: The DampPeerOscillations attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event7
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.161. Event7:
AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
Functionality/Description: The PassiveTcpEstablishment attribute
SHOULD be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event7
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.28.162. Event8: AutomaticStop
Functionality/Description: The AllowAutomaticStop attribute
SHOULD be TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 60]
RFC 4276 BGP-4 Implementation Report January 2006
3.29. Timer Events / Section 8.1.3 [RFC 4271]
3.29.163. Event12: DelayOpenTimer_Expires
Functionality/Description: DelayOpen attribute SHOULD be set to
TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
3.29.164. Event12: DelayOpenTimer_Expires
Functionality/Description: DelayOpenTime attribute SHOULD be
supported
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
3.29.165. Event12: DelayOpenTimer_Expires
Functionality/Description: DelayOpenTimer SHOULD be supported
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 61]
RFC 4276 BGP-4 Implementation Report January 2006
3.29.166. Event13: IdleHoldTimer_Expires
Functionality/Description: DampPeerOscillations attribute SHOULD
be set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O Don't support DampPeerOscillations
attribute and hence Event13
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.29.167. Event13: IdleHoldTimer_Expires
Functionality/Description: IdleHoldTimer SHOULD have just
expired
RFC 2119: 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 [RFC 4271]
3.30.168. Event14: TcpConnection_Valid
Functionality/Description: BGP's destination port SHOULD be port
179
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 62]
RFC 4276 BGP-4 Implementation Report January 2006
3.30.169. Event14: TcpConnection_Valid
Functionality/Description: The TrackTcpState attribute SHOULD be
set to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O GateD NGC 2.0 provides hooks for
the TCP state tracking, but use of
this option depends OS support.
Future versions will have additional
hooks.
3.30.170. Event15: Tcp_CR_Invalid
Functionality/Description: BGP destination port number SHOULD be
179
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O GateD NGC 2.0 provides hooks for
the TCP state tracking, but use of
this option depends OS support.
Future versions will have additional
hooks.
3.31. BGP Messages-Based Events / Section 8.1.5 [RFC 4271]
3.31.171. Event19: BGPOpen
Functionality/Description: The DelayOpen optional attribute
SHOULD be set to FALSE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 63]
RFC 4276 BGP-4 Implementation Report January 2006
3.31.172. Event19: BGPOpen
Functionality/Description: The DelayOpenTimer SHOULD not be
running
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.31.173. Event20: BGPOpen with DelayOpenTimer Running
Functionality/Description: The DelayOpen attribute SHOULD be set
to TRUE
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N Not applicable
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
3.31.174. Event20: BGPOpen with DelayOpenTimer Running
Functionality/Description: The DelayOpenTimer SHOULD be running
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: n/a
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 64]
RFC 4276 BGP-4 Implementation Report January 2006
3.31.175. Event23: OpenCollisionDump
Functionality/Description: If the state machine is to process
this event in Established state, the
CollisionDetectEstablishedState optional attribute SHOULD be set
to TRUE
RFC 2119: 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 [RFC 4271]
3.32.176. FSM
Functionality/Description: Separate FSM for each configured peer
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.32.177. TCP Port 179
Functionality/Description: A BGP implementation MUST connect to
and listen on TCP port 179 for incoming connections in addition
to trying to connect to peers
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 65]
RFC 4276 BGP-4 Implementation Report January 2006
3.32.178. Incoming Connections
Functionality/Description: A state machine MUST be instantiated
RFC 2119: MUST
Alcatel 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 [RFC 4271]
3.33.179. Connection Collision
Functionality/Description: The corresponding FSM for the
connection that is closed SHOULD be disposed of
RFC 2119: 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 [RFC 4271]
3.34.180. Event Numbers
Functionality/Description: Used to provide network management
information
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y Not visible to operator.
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: N Future Release of GateD NGC may
support event numbers.
Hares & Retana Informational [Page 66]
RFC 4276 BGP-4 Implementation Report January 2006
3.35. Finite State Machine / Section 8.2.2 [RFC 4271]
3.35.181. ConnectRetryTimer
Functionality/Description: Sufficiently large to allow TCP
initialization
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.35.182. Second Connection Tracking
Functionality/Description: In response to a TCP connection
succeeds [Event 16 or Event 17], the 2nd connection SHALL be
tracked until it sends an OPEN message
RFC 2119: 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 [RFC 4271]
3.36.183. UPDATE Message Handling
Functionality/Description: Does your implementation handle
UPDATE messages in a manner compatible to the description in
this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 67]
RFC 4276 BGP-4 Implementation Report January 2006
3.36.184. WITHDRAWN ROUTES
Functionality/Description: Any previously advertised routes
whose destinations are contained in this field SHALL be removed
from the Adj-RIB-In
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.36.185. WITHDRAWN ROUTES
Functionality/Description: The BGP speaker SHALL run its
Decision Process since the previously advertised route is no
longer available for use
RFC 2119: 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
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 68]
RFC 4276 BGP-4 Implementation Report January 2006
3.36.187. Other Feasible Routes
Functionality/Description: If an UPDATE message contains a
feasible route, and the NLRI of the new route is not identical
to the one of any route currently stored in the Adj-RIB-In, then
the new route SHALL be placed in the Adj-RIB-In
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.36.188. Adj-RIB-In Update
Functionality/Description: Once a BGP speaker updates the
Adj-RIB-In, it SHALL run its Decision Process
RFC 2119: 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 [RFC 4271]
3.37.189. Decision Process
Functionality/Description: Is your implementation compatible
with the description in this section?
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 69]
RFC 4276 BGP-4 Implementation Report January 2006
3.37.190. Degree of Preference
Functionality/Description: SHALL NOT use as its inputs any of
the following: the existence of other routes, the non-existence
of other routes, or the path attributes of other routes
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.38. Phase 1: Calculation of Degree of Preference / Section 9.1.1
[RFC 4271]
3.38.191. Ineligible Degree of Preference
Functionality/Description: The route MAY NOT serve as an input
to the next phase of route selection
RFC 2119: MAY NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.38.192. Eligible Degree of Preference
Functionality/Description: Used as the LOCAL_PREF value in any
IBGP re-advertisement
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 70]
RFC 4276 BGP-4 Implementation Report January 2006
3.39. Phase 2: Route Selection / Section 9.1.2 [RFC 4271]
3.39.193. Unresolvable NEXT_HOP
Functionality/Description: If the NEXT_HOP attribute of a BGP
route depicts an address that is not resolvable, or it would
become unresolvable if the route was installed in the routing
table the BGP route MUST be excluded
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.39.194. Routes Installed in LOC-RIB
Functionality/Description: The route in the Adj-RIBs-In
identified as the best (see section 9.1.2) is installed in the
Loc-RIB, replacing any route to the same destination that is
currently being held in the Loc-RIB
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.39.195. Immediate Next-Hop Address
Functionality/Description: MUST be determined from the NEXT_HOP
attribute of the selected route (see Section 5.1.3)
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 71]
RFC 4276 BGP-4 Implementation Report January 2006
3.39.196. Phase 2: Route Selection
Functionality/Description: Performed again if either the
immediate next hop or the IGP cost to the NEXT_HOP changes
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.39.197. Immediate Next-Hop Address
Functionality/Description: Used for packet forwarding
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.39.198. Unresolvable Routes
Functionality/Description: Removed from the Loc-RIB and the
routing table
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 72]
RFC 4276 BGP-4 Implementation Report January 2006
3.39.199. Unresolvable Routes
Functionality/Description: Kept in the corresponding Adj-RIBs-In
RFC 2119: 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 [RFC 4271]
3.40.200. Unresolvable Routes
Functionality/Description: Excluded from the Phase 2 decision
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.40.201. Multiple Matching Routes
Functionality/Description: Only the longest matching route
SHOULD be considered
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 73]
RFC 4276 BGP-4 Implementation Report January 2006
3.40.202. Mutual Recursion
Functionality/Description: If a route fails the resolvability
check because of mutual recursion, an error message SHOULD be
logged
RFC 2119: 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 [RFC 4271]
3.41.203. Tie-Breaking Criteria
Functionality/Description: Applied in the order specified
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.41.204. Algorithm Used
Functionality/Description: BGP implementations MAY use any
algorithm which produces the same results as those described
here
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 74]
RFC 4276 BGP-4 Implementation Report January 2006
3.41.205. MULTI_EXIT_DISC Removal
Functionality/Description: If done before re-advertising a route
into IBGP, then comparison based on the received EBGP
MULTI_EXIT_DISC attribute MAY still be performed
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.41.206. MULTI_EXIT_DISC Removal
Functionality/Description: The optional comparison on
MULTI_EXIT_DISC if performed at all MUST be performed only among
EBGP learned routes
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.41.207. MULTI_EXIT_DISC Comparison
Functionality/Description: Performed for IBGP learned routes
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 75]
RFC 4276 BGP-4 Implementation Report January 2006
3.42. Phase 3: Route Dissemination / Section 9.1.3 [RFC 4271]
3.42.208. Policy for processing routes from the Loc-RIB into
Adj-RIBs-Out
Functionality/Description: Exclude a route in the Loc-RIB from
being installed in a particular Adj-RIB-Out
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.42.209. Adj-Rib-Out Route Installation
Functionality/Description: Not unless the destination and
NEXT_HOP described by this route may be forwarded appropriately
by the Routing Table
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.42.210. Withdraw Routes
Functionality/Description: If a route in Loc-RIB is excluded
from a particular Adj-RIB-Out the previously advertised route in
that Adj-RIB-Out MUST be withdrawn from service by means of an
UPDATE message (see 9.2)
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 76]
RFC 4276 BGP-4 Implementation Report January 2006
3.43. Overlapping Routes / Section 9.1.4 [RFC 4271]
3.43.211. Overlapping Routes
Functionality/Description: Consider both routes based on the
configured acceptance policy
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.43.212. Accepted Overlapping Routes
Functionality/Description: The Decision Process MUST either
install both routes or...
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.43.213. Accepted Overlapping Routes
Functionality/Description: Aggregate the two routes and install
the aggregated route, provided that both routes have the same
value of the NEXT_HOP attribute
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We install both in Local RIB.
Laurel Y/N/O/Comments: N no automatic aggregation
NextHop Y/N/O/Comments: N no automatic aggregation
Hares & Retana Informational [Page 77]
RFC 4276 BGP-4 Implementation Report January 2006
3.43.214. Aggregation
Functionality/Description: Either include all ASs used to form
the aggregate in an AS_SET or add the ATOMIC_AGGREGATE
attribute to the route
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.43.215. De-Aggregation
Functionality/Description: Routes SHOULD NOT be de-aggregated
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.43.216. Route with the ATOMIC_AGGREGATE Attribute
Functionality/Description: Not de-aggregated
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 78]
RFC 4276 BGP-4 Implementation Report January 2006
3.44. Update-Send Process / Section 9.2 [RFC 4271]
3.44.217. UPDATE Message Received from an Internal Peer
Functionality/Description: Not re-distribute the routing
information to other internal peers, unless the speaker acts as
a BGP Route Reflector [RFC 2796]
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.44.218. No Replacement Route
Functionality/Description: All newly installed routes and all
newly unfeasible routes for which there is no replacement route
SHALL be advertised to its peers by means of an UPDATE message
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.44.219. Previously Advertised Routes
Functionality/Description: A BGP speaker SHOULD NOT advertise a
given feasible BGP route if it would produce an UPDATE message
containing the same BGP route as was previously advertised
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 79]
RFC 4276 BGP-4 Implementation Report January 2006
3.44.220. Unfeasible Routes
Functionality/Description: Removed from the Loc-RIB
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.44.221. Changes to Reachable Destinations
Functionality/Description: Changes to the reachable destinations
within its own autonomous system SHALL also be advertised in an
UPDATE message
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.44.222. A single route doesn't fit into the UPDATE message
Functionality/Description: Don't advertise
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.44.223. A single route doesn't fit into the UPDATE message
Functionality/Description: Log an error local
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 80]
RFC 4276 BGP-4 Implementation Report January 2006
3.45. Frequency of Route Advertisement / Section 9.2.1.1 [RFC 4271]
3.45.224. MinRouteAdvertisementIntervalTimer
Functionality/Description: Minimum separation between two UPDATE
messages sent by a BGP speaker to a peer that advertise feasible
routes and/or withdrawal of unfeasible routes to some common set
of destinations
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.45.225. Fast Convergence
Functionality/Description: MinRouteAdvertisementIntervalTimer
used for internal peers SHOULD be shorter than the
MinRouteAdvertisementIntervalTimer used for external peers, or
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: O Configurable on per peer basis.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N they are same for ebgp and ibgp
NextHop Y/N/O/Comments: Y Configuration option allows to set
the time per peer.
3.45.226. Fast Convergence
Functionality/Description: The procedure describes in this
section SHOULD NOT apply for routes sent to internal peers
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: O Operator has to ensure that through
configuration.
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y Default setting is off for BGP
peers.
Hares & Retana Informational [Page 81]
RFC 4276 BGP-4 Implementation Report January 2006
3.45.227. MinRouteAdvertisementIntervalTimer
Functionality/Description: The last route selected SHALL be
advertised at the end of MinRouteAdvertisementIntervalTimer
RFC 2119: 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 [RFC 4271]
3.46.228. MULTI_EXIT_DISC
Functionality/Description: Routes that have different
MULTI_EXIT_DISC attribute SHALL NOT be aggregated
RFC 2119: SHALL NOT
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
3.46.229. AS_SET as the First Element
Functionality/Description: If the aggregated route has an AS_SET
as the first element in its AS_PATH attribute, then the router
that originates the route SHOULD NOT advertise the
MULTI_EXIT_DISC attribute with this route
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 82]
RFC 4276 BGP-4 Implementation Report January 2006
3.46.230. NEXT_HOP
Functionality/Description: When aggregating routes that have
different NEXT_HOP attribute, the NEXT_HOP attribute of the
aggregated route SHALL identify an interface on the BGP speaker
that performs the aggregation
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.231. ORIGIN INCOMPLETE
Functionality/Description: Used if at least one route among
routes that are aggregated has ORIGIN with the value INCOMPLETE
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.232. ORIGIN EGP
Functionality/Description: Used if at least one route among
routes that are aggregated has ORIGIN with the value EGP
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 83]
RFC 4276 BGP-4 Implementation Report January 2006
3.46.233. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: The aggregated AS_PATH attribute
SHALL satisfy all of the following conditions: ...
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.234. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: All tuples of type AS_SEQUENCE in the
aggregated AS_PATH SHALL appear in all of the AS_PATH in the
initial set of routes to be aggregated
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.235. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: All tuples of type AS_SET in the
aggregated AS_PATH SHALL appear in at least one of the AS_PATH
in the initial set
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 84]
RFC 4276 BGP-4 Implementation Report January 2006
3.46.236. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: For any tuple X of type AS_SEQUENCE
in the aggregated AS_PATH which precedes tuple Y in the
aggregated AS_PATH, X precedes Y in each AS_PATH in the initial
set which contains Y, regardless of the type of Y
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.237. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: No tuple of type AS_SET with the same
value SHALL appear more than once in the aggregated AS_PATH
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.238. Routes to be aggregated have different AS_PATH attributes
Functionality/Description: Multiple tuples of type AS_SEQUENCE
with the same value may appear in the aggregated AS_PATH only
when adjacent to another tuple of the same type and value
RFC 2119: N/A
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 85]
RFC 4276 BGP-4 Implementation Report January 2006
3.46.239. AS_PATH Aggregation Algorithm
Functionality/Description: Able to perform the (minimum)
algorithm described in 9.2.2.2.
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N We don't do merging.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.240. ATOMIC_AGGREGATE
Functionality/Description: The aggregated route SHALL have this
attribute if at least one of the routes to be aggregated has it
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.46.241. AGGREGATOR
Functionality/Description: Attribute from routes to be
aggregated MUST NOT be included in aggregated route
RFC 2119: MUST NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 86]
RFC 4276 BGP-4 Implementation Report January 2006
3.46.242. AGGREGATOR
Functionality/Description: Attach a new one when aggregating
(see Section 5.1.7)
RFC 2119: 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 [RFC 4271]
3.47.243. Unstable Routes
Functionality/Description: Avoid using them
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.47.244. Route Changes
Functionality/Description: SHOULD NOT make rapid spontaneous
changes to the choice of route
RFC 2119: SHOULD NOT
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 87]
RFC 4276 BGP-4 Implementation Report January 2006
3.48. Originating BGP Routes / Section 9.4 [RFC 4271]
3.48.245. Non-BGP Acquired Routes
Functionality/Description: Distributed to other BGP speakers
within the local AS as part of the update process
(see Section 9.2)
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.48.246. Non-BGP Acquired Routes
Functionality/Description: Distribution controlled via
configuration
RFC 2119: 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 [RFC 4271]
3.49.247. Optional Timers
Functionality/Description: Two optional timers MAY be supported:
DelayOpenTimer, IdleHoldTimer by BGP
RFC 2119: MAY
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: O We support DelayOpenTimer but not
IdleHoldTimer
Laurel Y/N/O/Comments: Y support IdleHoldTimer but not the
DelayOpenTimer
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 88]
RFC 4276 BGP-4 Implementation Report January 2006
3.49.248. Hold Time
Functionality/Description: Configurable on a per peer basis
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.49.249. Timers
Functionality/Description: Allow the other timers to be
configurable
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.49.250. Jitter
Functionality/Description: Applied to the timers associated with
MinASOriginationInterval, KeepAlive,
MinRouteAdvertisementInterval, and ConnectRetry
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: O We only apply to ConnectRetry.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 89]
RFC 4276 BGP-4 Implementation Report January 2006
3.49.251. Jitter
Functionality/Description: Apply the same jitter to each of
these quantities regardless of the destinations to which the
updates are being sent; that is, jitter need not be configured
on a "per peer" basis
RFC 2119: MAY
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y We apply same only for connectretry.
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.49.252. Default Amount of jitter
Functionality/Description: Determined by multiplying the base
value of the appropriate timer by a random factor which is
uniformly distributed in the range from 0.75 to 1.0
RFC 2119: SHALL
Alcatel Y/N/O/Comments: Y Range is 0.9 to 1.1
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
3.49.253. Default Amount of jitter
Functionality/Description: New random value picked each time the
timer is set
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 90]
RFC 4276 BGP-4 Implementation Report January 2006
3.49.254. Jitter Random Value Range
Functionality/Description: Configurable
RFC 2119: MAY
Alcatel Y/N/O/Comments: N
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: N
3.50. TCP Options that May Be Used with BGP / Appendix E [RFC 4271]
3.50.255. TCP PUSH Function Supported
Functionality/Description: Each BGP message SHOULD be
transmitted with PUSH flag set
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O Depends on the TCP stack support.
GateD 10, NGC can run over
multiple stacks.
3.50.256. Differentiated Services Code Point (DSCP) Field Support
Functionality/Description: TCP connections opened with bits 0-2
of the DSCP field set to 110 (binary)
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: O Depends on the TCP stack support.
GateD 10, NGC can run over
multiple stacks.
Hares & Retana Informational [Page 91]
RFC 4276 BGP-4 Implementation Report January 2006
3.51. Reducing Route Flapping / Appendix F.2 [RFC 4271]
3.51.257. Avoid Excessive Route Flapping
Functionality/Description: A BGP speaker which needs to withdraw
a destination and send an update about a more specific or less
specific route SHOULD combine them into the same UPDATE message
RFC 2119: SHOULD
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: N
Laurel Y/N/O/Comments: N
NextHop Y/N/O/Comments: N
3.52. Complex AS_PATH aggregation / Appendix F.6 [RFC 4271]
3.52.258. Multiple Instances in AS_PATH
Functionality/Description: The last instance (rightmost
occurrence) of that AS number is kept
RFC 2119: 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 [RFC 4271]
3.53.259. Authentication Mechanism
Functionality/Description: A BGP implementation MUST support
the authentication mechanism specified in RFC 2385 [RFC 2385].
RFC 2119: MUST
Alcatel Y/N/O/Comments: Y
Cisco Y/N/O/Comments: Y
Laurel Y/N/O/Comments: Y
NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 92]
RFC 4276 BGP-4 Implementation Report January 2006
4. Additional BGP Implementations Information
Three implementations responded to a call (5/20/04-6/2/04) for
information on those implementations that had a BGP implementation,
but did not complete the full survey. The responses for the call for
additional information are below.
4.1. Avici
If you have an implementation of BGP and you did not send in an
implementation report (answering the 259 questions), could you send
me the answer the following questions:
1) BGP product
Contributor (your name):Curtis Villamizar [curtis@fictitious.org]
Company: Avici
name of product: IPriori (TM)
minor version: No interoperability problems with any version.
Current deployed versions are 5.x and 6.0.x.
Version 6.1 and beyond are tested against the
latest BGP specification [RFC 4271].
2) What other implementations you interoperate with.
Cisco: IOS 12.0(22)
Juniper: JUNOS (version not given)
3) Do you inter-operate with:
1) Alcatel BGP (release) - not tested
2) cisco BGP IOS 12.0(27)s - not tested
tested with IOS 12.0(22); BGP is the same
3) laurel BGP (specify release) - not tested
4) NextHop GateD - not tested
4) Did the length of the survey for BGP cause you to not
submit the BGP implementation report?
yes
Hares & Retana Informational [Page 93]
RFC 4276 BGP-4 Implementation Report January 2006
4.2. Data Connection Ltd.
If you have an implementation of BGP and you did not send in an
implementation report (answering the 259 questions), could you send
me the answer the following questions:
1) BGP product
Contributor (your name): Mike Dell
Company: Data Connection Ltd.
name of product: DC-BGP
version and minor of software: v1.1
release date: April 2003
2) What other implementations you interoperate with.
Cisco (12.0(26)S)
Alcatal (7770 0BX)
Agilent (Router Tester)
Ixia (1600T)
Netplane (Powercode)
Nortel (Shasta 5000 BSN)
Redback (SmartEdge 800)
Riverstone (RS8000)
Spirent (AX4000)
IP Infusion (ZebOs)
Nokia (IP400)
Juniper (M5)
3) Do you inter-operate with
1) Alcatel BGP (release) YES
2) cisco BGP IOS 12.0(27)s
Unknown, but we do inter-operate with v12.0(26)s
3) laurel BGP (specify release) Unknown
4) NextHop GateD YES
4) Did the length of the survey for BGP
cause you to not submit the BGP
implementation report?
YES
4.3. Nokia
If you have an implementation of BGP and you did not send in an
implementation report (answering the 259 questions), could you send
me the answer the following questions:
Hares & Retana Informational [Page 94]
RFC 4276 BGP-4 Implementation Report January 2006
1) BGP product
Contributor (your name):Rahul Bahadur
(rahul.bahadur@nokia.com)
Company: Nokia
Name of product: IP Security Platforms
Version and minor of software IPSO 3.8 Build031
Release date May 24, 2004
2) What other implementations you interoperate with.
Cisco: IOS 12.3(1)
Extreme: Extremeware Version 6.1.7 (Build 9)
Foundry: SW Version 07.5.05iT53
Juniper: JUNOS 5.3R1.2
Nortel: BayRS 15.4.0.1
GNU Zebra: zebra-0.92a
3) Do you inter-operate with
1) Alcatel BGP (release) - not tested
2) cisco BGP IOS 12.0(27)s - yes
3) laurel BGP (specify release) - not tested
4) NextHop GateD - not tested
4) Did the length of the survey for BGP
cause you to not submit the BGP implementation report?
Yes - lack of resources to help with task.
5. Security Considerations
This document does not address any security issues.
6. Normative References
[RFC 4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC 1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
Hares & Retana Informational [Page 95]
RFC 4276 BGP-4 Implementation Report January 2006
[RFC 2796] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection
- An Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[RFC 2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
[RFC 3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 3065, February 2001.
7. Acknowledgements
Alcatel responses provided by:
Contact Name: Devendra Raut
Contact EMail: Devendra.raut@Alcatel.com
Cisco Systems responses provided by:
Contact Name: Himanshu Shah, Ruchi Kapoor
Contact EMail: hhshah@cisco.com, ruchi@cisco.com
Laurel responses provided by:
Contact Name: Manish Vora
Contact EMail: vora@laurelnetworks.com
NextHop responses provided by:
Contact Name: Susan Hares
Contact EMail: skh@nexthop.com
Additional Help: Matt Richardson, Shane Wright.
Authors' Addresses
Susan Hares
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108
Phone: 734.222.1610
EMail: skh@nexthop.com
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
Phone: 919 392 2061
EMail: aretana@cisco.com
Hares & Retana Informational [Page 96]
RFC 4276 BGP-4 Implementation Report January 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hares & Retana Informational [Page 97]