Inter-Domain Working Group Internet Draft S. Hares (editor) Document: draft-hares-idr-rfc2858bis-survey-00.txt NextHop Expires: December 2004 July 2004 MP-BGP implementation Report Status of this Memo Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Abstract This document provides a survey of the BGP 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. Hares Expires - December 2004 ^L draft-ietf-idr-2858bis Survey Report July 2004 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 [1]. TABLE of CONTENTS 1. Overview.......................................................2 1.1 General....................................................2 1.2 Full Survey result.........................................3 1.3 Summary of questions.......................................3 1.4 Implementations and interoperability.......................4 1.5 BGP Implementation Identification..........................4 1.6 BGP Survery respondant.....................................5 2. BGP4 Implementation Report.....................................5 2.1 Implementation Survey Results..............................6 3. Survey Form...................................................13 4. Security Considerations.......................................19 Normative References.............................................19 Acknowledgments..................................................19 Author's Addresses...............................................20 Intellectual Property Statement..................................20 Copyright Statement..............................................21 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. Hares Expires - December 2004 [Page 2] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Hares Expires - December 2004 [Page 3] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Hares Expires - December 2004 [Page 4] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Survery respondant 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. Hares Expires - December 2004 [Page 5] ^L draft-ietf-idr-2858bis Survey Report July 2004 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." Hares Expires - December 2004 [Page 6] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Hares Expires - December 2004 [Page 7] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 caries 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 Hares Expires - December 2004 [Page 8] ^L draft-ietf-idr-2858bis Survey Report July 2004 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. Hares Expires - December 2004 [Page 9] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Hares Expires - December 2004 [Page 10] ^L draft-ietf-idr-2858bis Survey Report July 2004 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"/"Optinal 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 Advertisment 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 Hares Expires - December 2004 [Page 11] ^L draft-ietf-idr-2858bis Survey Report July 2004 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: Hares Expires - December 2004 [Page 12] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 (Survery version: 4) Contributor: Company: Software: Release: Date: ----------------------------------------------- Instructions: Hares Expires - December 2004 [Page 13] ^L draft-ietf-idr-2858bis Survey Report July 2004 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." Hares Expires - December 2004 [Page 14] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 caries no NLRI other than in the MPBGP attribute Hares Expires - December 2004 [Page 15] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Hares Expires - December 2004 [Page 16] ^L draft-ietf-idr-2858bis Survey Report July 2004 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"/"Optinal 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 Hares Expires - December 2004 [Page 17] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Advertisment 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 Hares Expires - December 2004 [Page 18] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 4. Security Considerations This document does not address any security issues. 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 [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 Hares Expires - December 2004 [Page 19] ^L draft-ietf-idr-2858bis Survey Report July 2004 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 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hares Expires - December 2004 [Page 20] ^L draft-ietf-idr-2858bis Survey Report July 2004 Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hares Expires - December 2004 [Page 21] ^L