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.