Network Working Group S. Hares Request for Comments: 4276 NextHop Category: Informational A. Retana Cisco January 2006
BGP-4 Implementation Report
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document reports the results of the BGP-4 implementation survey. The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, and NextHop) and brief information from three that did not (Avici, Data Connection Ltd., and Nokia).
The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on.
Table of Contents
1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................4 2. Results of Survey ...............................................4 2.1. Significant Differences ....................................4 2.2. Overview of Differences ....................................5 2.3. Implementations and Interoperability .......................6 2.4. BGP Implementation Identification ..........................7 3. BGP-4 Implementation Report .....................................7 3.0. Summary of Operation / Section 3 [RFC4271] .................7 3.1. Routes: Advertisement and Storage / Section 3.1 [RFC4271] ..8 3.2. Routing Information Bases / Section 3.2 [RFC4271] ..........9 3.3. Message Formats / Section 4 [RFC4271] ......................9 3.4. Message Header Format / Section 4.1 [RFC4271] .............10
This document reports results from a survey of implementations of BGP-4 as specified in [RFC4271]. RFC 4271 is in alignment with current deployments of BGP-4 and obsoletes the BGP standard [RFC1771]. BGP is a widely deployed cornerstone of Internet technology that continues to add additional functionality as the needs of the Internet evolve. As deployed in the Internet, BGP-4 encompasses both this base specification and additional specifications such as TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065], and BGP Route Refresh [RFC2918].
The BGP-4 implementation survey had 259 detailed questions about compliance with [RFC4271]. Four implementers (Alcatel, Cisco, Laurel, and NextHop) completed the survey. Section 3 provides a compilation of those results.
Section 2.1 highlights significant differences and Section 2.2 provides an overview of the differences between the four implementations. Section 2.3 provides interoperability information.
Due to the large number of BGP implementations and the small number of respondents, the editors took an informal survey to determine if the length of the original survey caused implementers not to submit it. Three implementers responded, and all indicated the length of the survey was the issue. Section 4 gives the results of this informal survey.
Hares & Retana Informational [Page 3]
RFC 4276 BGP-4 Implementation Report January 2006
In this document, the editors have compiled the results of the implementation survey results and the informal survey.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The respondents replied "Y" (yes) or "N" (no) to the survey's 259 questions to indicate whether their implementation supports the Functionality/Description of the [RFC2119] language in [RFC4271]. The respondents replied "O" (other) to indicate that the support is neither "Y" nor "N" (for example, an alternate behavior).
Each question received affirmative responses from at least two implementers (i.e., two "Y" responses, or one "Y" and one "O"), except the following questions:
a) MUST - Linked Questions 212/213, regarding Section 9.1.4
Due to the format of the linked questions, three vendors (Cisco, Laurel, and NextHop) replied "N" to Question 213. (See Section 2.2 for details.)
b) SHALL NOT - Question 228, regarding Section 9.2.2.2
Three vendors (Alcatel, Cisco, and Laurel) answered "N" to SHALL NOT (meaning they did). One vendor (NextHop) indicated "O" matching the specification.
Text: Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be aggregated. (Section 9.2.2.2, [RFC4271])
c) SHOULD - Questions 257 and 258, regarding Appendix F
Three vendors answered "N" and one vendor answered "Y" to Question 257. All four vendors answered "N" to Question 258. (Please note that support of Appendix F, "Implementation Recommendations", is optional.)
Hares & Retana Informational [Page 4]
RFC 4276 BGP-4 Implementation Report January 2006
Text: A BGP speaker which needs to withdraw a destination and send an update about a more specific or less specific route SHOULD combine them into the same UPDATE message. (Appendix F.2, [RFC4271])
Text: The last instance (rightmost occurrence) of that AS number is kept. (Appendix F.6, [RFC4271])
d) MAY - Questions 180 and 254, regarding Sections 8.1.2.4 and 10
Three vendors answered "N", and 1 replied "Y" to Question 180.
Text: The Event numbers (1-28) utilized in this state machine description aid in specifying the behavior of the BGP state machine. Implementations MAY use these numbers to provide network management information. The exact form of a FSM or the FSM events are specific to each implementation. (Section 8.1.2.4, [RFC4271])
Editors' note: Section 8.1.2.4 was written to allow existing implementations to transition to the new event numbering. It was expected over time (3 years) that the FSM event numbering would be updated to the new numbering.
Three vendors answered "N" and one answered "Y" to Question 254 about configurable jitter time values.
Text: A given BGP speaker MAY apply the same jitter to each of these quantities regardless of the destinations to which the updates are being sent; that is, jitter need not be configured on a "per peer" basis. (Section 10, [RFC4271])
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):
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.
For every item listed, the respondents indicated whether their implementation supports the Functionality/Description or not (Y/N) according to the [RFC2119] language indicated. Any respondent comments are included. If appropriate, the respondents indicated with "O" the fact that the support is neither Y/N (an alternate behavior, for example). Refer to the appropriate sections in [RFC4271] for additional details. Note that the last digit of the subsection number is the number of the survey question.
Functionality/Description: To allow local policy changes to have the correct effect without resetting any BGP connections, a BGP speaker SHOULD either (a) retain the current version of the routes advertised to it by all of its peers for the duration of the connection, or (b) make use of the Route Refresh extension [RFC2918]
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
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
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
Alcatel Y/N/O/Comments: Y Withdrawn routes are processed before NLRI fields. Hence we get the desired behavior. Cisco Y/N/O/Comments: Y Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y
Hares & Retana Informational [Page 15]
RFC 4276 BGP-4 Implementation Report January 2006
3.7. KEEPALIVE Message Format / Section 4.4 [RFC4271]
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
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
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
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
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)
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
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)
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
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
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
Functionality/Description: An implementation MAY also (based on local configuration) alter the value of the MULTI_EXIT_DISC attribute received over EBGP
Functionality/Description: Calculated for each external route based on the locally configured policy, and included when advertising a route to its internal peers
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
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
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
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
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
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
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
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
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
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.
Functionality/Description: If any attribute appears more than once in the UPDATE message, then the Error Subcode MUST be set to Malformed Attribute List
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
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
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
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.
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)
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
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
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
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
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
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
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
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
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
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
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.
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.
Functionality/Description: If the state machine is to process this event in Established state, the CollisionDetectEstablishedState optional attribute SHOULD be set to TRUE
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.
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
Alcatel Y/N/O/Comments: Y Not visible to operator. Cisco Y/N/O/Comments: N Laurel Y/N/O/Comments: N NextHop Y/N/O/Comments: N Future Release of GateD NGC may support event numbers.
Hares & Retana Informational [Page 66]
RFC 4276 BGP-4 Implementation Report January 2006
3.35. Finite State Machine / Section 8.2.2 [RFC4271]
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
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
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
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
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
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
Alcatel Y/N/O/Comments: Y Cisco Y/N/O/Comments: O We have checks that disallow mutual recursion, so this won't happen. Laurel Y/N/O/Comments: Y NextHop Y/N/O/Comments: Y
3.41. Breaking Ties (Phase 2) / Section 9.1.2.2 [RFC4271]
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
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)
Functionality/Description: Aggregate the two routes and install the aggregated route, provided that both routes have the same value of the NEXT_HOP attribute
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
3.44.217. UPDATE Message Received from an Internal Peer
Functionality/Description: Not re-distribute the routing information to other internal peers, unless the speaker acts as a BGP Route Reflector [RFC2796]
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
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
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
Functionality/Description: MinRouteAdvertisementIntervalTimer used for internal peers SHOULD be shorter than the MinRouteAdvertisementIntervalTimer used for external peers, or
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.
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.
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
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
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
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
Alcatel 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
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
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
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
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)
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.
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
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.
If you have an implementation of BGP and you did not send in an implementation report (answering the 259 questions), could you send me the answer the following questions:
1) BGP product Contributor (your name):Curtis Villamizar [curtis@fictitious.org] Company: Avici name of product: IPriori (TM) minor version: No interoperability problems with any version.
Current deployed versions are 5.x and 6.0.x. Version 6.1 and beyond are tested against the latest BGP specification [RFC4271].
2) What other implementations you interoperate with.
Cisco: IOS 12.0(22) Juniper: JUNOS (version not given)
3) Do you inter-operate with:
1) Alcatel BGP (release) - not tested 2) cisco BGP IOS 12.0(27)s - not tested tested with IOS 12.0(22); BGP is the same 3) laurel BGP (specify release) - not tested 4) NextHop GateD - not tested
4) Did the length of the survey for BGP cause you to not submit the BGP implementation report?
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.
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?
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).