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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
