Protocol Action: 'BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs '
   <draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt> as a Proposed Standard


This document is the product of the Layer 3 Virtual Private Networks Working Group. 

The IESG contact persons are Ross Callon and Adrian Farrel.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt

Technical Summary

   This document describes the BGP encodings and procedures for
   exchanging the information elements required by Multicast in 
   MPLS/BGP IP VPNs, as specified in the related document
   draft-ietf-l3vpn-2547bis-mcast. 

Working Group Summary

   The L3VPN WG has been working on multicast for many years, with 
   significant difficulty coming to consensus. This document is put 
   forth with draft-ietf-l3vpn-2547bis-mcast. Interoperability and
   default deployment modes are a concern because of the large number
   of options and features provided in each of these specifications.
   These concerns are being addressed by draft-ietf-l3vpn-mvpn-
   considerations, which will be submitted very shortly as well.  
   After much deliberation and consideration in the WG and among 
   relevant stake holders this is the most feasible path forward.

Document Quality

   Many of the options described in this document are implemented and
   widely deployed. The related document draft-ietf-l3vpn-mvpn-
   considerations is co-authored by experts from multiple service 
   providers based largely on deployement experience. 

Personnel

   Danny McPherson is the Document Shepherd for this document. Ross
   Callon is is the Responsible Area Director.

RFC Editor Note

  In section 2 ("Introduction"), second paragraph:

  OLD
    This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI
    is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel
    binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN
    customer multicast routing information exchange among PEs, choosing a
    single forwarder PE, and for procedures in support of co-locating a
    C-RP on a PE.

  NEW
    This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI
    is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel
    binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN
    customer multicast routing information exchange among PEs, choosing a
    single forwarder PE, and for procedures in support of co-locating a
    C-RP on a PE.  This NLRI does not apply to communications between CE
    and PE equipment.

  In section 8 ("PE Distinguisher Labels Attribute"), third paragraph:

  OLD
    The attribute is also considered to be malformed if the PE Address 
    field is expected to be an IPv4 address, and the length of the
    attribute minus 4 is not a multiple of 3, or the PE Address field
    is expected to be an IPv6 address, and the length of the attribute
    minus 16 is not a multiple of 3.

  NEW
    The attribute is also considered to be malformed if the PE Address
    field is expected to be an IPv4 address, and the length of the
    attribute is not a multiple of 7, or the PE Address field is
    expected to be an IPv6 address, and the length of the attribute is
    not a multiple of 19.

  In section 17 ("Security Considerations"), replace first paragraph:

  OLD  
    The mechanisms described in this document could re-use the existing
    BGP security mechanisms.
  
  NEW  
    The mechanisms described in this document could re-use the existing
    BGP security mechanisms [RFC4271][RFC4272]. The security model and
    threats specific to Provider Provisioned VPNs, including L3VPNs, are
    discussed in [RFC4111]. [MVPN] discusses 
    additional threats specific to the use of multicast in L3VPNs. There
    is currently work in progress to improve the security of TCP
    authentication. When the document is finalized as an RFC, the method
    defined in [draft-ietf-tcpm-tcp-auth-opt] SHOULD be used where
    authentication of BGP control packets is needed.

  In Section 18 ("IANA Considerations"), first paragraph:

  OLD
    This document defines a new BGP Extended Community called Source AS.
    This community is 2-octet AS specific, of an extended type, and is
    transitive.

  NEW
    This document defines a new BGP Extended Community called Source
    AS. This community is of an extended type, and is transitive.
    This document requests allocation of the Type value for this
    community from both the Two-octet AS Specific Extended Community
    and the Four-octet AS Specific Extended Community registries.
    Moreover, the document requests allocating the same Type value
    from both of these registries.

  Please add an informative reference (section 21.2) to RFC4111, 
  RFC4272, and draft-ietf-tcpm-tcp-auth-opt.