Implementation Report S. Hares (editor) NextHop July 2004 MP-BGP implementation Report Abstract This document provides a survey of the BGP implementations supporting the multi-protocol extensions as specified in ietf-idr-rfc2858bis-06.txt implementations. After a brief summary, each response is listed. The editor makes no claim as to the accuracy of the information provided. 1. Overview 1.1 General This draft provides a survey of BGP-4 implementations, as defined by [MP-BGP], that enable BGP to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc). These extensions are often denoted as MP-BGP. The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. The multi-protocol extensions for BGP are a widely deployed cornerstone of Internet technology. This survey had 15 detailed questions on the compliances with the standard. Of these 15 questions, 3 of the questions are informational (1, 10, and 15). Of the remaining 12 questions, one of the questions (2) has 5 parts, of which 3 are informational. The responses are listed in section 2, and the full survey is listed in section 3. 5 implementers from Cisco, Juniper, Laurel, NextHop, and Redback sent in implementation reports. 1.2 Full Survey result Significant Differences Of the 12 standards related questions, all questions had 2 or more Yes responses. (Note question 2e - has the "O" response indicating support for the attribute, but no support for SNPA). Of the informational questions: Question 1: Can your MPBGP support be configured to be "off"? Cisco, Juniper, NextHOP and Redback indicated that the MP-BGP Status could be configured off. Laurel indicated that MP-BGP could not be configured off. Questions 10: The actions upon more than one AFI/SAFI in MP-BGP UPDATE messages is undefined. What action do you take? Cisco: Takes the last AFI/SAFI in packet Juniper: Processes AFI/SAFIs in order received Laurel: Processes Withdraws, MP_REACH_NLRI, MP_UNREACH_NLRI, NLRI NextHop: Processes Withdraws, MP_UNREACH_NLRI, MP_REACH_NLRI, NLRI Redback: Processes last instance Question 15: What SAFIs are supported: (for IPv4, or IPv6) SAFIs 0-2 3 4 5-63 63-127 128-255 ================================ Cisco Y R Y N N 128 Juniper Y N Y N N 128 Laurel Y N N N N 128 NextHop Y R Y N N 128 Redback Y N Y N NA NA Y - support send/receive R - only support receive NA - not answered 1.3 Summary of questions The following section provides a list of sections where all answers were not "yes" to RFC 2119 questions (2-9, 11-14). This section is provided to allow the reader a short cut to the interesting points. SHOULD: 1) Question 4: Use of NextHop in MP_REACH_NLRI attribute Yes: Cisco, Laurel, NextHop, Redback No: Juniper 2) Question 8: Ignore Update message with no NLRI other than MP_REACH_NLRI and with NEXT_HOP Yes: Juniper, Laurel, NextHop, Redback Optional: Cisco SHOULD NOT: 1) Question 7: Update message with no NLRI, other than the one coded in MP_REACH_NLRI attribute SHOULD NOT carry the NextHop Attribute. Yes: Juniper, Laurel, NextHop, Redback Optional: Cisco Please note, that Cisco has an optional setting that matches all other implementations for questions 4,7, and 8. 1.4 Implementations and interoperability Cisco Juniper Laurel NextHop Redback ======================================= Cisco - Y Y Y Y Juniper Y - - Y - Laurel Y Y - Y NextHop Y Y - - - Redback Y Y - - - 1.5 BGP Implementation Identification 1.5.1 Cisco Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S Date: 11/26/2003 1.5.2 Juniper Implementation Name/Version: JUNOS 6.4 Date: June 2004 1.5.3 Laurel Implementation Name/Version: Laurel Networks Release 3.0 Date: May 2004 1.5.4 NextHop Technologies Implementation Name/Version: Gated NGC 2.0, 2.2 Date: January 2004 1.5.5 Redback Implementation Name/Version: SEOS-2.5.7 Date: May 2004 1.6 BGP Survey respondent 1.6.1 Cisco survey respondent: Russ White email: ruwhite@cisco.com time period: 5/09/02 - 6/15/04 1.6.2 Juniper survey respondent: Pedro Roque Marques email: roque@juniper.net time period: 5/03/02 - 6/15/04 1.6.3 Laurel survey respondent: Manish Vora email: mvora@laurelnetworks.com time period: 5/02/02 - 6/15/04 1.6.4 NextHop Technologies survey respondent: Susan Hares time period: 5/03/02 - 6/15/04 1.6.5 Redback survey respondent: Enke Chen email: enke@redback.com time period: 5/03/02 - 6/15/04 2. BGP4 Implementation Report For every item listed, the respondents indicated whether their implementation supports the Functionality/Description or not (Y/N) according to the [RFC2119] 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 the latest [MP-BGP] for additional details. 2.1 Implementation Survey Results This survey was first issued in May of 2002. This survey was reissued in February through May of 2004 to update the original responses to match the text in draft-ietf-idr-rfc2858bis-06.txt. The form of the questions has retained the original 2002 form, but some sub-sections have been added to match the current 2004 suggestions from the Routing AD and IESG on implementation reports. Each question indicates the status of the question as informational or RFC 2119. For descriptions of MAY/SHOULD/MUST see RFC 2119. Each question may also have questions attached. ----------------------------------------------------- 1) Can your MPBGP support be configured to be "off"? If your MP-BGP support can be turned off, does your implementation ignore information passed in MP_REACH_NLRI and MP_UNREACH_NLRI, and not pass it to other speakers. section: 4 text: "This way a BGP speaker that doesn't support the multiprotocol capabilities will just ignore the information carried in these attributes, and will not pass it to other BGP speakers." status: informational response: yes/no survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 2) Does your MPBGP support MP_REACH_NLRI and MP_UNREACH_NLRI for: a) IP Unicast forwarding? b) IP Multicast forwarding? [Assumed in the above two questions are the following questions: 2a) MP_REACH_NLRI section 5: "The MP_REACH_NLRI is an optional non-transitive attribute with Type code 14." 2b) MP_UNREACH_NLRI type is 15 section 6: "the MP_UNREACH_NLRI" is an optional non-transitive attribute with Type code 15." 2c) AFI values used are specified by RFC 1700 section 5: "Presently defined values for the Address Family Identifier field are specified in RFC1700 (see the Address Family Numbers." [Editor's note: RFC 1700 has be replaced by an online IANA database at www.iana.org.] 2d) SAFI MAY support all, some or none of the SAFIs section 5: "This document defines the following values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes: 1 - Network Layer Reachability Information used for unicast forwarding 2 - Network Layer Reachability Information used for multicast forwarding. An implementation MAY support all, some, or none of the Subsequent Address Family Identifier values defined in this document." 2e) SNPA padding of odd semi-octets is done in all zeros section 5: "If the SNPA contains an odd number of semi-octets, a value in this field will be padded with a trailing all-zero semi-octet." status: 2a-2c informational, 2d-2e - RFC 2119 response: yes/no/optional survey results: 2a 2b 2c 2d 2e Comments ============================================ Cisco y y y y y 2e: no SNPAs sent Juniper y y y y y 2e: no SNPAs sent Laurel y y y y y 2e: No SNPAs sent NextHop y y y y y Redback y y y y y 2d comments: Cisco: (1) Unicast and (2) Multicast 3) No SNPAs listed in MP_UNREACH_NLRI section 5: "The value 0 SHALL be used to indicate that no SNPAs are listed in this attribute." status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: yes comment: No SNPAs are sent Laurel: yes comment: No SNPAs are sent NextHop: yes Redback: yes comment: No SNPAs are sent 4) MPBGP NextHop field section 5: "The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the border router that SHOULD be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message." status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: no Laurel: yes NextHop: yes Redback: yes 5) MPBGP update with messages that carries no NLRI other than in the MPBGP attribute section 5: "An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges)." status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 6) IBGP Update messages must carry LOCAL_PREF with MP_REACH_NLRI section 5: "Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute. " status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 7) Update with no NLRI other than MP_REACH_NLRI SHOULD NOT carry the NEXT_HOP attribute section 5: "An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute." status: RFC 2119 response: yes/no/optional survey results: Cisco: Optional Comment: SAFI 1: only NEXT_HOP for IPv4 SAFI 2: NextHop for MP_REACH_NLRI and normal NLRIs, Other SAFIs - no NEXT_HOP Juniper: yes Laurel: yes NextHop: yes - Allows option to work around other vendors bug. Redback: yes - Allows option to work around other vendors bug. 8) Reception of an UPDATE with no NLRI other than MP_REACH_NLRI and NEXT_HOP attribute section 5: "If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute." status: RFC 2119 response (yes/no/optional): survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes - Allows option to work around other vendors bug. 9) Only one instance of AFI/SAFI Section 5: "An UPDATE message SHOULD NOT include the same address prefix (of the same ) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field." status: RFC 2119 response (yes/no/optional): survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 10) Processing of more than one instance of AFI/SAFI is undefined: Section 5: "Processing of such an update in this form is undefined." What happens if you receive more than one AFI/SAFI? status: informational response: (comments only) Cisco: Takes the last AFI/SAFI in packet Juniper: Processes AFI/SAFIs in order received Laurel: Processes Withdraws, MP_REACH_NLRI, MP_UNREACH_NLRI, NLRI NextHop: Processes Withdraws, MP_UNREACH_NLRI, MP_REACH, NLRI Redback: Process last instance [Editor's note: The sentence in question 10 follows the text in question 9. Please refer to the [MP-BGP] specification for the full text.] 11) Does your BGP implementation, upon receiving an update with an incorrect MP_REACH_NLRI or MP_UNREACH_NLRI: a) delete all routes from that same SAFI/AFI? Section 9: "If a BGP speaker receives from a neighbor an Update message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the speaker determines that the attribute is incorrect, the speaker MUST delete all the BGP routes received from that neighbor whose AFI/SAFI is the same as the one carried in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute." b) Ignore all subsequent routes with that AFI/SAFI? [SHOULD], or Section 9: "For the duration of the BGP session over which the Update message was received, the speaker then SHOULD ignore all the subsequent routes with that AFI/SAFI received over that session." c) Terminate the session? [MAY] with "Update Message Error"/"Optional Attribute Error". Section 9: "In addition, the speaker MAY terminate the BGP session over which the Update message was received." d) (if terminated) Section 9: "The session SHOULD be terminated with the Notification message code/subcode indicating "Update Message Error"/"Optional Attribute Error". status: RFC 2119 response: yes/no/optional survey results: 11a 11b 11c 11d ==================== Cisco y y y y Juniper y y y y Laurel y y y y NextHop y y y y Redback y y y y 12) Does the BGP use the BGP Capability advertisement to determine whether the speaker can use MP extensions with a peer? section 10: "A BGP speaker that uses Multiprotocol Extensions SHOULD use the Capability Advertisement procedures [BGP-CAP] to determine whether the speaker could use Multiprotocol Extensions with a particular peer." status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 13) Are the fields: afi, res, safi in the Capability announcement have Res. (reserved) set to zero by the sender and ignored by the receiver? section 10: "Res. - Reserved (8 bit) field. Should be set to 0 by the sender and ignored by the receiver." status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 14) Do you support bi-directional exchange via cross advertisement of capabilities? section 10: "To have a bi-directional exchange of routing information for a particular between a pair of BGP speakers, each such speaker MUST advertise to the other (via the Capability Advertisement mechanism) the capability to support that particular routes." status: RFC 2119 response: yes/no/optional survey results: Cisco: yes Juniper: yes Laurel: yes NextHop: yes Redback: yes 15) What ranges of SAFI are supported in your implementation: a) SAFI 0 - reserved b) SAFI 1-2 - defined by document c) SAFI 3 - no longer defined by draft d) SAFI 4-63 - IANA Assigned, IETF consensus e) SAFI 64-127 - IANA Assigned, f) SAFI 128-255 - private use status: informational only response: (per a-f comment: yes/no) survey response: SAFIs 0-2 3 4 5-63 63-127 128-255 ================================ Cisco Y R Y N N 128 Juniper Y N Y N N 128 Laurel Y N N N N 128 NextHop Y R Y N N 128 Redback Y N Y N NA NA Y - support send/receive R - only support receive NA - not answered 16) What other implementations do you inter-operate with? status: informational response: comments survey results: Cisco: most implementations Juniper: most implementations Laurel: Cisco, Juniper, Redback NextHop: Cisco, Juniper Redback: Cisco, Juniper 3. Survey Form (Survey version: 4) Contributor: Company: Software: Release: Date: ----------------------------------------------- Instructions: This survey was first issue in 5/2002. I am re-issuing this survey for any new participants. The form of the questions has retained it's original 2002 form, but some sub-sections have been added to match the current 2004 suggestions from the Routing AD and IESG on implementation reports. For descriptions of MAY/SHOULD/MUST see RFC 2026. Questions without MAY/SHOULD/MUST in the section text are informational only and are not required for a conformant implementation. 1) Can your MPBGP support be configured to be "off"? If your MP-BGP support can be turned off, does your implementation ignore information passed in MP_REACH_NLRI and MP_UNREACH_NLRI, and not pass it to other speakers. section: 4 text: "This way a BGP speaker that doesn't support the multiprotocol capabilities will just ignore the information carried in these attributes, and will not pass it to other BGP speakers." response: (yes/no/optional) status: informational comments: 2) Does your MPBGP support MP_REACH_NLRI and MP_UNREACH_NLRI for: a) IP Unicast forwarding? b) IP Multicast forwarding? [Assumed in the above two questions are the following questions: 2a) MP_REACH_NLRI section 5: "The MP_REACH_NLRI is an optional non-transitive attribute with Type code 14." 2b) MP_UNREACH_NLRI type is 15 section 6: "the MP_UNREACH_NLRI" is an optional non-transitive attribute with Type code 15." 2c) AFI values used are specified by RFC 1700 section 5: "Presently defined values for the Address Family Identifier field are specified in RFC1700 (see the Address Family Numbers." 2d) SAFI MAY support all, some or none of the SAFIs section 5: "This document defines the following values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes: 1 - Network Layer Reachability Information used for unicast forwarding 2 - Network Layer Reachability Information used for multicast forwarding. An implementation MAY support all, some, or none of the Subsequent Address Family Identifier values defined in this document." 2e) SNPA padding of odd semi-octets is done in all zeros section 5: "If the SNPA contains an odd number of semi-octets, a value in this field will be padded with a trailing all-zero semi-octet." status: 2a-2c informational, 2d-2e - RFC 2119 response: (yes/no/optional) comments: 3) No SNPAs listed in MP_UNREACH_NLRI section 5: "The value 0 SHALL be used to indicate that no SNPAs are listed in this attribute." status: RFC 2119 response: (yes/no/optional) comments: 4) MPBGP NextHop field section 5: "The next hop information carried in the MP_REACH_NLRI path attribute defines the Network Layer address of the border router that SHOULD be used as the next hop to the destinations listed in the MP_NLRI attribute in the UPDATE message." status: RFC 2119 response: (yes/no/optional) 5) MPBGP update with messages that carries no NLRI other than in the MPBGP attribute section 5: "An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges)." status: RFC 2119 response: (yes/no/optional) comments: 6) IBGP Update messages must carry LOCAL_PREF with MP_REACH_NLRI section 5: "Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute." status: RFC 2119 response: (yes/no/optional) comments: 7) Update with no NLRI other than MP_REACH_NLRI SHOULD NOT carry the NEXT_HOP attribute section 5: "An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute." status: RFC 2119 response: (yes/no/optional) comments: 8) Reception of an UPDATE with no NLRI other than MP_REACH_NLRI and NEXT_HOP attribute section 5: "If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute." status: RFC 2119 response (yes/no/optional): comments: 9) Only one instance of AFI/SAFI Section 5: "An UPDATE message SHOULD NOT include the same address prefix (of the same ) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field." status: RFC 2119 response (yes/no/optional): comments: 10) Processing of more than one instance of AFI/SAFI is undefined: Section 5: "Processing of such an update in this form is undefined." What happens if your receive more than one AFI/SAFI? response: (comments only) status: informational 11) Does your BGP implementation, upon receiving an update with an incorrect MP_REACH_NLRI or MP_UNREACH_NLRI a) delete all routes from that same SAFI/AFI? section 9: "If a BGP speaker receives from a neighbor an Update message that contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the speaker determines that the attribute is incorrect, the speaker MUST delete all the BGP routes received from that neighbor whose AFI/SAFI is the same as the one carried in the incorrect MP_REACH_NLRI or MP_UNREACH_NLRI attribute." b) Ignore all subsequent routes with that AFI/SAFI? [SHOULD], or Section 9: "For the duration of the BGP session over which the Update message was received, the speaker then SHOULD ignore all the subsequent routes with that AFI/SAFI received over that session." c) Terminate the session? [MAY] with "Update Message Error"/"Optional Attribute Error". Section 9: "In addition, the speaker MAY terminate the BGP session over which the Update message was received." d) (if terminated) Section 9: "The session SHOULD be terminated with the Notification message code/subcode indicating "Update Message Error"/"Optional Attribute Error". response:(yes/no/optional) (respond to 11a-11d) status: RFC 2119 12) Does the BGP use the BGP Capability advertisement to determine whether the speaker can use MP extensions with a peer? section 10: "A BGP speaker that uses Multiprotocol Extensions SHOULD use the Capability Advertisement procedures [BGP-CAP] to determine whether the speaker could use Multiprotocol Extensions with a particular peer." [BGP-CAP] "Capabilities Advertisement with BGP-4", R. Chandra, J. Scudder, RFC2842, May 2000 status: RFC 2119 response(yes/no/optional): comments: 13) Are the fields: afi, res, safi in the Capability announcement have Res. (reserved) set to zero by the sender and ignored by the receiver? section 10: "Res. - Reserved (8 bit) field. Should be set to 0 by the sender and ignored by the receiver." status: RFC 2119 response (yes/no/optional): comments: 14) Do you support bi-directional exchange via cross advertisement of capabilities? section 10: "To have a bi-directional exchange of routing information for a particular between a pair of BGP speakers, each such speaker MUST advertise to the other (via the Capability Advertisement mechanism) the capability to support that particular routes." status: RFC 2119 response (yes/no/optional): comments: 15) What ranges of SAFI are supported in your implementation: a) SAFI 0 - reserved b) SAFI 1-2 - defined by document c) SAFI 3 - no longer defined by draft d) SAFI 4-63 - IANA Assigned, IETF consensus e) SAFI 64-127 - IANA Assigned, f) SAFI 128-255 - private use response: (per a-f comment: yes/no) status: informational only 16) What other implementations do you inter-operate with? response: status: informational only Normative References [MP-BGP] Bates, T., Chandra, R. , Katz, D., Rekhter, Y., "Multiprotocol Extensions for BGP-4", draft-ietf-idr-rfc2858bis-06.txt, May 2004 [BGP-CAP] "Capabilities Advertisement with BGP-4", R. Chandra, J. Scudder, RFC2842, May 2000 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, February 2004 [RFC3668] Bradner, S. "Intellectual Property Rights in IETF Technology", BCP 79, February 2004 Acknowledgments My thanks to Russ White (Cisco), Pedro Marques (Juniper), Manish Vora (Laurel Networks), and Enke Chen (Redback) for responding to lots of email regarding this survey. My thanks to Matt Richardson and Jeff Haas of NextHop for help with the NextHop Survey form. My thanks to Jeff Haas and Dave Hares on editorial comments. Author's Addresses Susan Hares NextHop Technologies 825 Victors Way, Suite 100 Phone: 734.222.1610 Email: skh@nexthop.com