Multiprotocol Extensions for BGP-4
RFC 4760

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    idr mailing list <idr@ietf.org>, 
    idr chair <idr-chairs@tools.ietf.org>
Subject: Protocol Action: 'Multiprotocol Extensions for BGP-4' 
         to Draft Standard 

The IESG has approved the following document:

- 'Multiprotocol Extensions for BGP-4 '
   <draft-ietf-idr-rfc2858bis-11.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-11.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