draft-ietf-bess-mvpn-global-table-mcast-00.txt   draft-ietf-bess-mvpn-global-table-mcast-01.txt 
BESS Working Group J. Zhang BESS Working Group Z. Zhang
Internet-Draft L. Giuliano Internet-Draft L. Giuliano
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: May 24, 2015 Juniper Networks, Inc. Expires: November 19, 2015 Juniper Networks, Inc.
K. Subramanian K. Subramanian
Cisco Systems, Inc. Cisco Systems, Inc.
D. Pacella D. Pacella
Verizon Verizon
J. Schiller J. Schiller
Google Google
November 20, 2014 May 18, 2015
Global Table Multicast with BGP-MVPN Procedures Global Table Multicast with BGP-MVPN Procedures
draft-ietf-bess-mvpn-global-table-mcast-00 draft-ietf-bess-mvpn-global-table-mcast-01
Abstract Abstract
RFC6513, RFC6514, and other RFCs describe protocols and procedures RFC6513, RFC6514, and other RFCs describe protocols and procedures
which a Service Provider (SP) may deploy in order offer Multicast which a Service Provider (SP) may deploy in order offer Multicast
Virtual Private Network (Multicast VPN or MVPN) service to its Virtual Private Network (Multicast VPN or MVPN) service to its
customers. Some of these procedures use BGP to distribute VPN- customers. Some of these procedures use BGP to distribute VPN-
specific multicast routing information across a backbone network. specific multicast routing information across a backbone network.
With a small number of relatively minor modifications, the very same With a small number of relatively minor modifications, the very same
BGP procedures can also be used to distribute multicast routing BGP procedures can also be used to distribute multicast routing
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 24, 2015. This Internet-Draft will expire on November 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5 2. Adapting MVPN Procedures to GTM . . . . . . . . . . . . . . . 5
2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5 2.1. Use of Route Distinguishers . . . . . . . . . . . . . . . 5
2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6 2.2. Use of Route Targets . . . . . . . . . . . . . . . . . . 6
2.3. UMH-eligible Routes . . . . . . . . . . . . . . . . . . . 8 2.3. UMH-eligible Routes . . . . . . . . . . . . . . . . . . . 8
2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs . . . . . . . 9 2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs . . . . . . . 9
2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 9 2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 10
2.3.3. Non-BGP Routes as the UMH-eligible Routes . . . . . . 11 2.3.3. Non-BGP Routes as the UMH-eligible Routes . . . . . . 11
2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11 2.3.4. Why SFS Does Not Apply to GTM . . . . . . . . . . . . 11
2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13 2.4. Inclusive and Selective Tunnels . . . . . . . . . . . . . 13
2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13 2.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13 2.5.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13 2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 13 2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14
2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14 2.7. Leaf A-D Routes . . . . . . . . . . . . . . . . . . . . . 14
2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14 2.8. Source Active A-D Routes . . . . . . . . . . . . . . . . 14
2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14 2.8.1. Finding the Originator of an SA A-D Route . . . . . . 14
2.8.2. Optional Additional Constraints on Distribution . . . 15 2.8.2. Optional Additional Constraints on Distribution . . . 15
2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16 2.9. C-multicast Source/Shared Tree Joins . . . . . . . . . . 16
3. Differences from other MVPN-like GTM Procedures . . . . . . . 16 3. Differences from other MVPN-like GTM Procedures . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Additional Contributors . . . . . . . . . . . . . . . . . . . 18 6. Additional Contributors . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 5, line 15 skipping to change at page 5, line 15
This document not only uses MVPN procedures for GTM, but also, This document not only uses MVPN procedures for GTM, but also,
insofar as possible, uses the same protocol elements, encodings, and insofar as possible, uses the same protocol elements, encodings, and
formats. The BGP Updates for GTM thus use the same Subsequent formats. The BGP Updates for GTM thus use the same Subsequent
Address Family Identifier (SAFI), and have the same Network Layer Address Family Identifier (SAFI), and have the same Network Layer
Reachability Information (NLRI) format, as the BGP Updates for MVPN. Reachability Information (NLRI) format, as the BGP Updates for MVPN.
Details for supporting MVPN (either IPv4 or IPv6 MVPN traffic) over Details for supporting MVPN (either IPv4 or IPv6 MVPN traffic) over
an IPv6 backbone network can be found in [RFC6515]. The procedures an IPv6 backbone network can be found in [RFC6515]. The procedures
and encodings described therein are also applicable to GTM. and encodings described therein are also applicable to GTM.
The document [SEAMLESS-MCAST] extends [RFC6514] by providing The document [RFC7524] extends [RFC6514] by providing procedures that
procedures that allow tunnels through the core to be "segmented" at allow tunnels through the core to be "segmented" at ABRs within the
ABRs within the core. The ABR segmentation procedures are also core. The ABR segmentation procedures are also applicable to GTM as
applicable to GTM as defined in the current document. In general, defined in the current document. In general, the MVPN procedures of
the MVPN procedures of [SEAMLESS-MCAST], adapted as specified in the [RFC7524], adapted as specified in the current document, are
current document, are applicable to GTM. applicable to GTM.
The document [SEAMLESS-MCAST] also defines a set of procedures for The document [RFC7524] also defines a set of procedures for GTM.
GTM. Those procedures are different from the procedures defined in Those procedures are different from the procedures defined in the
the current document, and the two sets of procedures are not current document, and the two sets of procedures are not
interoperable with each other. The two sets of procedures can co- interoperable with each other. The two sets of procedures can co-
exist in the same network, as long as they are not applied to the exist in the same network, as long as they are not applied to the
same multicast flows or to the same multicast group addresses. See same multicast flows or to the same multicast group addresses. See
Section 3 for more details. Section 3 for more details.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Adapting MVPN Procedures to GTM 2. Adapting MVPN Procedures to GTM
skipping to change at page 7, line 45 skipping to change at page 7, line 45
distinct from any RTs used in support of MVPN (except in the case distinct from any RTs used in support of MVPN (except in the case
where it is actually intended to create an "extranet" where it is actually intended to create an "extranet"
[MVPN-extranet] in which some sources are reachable in global [MVPN-extranet] in which some sources are reachable in global
table context while others are reachable in VPN context.) table context while others are reachable in VPN context.)
The "RT Constraint" procedures of [RFC4684] MAY be used to constrain The "RT Constraint" procedures of [RFC4684] MAY be used to constrain
the distribution of MCAST-VPN routes (or other routes) that carry RTs the distribution of MCAST-VPN routes (or other routes) that carry RTs
that have been configured as import RTs for GTM. (This includes the that have been configured as import RTs for GTM. (This includes the
upstream-node-identifying RTs.) upstream-node-identifying RTs.)
N.B.: If the "RT Constraint" procedures of [RFC4684] are deployed,
but the MCAST-VPN routes are not carrying RTs, then proper
operation requires the "default behavior" specified for the
MCAST-VPN address family in Section 3 ("Default Behavior") of
[RTC_without_RTs].
In [RFC6513], the UMH-eligible routes (see section 5.1 of [RFC6513], In [RFC6513], the UMH-eligible routes (see section 5.1 of [RFC6513],
"Eligible Routes for UMH Selection") are generally routes of SAFI 128 "Eligible Routes for UMH Selection") are generally routes of SAFI 128
(Labeled VPN-IP routes) or 129 (VPN-IP multicast routes), and are (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes), and are
required to carry RTs. These RTs determine which VRFs import which required to carry RTs. These RTs determine which VRFs import which
such routes. However, for GTM, when the UMH-eligible routes may be such routes. However, for GTM, when the UMH-eligible routes may be
routes of SAFI 1, 2, or 4, the routes are not required to carry RTs. routes of SAFI 1, 2, or 4, the routes are not required to carry RTs.
This document does NOT specify any new rules for determine whether a This document does NOT specify any new rules for determining whether
SAFI 1, 2, or 4 route is to be imported into the global table of any a SAFI 1, 2, or 4 route is to be imported into the global table of
PBR. any PBR.
2.3. UMH-eligible Routes 2.3. UMH-eligible Routes
[RFC6513] section 5.1 defines procedures by which a PE router [RFC6513] section 5.1 defines procedures by which a PE router
determines the "C-root", the "Upstream Multicast Hop" (UMH), the determines the "C-root", the "Upstream Multicast Hop" (UMH), the
"Upstream PE", and the "Upstream RD" of a given multicast flow. (In "Upstream PE", and the "Upstream RD" of a given multicast flow. (In
non-VPN multicast documents, the UMH of a multicast flow at a non-VPN multicast documents, the UMH of a multicast flow at a
particular router is generally known as the "RPF neighbor" for that particular router is generally known as the "RPF neighbor" for that
flow.) It also defines procedures for determining the "Source AS" of flow.) It also defines procedures for determining the "Source AS" of
a particular flow. Note that in GTM, the "Upstream PE" is actually a particular flow. Note that in GTM, the "Upstream PE" is actually
skipping to change at page 16, line 26 skipping to change at page 16, line 33
that the next hop of the C-multicast Source/Shared Tree Joins does that the next hop of the C-multicast Source/Shared Tree Joins does
not change during the distribution of those routes, the proper not change during the distribution of those routes, the proper
procedure for creating the IP-address-specific RT is to just put the procedure for creating the IP-address-specific RT is to just put the
IP Address of the Upstream PBR in the Global Administrator field of IP Address of the Upstream PBR in the Global Administrator field of
the RT. In other scenarios, the procedure of the previous paragraph the RT. In other scenarios, the procedure of the previous paragraph
(as modified by this document's sections on "RD usage" and "RT (as modified by this document's sections on "RD usage" and "RT
usage") is applied by the PBRs. usage") is applied by the PBRs.
3. Differences from other MVPN-like GTM Procedures 3. Differences from other MVPN-like GTM Procedures
The document [SEAMLESS-MCAST] also defines a procedure for GTM that The document [RFC7524] also defines a procedure for GTM that is based
is based on the BGP procedures that were developed for MVPN. on the BGP procedures that were developed for MVPN.
However, the GTM procedures of [SEAMLESS-MCAST] are different than However, the GTM procedures of [RFC7524] are different than and are
and are NOT interoperable with the procedures defined in this NOT interoperable with the procedures defined in this document.
document.
The two sets of procedures can co-exist in the same network, as long The two sets of procedures can co-exist in the same network, as long
as they are not applied to the same multicast flows or to the same as they are not applied to the same multicast flows or to the same
ASM multicast group addresses. ASM multicast group addresses.
Some of the major differences between the two sets of procedures are Some of the major differences between the two sets of procedures are
the following: the following:
o The [SEAMLESS-MCAST] procedures for GTM do not use C-multicast o The [RFC7524] procedures for GTM do not use C-multicast Shared
Shared Tree Joins or C-multicast Source Tree Joins at all. The Tree Joins or C-multicast Source Tree Joins at all. The
procedures of this document use these C-multicast routes for GTM, procedures of this document use these C-multicast routes for GTM,
setting the RD field of the NLRI to zero. setting the RD field of the NLRI to zero.
o The [SEAMLESS-MCAST] procedures for GTM use Leaf A-D routes o The [RFC7524] procedures for GTM use Leaf A-D routes instead of
instead of C-multicast Shared/Source Tree Join routes. Leaf A-D C-multicast Shared/Source Tree Join routes. Leaf A-D routes used
routes used in that manner can be distinguished from Leaf A-D in that manner can be distinguished from Leaf A-D routes used as
routes used as specified in [RFC6514] by means of the NLRI format; specified in [RFC6514] by means of the NLRI format; [RFC7524]
[SEAMLESS-MCAST] defines a new NLRI format for Leaf A-D routes. defines a new NLRI format for Leaf A-D routes. Whether a given
Whether a given Leaf A-D route is being used according to the Leaf A-D route is being used according to the [RFC7524] procedures
[SEAMLESS-MCAST] procedures or not can be determined from its or not can be determined from its NLRI. (See [RFC7524] section
NLRI. (See [SEAMLESS-MCAST] section "Leaf A-D Route for Global "Leaf A-D Route for Global Table Multicast".)
Table Multicast".)
o The Leaf A-D routes used by the current document contain an NLRI o The Leaf A-D routes used by the current document contain an NLRI
that is in the format defined in [RFC6514], NOT in the format as that is in the format defined in [RFC6514], NOT in the format as
defined in [SEAMLESS-MCAST]. The procedures assumed by this defined in [RFC7524]. The procedures assumed by this document for
document for originating and processing Leaf A-D routes are as originating and processing Leaf A-D routes are as specified in
specified in [RFC6514], NOT as specified in [SEAMLESS-MCAST]. [RFC6514], NOT as specified in [RFC7524].
o The current document uses an RD value of zero in the NLRI in order o The current document uses an RD value of zero in the NLRI in order
to indicate that a particular route is "about" a Global to indicate that a particular route is "about" a Global
Table Multicast, rather than a VPN multicast. No other semantics Table Multicast, rather than a VPN multicast. No other semantics
are inferred from the fact that RD is zero. [SEAMLESS-MCAST] uses are inferred from the fact that RD is zero. [RFC7524] uses two
two different RD values in its GTM procedures, with semantic different RD values in its GTM procedures, with semantic
differences that depend upon the RD values. differences that depend upon the RD values.
o In order for both sets of procedures to co-exist in the same o In order for both sets of procedures to co-exist in the same
network, the PBRs MUST be provisioned so that for any given IP network, the PBRs MUST be provisioned so that for any given IP
group address in the global table, all egress PBRs use the same group address in the global table, all egress PBRs use the same
set of procedures for that group address (i.e., for group G, set of procedures for that group address (i.e., for group G,
either all egress PBRs use the GTM procedures of this document or either all egress PBRs use the GTM procedures of this document or
all egress PBRs use the GTM procedures of [SEAMLESS-MCAST]. all egress PBRs use the GTM procedures of [RFC7524].
4. IANA Considerations 4. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
5. Security Considerations 5. Security Considerations
The security considerations of this document are primarily the The security considerations of this document are primarily the
security considerations of the base protocols, as discussed in security considerations of the base protocols, as discussed in
[RFC6514], [RFC4601], and [RFC5294]. [RFC6514], [RFC4601], and [RFC5294].
skipping to change at page 19, line 34 skipping to change at page 19, line 34
February 2012. February 2012.
8.2. Informative References 8.2. Informative References
[ADD-PATH] [ADD-PATH]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", internet-draft "Advertisement of Multiple Paths in BGP", internet-draft
draft-ietf-idr-add-paths-10, October 2014. draft-ietf-idr-add-paths-10, October 2014.
[MVPN-extranet] [MVPN-extranet]
Rekhter, Y. and E. Rosen, "Extranet Multicast in BGP/IP Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
MPLS VPNs", internet-draft draft-ietf-bess-mvpn-extranet- Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
00, July 2014. draft draft-ietf-bess-mvpn-extranet-02, May 2015.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006. Private Networks (VPNs)", RFC 4684, November 2006.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294, August 2008. Independent Multicast (PIM)", RFC 5294, August 2008.
[RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
Yamagata, "Internal BGP as the Provider/Customer Edge Yamagata, "Internal BGP as the Provider/Customer Edge
Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 6368, September 2011. RFC 6368, September 2011.
[SEAMLESS-MCAST] [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Rekhter, Y., Aggarwal, R., Morin, T., Grosclaude, I., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Leymann, N., and S. Saad, "Inter-Area P2MP Segmented Point-to-Multipoint (P2MP) Segmented Label Switched Paths
LSPs", internet-draft draft-ietf-mpls-seamless-mcast-14, (LSPs)", RFC 7524, May 2015.
July 2014.
[RTC_without_RTs]
Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route
Target Constrained Distribution of Routes with no Route
Targets", internet-draft draft-ietf-idr-rtc-no-rt-00,
January 2015.
Authors' Addresses Authors' Addresses
Jeffrey Zhang Zhaohui Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US US
Email: zzhang@juniper.net Email: zzhang@juniper.net
Lenny Giuliano Lenny Giuliano
Juniper Networks, Inc. Juniper Networks, Inc.
2251 Corporate Park Drive 2251 Corporate Park Drive
 End of changes. 22 change blocks. 
51 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/