The IESG has approved the following document: - 'Multiprotocol Extensions for BGP-4 ' <draft-ietf-idr-rfc2858bis-10.txt> as a Draft Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-10.txt Technical Summary This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. In the move to Draft Standard, the support for SAFI 3 (unicast+ multicast for congruent topologies) was removed due to lack of implementation support. The value remains reserved in case this feature is implemented. In addition, the support for SNPA was removed, also due to lack of implementation support. The "Number of SNPAs" field was changed to reserved and MUST be set to zero. Working Group Summary The working group had consensus to move this document to Draft Standard. Protocol Quality Bill Fenner reviewed this spec for the IESG. There are several implementations, as described in the accompanying implementation report, which can be found at http://www.ietf.org/IESG/Implementations/mp-bgp-implementation-report.txt Note to RFC Editor This document obsoletes RFC 2858. Please make the following changes: In the Abstract, remove the first sentence and add another example to the list; OLD: Currently BGP-4 is capable of carrying routing information only for IPv4. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that NEW: This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that OLD: To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI this document uses a combination of Address Family, as defined in [RFC1700], and Subsequent Address Family (as described in this document). NEW: To identify individual Network Layer protocols associated with the next hop information and semantics of NLRI this document uses a combination of Address Family, as defined in [IANA-AF], and Subsequent Address Family (as described in this document). This paragraph appears twice, please change both: OLD: Presently defined values for the Address Family Identifier field are specified in RFC1700 (see the Address Family Numbers section). NEW: Presently defined values for the Address Family Identifier field are specified in the IANA's Address Family Numbers registry [IANA-AF]. In section 8: OLD: Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender and ignored by the receiver. NEW: Res. - Reserved (8 bit) field. SHOULD be set to 0 by the sender and ignored by the receiver. Note that not setting the field value to 0 may create issues for a receiver not ignoring the field. In addition this definition is problematic if it is ever attempted to redefine the field. In the IANA considerations section: OLD: - SAFI values 128 through 240 are part of the previous "private use" range. Of this space, allocations which are currently in use are to be recognized by IANA. Unused values, namely 130, 131, 135 through 139, and 141 through 240 should be considered reserved, in order to avoid conflicts. NEW: - SAFI values 128 through 240 are part of the previous "private use" range. At the time of approval of this document, a list of allocations which are currently in use will be provided to IANA by the Routing Area Director. Unused values, namely 130, 131, 135 through 139, and 141 through 240 should be considered reserved, in order to avoid conflicts. References: OLD: [BGP-CAP] "Capabilities Advertisement with BGP-4", R. Chandra, J. Scudder, RFC2842, May 2000 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [RFC1700] "Assigned Numbers", J. Reynolds, J. Postel, RFC1700, October 1994 (see also http://www.iana.org/iana/assignments.html) NEW: [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [IANA-AF] "Address Family Numbers", reachable from http://www.iana.org/numbers.html Authors' Addresses: [change juniper.com to juniper.net] OLD: Dave Katz Juniper Networks, Inc. email: dkatz@juniper.com Yakov Rekhter Juniper Networks, Inc. email: yakov@juniper.com NEW: Dave Katz Juniper Networks, Inc. email: dkatz@juniper.net Yakov Rekhter Juniper Networks, Inc. email: yakov@juniper.net _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
