draft-ietf-bess-mvpn-global-table-mcast-03.txt   rfc7716.txt 
BESS Working Group Z. Zhang Internet Engineering Task Force (IETF) Z. Zhang
Internet-Draft L. Giuliano Request for Comments: 7716 L. Giuliano
Intended status: Standards Track E. Rosen, Ed. Category: Standards Track E. Rosen, Ed.
Expires: March 20, 2016 Juniper Networks, Inc. ISSN: 2070-1721 Juniper Networks, Inc.
K. Subramanian K. Subramanian
Cisco Systems, Inc. Cisco Systems, Inc.
D. Pacella D. Pacella
Verizon Verizon
September 17, 2015 December 2015
Global Table Multicast with BGP-MVPN Procedures Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
draft-ietf-bess-mvpn-global-table-mcast-03
Abstract Abstract
RFC6513, RFC6514, and other RFCs describe protocols and procedures RFCs 6513, 6514, and others describe protocols and procedures that a
which a Service Provider (SP) may deploy in order offer Multicast Service Provider (SP) may deploy in order to offer Multicast Virtual
Virtual Private Network (Multicast VPN or MVPN) service to its Private Network (Multicast VPN or MVPN) service to its customers.
customers. Some of these procedures use BGP to distribute VPN- Some of these procedures use BGP to distribute VPN-specific multicast
specific multicast routing information across a backbone network. routing information across a backbone network. With a small number
With a small number of relatively minor modifications, the very same of relatively minor modifications, the same BGP procedures can also
BGP procedures can also be used to distribute multicast routing be used to distribute multicast routing information that is not
information that is not specific to any VPN. Multicast that is specific to any VPN. Multicast that is outside the context of a VPN
outside the context of a VPN is known as "Global Table Multicast", or is known as "Global Table Multicast", or sometimes simply as
sometimes simply as "Internet multicast". In this document, we "Internet multicast". In this document, we describe the
describe the modifications that are needed to use the MVPN BGP modifications that are needed to use the BGP-MVPN procedures for
procedures for Global Table Multicast. Global Table Multicast.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 20, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7716.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . 10 2.3.2. MVPN ECs on the Route to the Next Hop . . . . . . . . 9
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 . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . 14 2.5.2. Inter-AS I-PMSI A-D Routes . . . . . . . . . . . . . 13
2.6. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . 17 3. Differences from Other MVPN-Like GTM Procedures . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Additional Contributors . . . . . . . . . . . . . . . . . . . 19 5.1. Normative References . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Informative References . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
[RFC4364] specifies architecture, protocols, and procedures that a [RFC4364] specifies architecture, protocols, and procedures that a
Service Provider (SP) can use to provide Virtual Private Network Service Provider (SP) can use to provide Virtual Private Network
(VPN) service to its customers. In that architecture, one or more (VPN) service to its customers. In that architecture, one or more
Customer Edge (CE) routers attach to a Provider Edge (PE) router. Customer Edge (CE) routers attach to a Provider Edge (PE) router.
Each CE router belongs to a single VPN, but CE routers from several Each CE router belongs to a single VPN, but CE routers from several
VPNs may attach to the same PE router. In addition, CEs from the VPNs may attach to the same PE router. In addition, CEs from the
same VPN may attach to different PEs. BGP is used to carry VPN- same VPN may attach to different PEs. BGP is used to carry VPN-
skipping to change at page 3, line 32 skipping to change at page 3, line 32
given customer's multicast routing information in the VRF for that given customer's multicast routing information in the VRF for that
customer's VPN. BGP is used to distribute certain multicast-related customer's VPN. BGP is used to distribute certain multicast-related
control information among the PEs that attach to a given VPN, and BGP control information among the PEs that attach to a given VPN, and BGP
may also be used to exchange the customer multicast routing may also be used to exchange the customer multicast routing
information itself among the PEs. information itself among the PEs.
While this multicast architecture was originally developed for VPNs, While this multicast architecture was originally developed for VPNs,
it can also be used (with a small number of modifications to the it can also be used (with a small number of modifications to the
procedures) to distribute multicast routing information that is not procedures) to distribute multicast routing information that is not
specific to VPNs. The purpose of this document is to specify the way specific to VPNs. The purpose of this document is to specify the way
in which BGP MVPN procedures can be adapted to support non-VPN in which BGP-MVPN procedures can be adapted to support non-VPN
multicast. multicast.
Multicast routing information that is not specific to VPNs is stored Multicast routing information that is not specific to VPNs is stored
in a router's "global table", rather than in a VRF; hence it is known in a router's "global table", rather than in a VRF; hence, it is
as "Global Table Multicast" (GTM). GTM is sometimes more simply known as "Global Table Multicast" (GTM). GTM is sometimes more
called "Internet multicast". However, we will avoid that term simply called "Internet multicast". However, we will avoid that term
because it suggests that the multicast data streams are available on because it suggests that the multicast data streams are available on
the "public" Internet. The procedures for GTM can certainly be used the "public" Internet. The procedures for GTM can certainly be used
to support multicast on the public Internet, but they can also be to support multicast on the public Internet, but they can also be
used to support multicast streams that are not public, e.g., content used to support multicast streams that are not public, e.g., content
distribution streams offered by content providers to paid distribution streams offered by content providers to paid
subscribers. For the purposes of this document, all that matters is subscribers. For the purposes of this document, all that matters is
that the multicast routing information is maintained in a global that the multicast routing information is maintained in a global
table rather than in a VRF. table rather than in a VRF.
This architecture does assume that the network over which the This architecture does assume that the network over which the
multicast streams travel can be divided into a "core network" and one multicast streams travel can be divided into a "core network" and one
or more non-core parts of the network, which we shall call or more non-core parts of the network, which we shall call
"attachment networks". The multicast routing protocol used in the "attachment networks". The multicast routing protocol used in the
attachment networks may not be the same as the one used in the core, attachment networks may not be the same as the one used in the core,
so we consider there to be a "protocol boundary" between the core so we consider there to be a "protocol boundary" between the core
network and the attachment networks. We will use the term "Protocol network and the attachment networks. We will use the term "Protocol
Boundary Router" (PBR) to refer to the core routers that are at the Boundary Router" (PBR) to refer to the core routers that are at the
boundary. We will use the term "Attachment Router" (AR) to refer to boundary. We will use the term "Attachment Router" (AR) to refer to
the routers that are not in the core but that attach to the PBRs. the routers that attach to the PBRs but are not in the core.
This document does not make any particular set of assumptions about This document does not make any particular set of assumptions about
the protocols that the ARs and the PBRs use to exchange unicast and the protocols that the ARs and the PBRs use to exchange unicast and
multicast routing information with each other. For instance, multicast routing information with each other. For instance,
multicast routing information could be exchanged between an AR and a multicast routing information could be exchanged between an AR and a
PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an PBR via PIM, IGMP, or even BGP. Multicast routing also depends on an
exchange of routes that are used for looking up the path to the root exchange of routes that are used for looking up the path to the root
of a multicast tree. This routing information could be exchanged of a multicast tree. This routing information could be exchanged
between an AR and a PBR via IGP, via EBGP, or via IBGP ([RFC6368]). between an AR and a PBR via IGP, via EBGP, or via IBGP [RFC6368].
Note that if IBGP is used, the [RFC6368] "push/pop procedures" are Note that if IBGP is used, the "push" and "pop" procedures described
not necessary. in [RFC6368] are not necessary.
The PBRs are not necessarily "edge" routers, in the sense of The PBRs are not necessarily "edge routers", in the sense of
[RFC4364]. For example, they may be both be Autonomous System Border [RFC4364]. For example, they may be both be Autonomous System Border
Routers (ASBR). As another example, an AR may be an "access router" Routers (ASBRs). As another example, an AR may be an "access router"
attached to a PBR that is an OSPF Area Border Router (ABR). Many attached to a PBR that is an OSPF Area Border Router (ABR). Many
other deployment scenarios are possible. However, the PBRs are other deployment scenarios are possible. However, the PBRs are
always considered to be delimiting a "backbone" or "core" network. A always considered to be delimiting a "backbone" or "core" network. A
multicast data stream from an AR is tunneled over the core network multicast data stream from an AR is tunneled over the core network
from an Ingress PBR to one or more Egress PBRs. Multicast routing from an ingress PBR to one or more egress PBRs. Multicast routing
information that a PBR learns from the ARs attached to it is stored information that a PBR learns from the ARs attached to it is stored
in the PBR's global table. The PBRs use BGP to distribute multicast in the PBR's global table. The PBRs use BGP to distribute multicast
routing and auto-discovery information among themselves. This is routing and auto-discovery information among themselves. This is
done following the procedures of [RFC6513], [RFC6514], and other MVPN done following the procedures of [RFC6513], [RFC6514], and other MVPN
specifications, as modified in this document. specifications, as modified in this document.
In general, PBRs follow the same MVPN/BGP procedures that PE routers In general, PBRs follow the same BGP-MVPN procedures that PE routers
follow, except that these procedures are adapted to be applicable to follow, except that these procedures are adapted to be applicable to
the global table rather than to a VRF. Details are provided in the global table rather than to a VRF. Details are provided in
subsequent sections of this document. subsequent sections of this document.
By supporting GTM using the BGP procedures designed for MVPN, one By supporting GTM using the BGP procedures designed for MVPN, one
obtains a single control plane that governs the use of both VPN and obtains a single control plane that governs the use of both VPN and
non-VPN multicast. Most of the features and characteristics of MVPN non-VPN multicast. Most of the features and characteristics of MVPN
carry over automatically to GTM. These include scaling, aggregation, carry over automatically to GTM. These include scaling, aggregation,
flexible choice of tunnel technology in the SP network, support for flexible choice of tunnel technology in the SP network, support for
both segmented and non-segmented tunnels, ability to use wildcards to both segmented and non-segmented tunnels, ability to use wildcards to
identify sets of multicast flows, support for the Any Source identify sets of multicast flows, support for the Any-Source
Multicast (ASM), Single Source Multicast (SSM), and Bidirectional Multicast (ASM), Source-Specific Multicast (SSM), and Bidirectional
(bidir) multicast paradigms, support for both IPv4 and IPv6 multicast (bidir) multicast paradigms, support for both IPv4 and IPv6 multicast
flows over either an IPv4 or IPv6 SP infrastructure, support for flows over either an IPv4 or IPv6 SP infrastructure, support for
unsolicited flooded data (including support for BSR as RP-to-group unsolicited flooded data (including support for Bootstrap Router
mapping protocols), etc. (BSR) as an RP-to-group mapping protocol), etc.
This document not only uses MVPN procedures for GTM, but also, This document not only uses MVPN procedures for GTM but also, insofar
insofar as possible, uses the same protocol elements, encodings, and as possible, uses the same protocol elements, encodings, and formats.
formats. The BGP Updates for GTM thus use the same Subsequent The BGP Updates for GTM thus use the same Subsequent Address Family
Address Family Identifier (SAFI), and have the same Network Layer Identifier (SAFI) and have the same Network Layer Reachability
Reachability Information (NLRI) format, as the BGP Updates for MVPN. 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 [RFC7524] extends [RFC6514] by providing procedures that [RFC7524] extends [RFC6514] by providing procedures that allow
allow tunnels through the core to be "segmented" at ABRs within the tunnels through the core to be "segmented" at ABRs within the core.
core. The ABR segmentation procedures are also applicable to GTM as The ABR segmentation procedures are also applicable to GTM as defined
defined in the current document. In general, the MVPN procedures of in the current document. In general, the MVPN procedures of
[RFC7524], adapted as specified in the current document, are [RFC7524], adapted as specified in the current document, are
applicable to GTM. applicable to GTM.
The document [RFC7524] also defines a set of procedures for GTM. [RFC7524] also defines a set of procedures for GTM. Those procedures
Those procedures are different from the procedures defined in the are different from the procedures defined in the current document,
current document, and the two sets of procedures are not and the two sets of procedures are not interoperable with each other.
interoperable with each other. The two sets of procedures can co- The two sets of procedures can co-exist in the same network, as long
exist in the same network, as long as they are not applied to the as they are not applied to the same multicast flows or to the same
same multicast flows or to the same multicast group addresses. See 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
In general, PBRs support Global Table Multicast by using the In general, PBRs support Global Table Multicast by using the
procedures that PE routers use to support VPN multicast. For GTM, procedures that PE routers use to support VPN multicast. For GTM,
where [RFC6513] and [RFC6514] talk about the "PE-CE interface", one where [RFC6513] and [RFC6514] talk about the "PE-CE interface", one
skipping to change at page 6, line 5 skipping to change at page 6, line 4
A few adaptations to the procedures of [RFC6513] and [RFC6514] need A few adaptations to the procedures of [RFC6513] and [RFC6514] need
to be made. Those adaptations are described in the following sub- to be made. Those adaptations are described in the following sub-
sections. sections.
2.1. Use of Route Distinguishers 2.1. Use of Route Distinguishers
The MVPN procedures require the use of BGP routes, defined in The MVPN procedures require the use of BGP routes, defined in
[RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We refer to [RFC6514], that have a SAFI value of 5 ("MCAST-VPN"). We refer to
these simply as "MCAST-VPN routes". [RFC6514] defines the Network these simply as "MCAST-VPN routes". [RFC6514] defines the Network
Layer Reachability Information (NLRI) format for MCAST-VPN routes. Layer Reachability Information (NLRI) format for MCAST-VPN routes.
The NLRI field always begins with a "Route Type" octet, and, The NLRI field always begins with a "Route Type" octet, and,
depending on the route type, may be followed by a "Route depending on the route type, may be followed by a Route Distinguisher
Distinguisher" (RD) field. (RD) field.
When a PBR originates an MCAST-VPN route in support of GTM, the RD When a PBR originates an MCAST-VPN route in support of GTM, the RD
field (for those routes types where it is defined) of that route's field (for those routes types where it is defined) of that route's
NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF NLRI MUST be set to zero (i.e., to 64 bits of zero). Since no VRF
may have an RD of zero, this allows "MCAST-VPN" routes that are may have an RD of zero, this allows MCAST-VPN routes that are about
"about" GTM to be distinguished from MCAST-VPN routes that are about GTM to be distinguished from MCAST-VPN routes that are about VPNs.
VPNs.
2.2. Use of Route Targets 2.2. Use of Route Targets
The MVPN procedures require all MCAST-VPN routes to carry Route The MVPN procedures require all MCAST-VPN routes to carry Route
Targets (RTs). When a PE router receives an MCAST-VPN route, it Targets (RTs). When a PE router receives an MCAST-VPN route, it
processes the route in the context of a particular VRF if and only if processes the route in the context of a particular VRF if and only if
the route is carrying an RT that is configured as one of that VRF's the route is carrying an RT that is configured as one of that VRF's
"import RTs". "import RTs".
There are two different "kinds" of RT used in MVPN. There are two different kinds of RT used in MVPN.
o One kind of RT is carried only by the following MCAST-VPN route o One kind of RT is carried only by the following MCAST-VPN route
types: C-multicast Shared Tree Joins, C-multicast Source Tree types: C-multicast Shared Tree Joins, C-multicast Source Tree
Joins, and Leaf A-D routes. This kind of RT identifies the PE Joins, and Leaf auto-discovery routes (A-D routes). This kind of
router that has been selected by the route's originator as the RT identifies the PE router that has been selected by the route's
"Upstream PE" or as the "Upstream Multicast Hop" (UMH) for a originator as the "Upstream PE" or as the "Upstream Multicast Hop"
particular (set of) multicast flow(s). Per [RFC6514] and (UMH) for a particular (set of) multicast flow(s). Per [RFC6514]
[RFC6515], this RT must be an IPv4-address-specific or IPv6- and [RFC6515], this RT must be an IPv4-address-specific or IPv6-
address-specific Extended Community (EC), whose "Global address-specific Extended Community (EC), whose Global
Administrator" field identifies the Upstream PE or the UMH. If Administrator field identifies the Upstream PE or the UMH. If the
the Global Administrator field identifies the Upstream PE, the Global Administrator field identifies the Upstream PE, the Local
"Local Administrator" field identifies a particular VRF in that Administrator field identifies a particular VRF in that PE.
PE.
The GTM procedures of this document require the use of this type The GTM procedures of this document require the use of this type
of RT, in exactly the same situations where it is used in the MVPN of RT, in exactly the same situations where it is used in the MVPN
specification. However, one adaptation is necessary: the "Local specification [RFC6514]. However, one adaptation is necessary:
Administrator" field of this kind of RT MUST always be set to the Local Administrator field of this kind of RT MUST always be
zero, thus implicitly identifying the global table, rather than set to zero, thus implicitly identifying the global table rather
identifying a VRF. We will refer to this kind of RT as an than identifying a VRF. We will refer to this kind of RT as an
"upstream-node-identifying RT". "upstream-node-identifying RT".
o The other kind of RT is the conventional RT first specified in o The other kind of RT is the conventional RT first specified in
[RFC4364]. It does not necessarily identify a particular router [RFC4364]. It does not necessarily identify a particular router
by address, but is used to constrain the distribution of VPN by address but is used to constrain the distribution of VPN routes
routes, and to ensure that a given VPN route is processed in the and to ensure that a given VPN route is processed in the context
context of a given VRF if and only if the route is carrying an RT of a given VRF if and only if the route is carrying an RT that has
that has been configured as one of that VRF's "import RTs". been configured as one of that VRF's "import RTs".
Whereas every VRF must be configured with at least one import RT, Whereas every VRF must be configured with at least one import RT,
there is heretofore no requirement to configure any RTs for the there has been no requirement to configure any RTs for the global
global table of any router. As stated above, this document makes table of any router until now. As stated above, this document
the use of upstream-node-identifying RTs mandatory for GTM. This makes the use of upstream-node-identifying RTs mandatory for GTM.
document makes the use of non-upstream-node-identifying RTs This document makes the use of non-upstream-node-identifying RTs
OPTIONAL for GTM. OPTIONAL for GTM.
The procedures for the use of RTs in GTM are the following: The procedures for the use of RTs in GTM are the following:
o If the global table of a particular PBR is NOT configured with any o If the global table of a particular PBR is NOT configured with any
import RTs, then a received MCAST-VPN route is processed in the import RTs, then a received MCAST-VPN route is processed in the
context of the global table only if it is carrying no RTs, or if context of the global table only if it is carrying no RTs or if it
it is carrying an upstream-node-identifying RT whose Global is carrying an upstream-node-identifying RT whose Global
Administrator field identifies that PBR. Administrator field identifies that PBR.
o The global table in each PBR MAY be configured with (a) a set of o The global table in each PBR MAY be configured with (a) a set of
export RTs to be attached to MCAST-VPN routes that are originated export RTs to be attached to MCAST-VPN routes that are originated
to support GTM, and (b) with a set of import RTs for GTM. to support GTM and (b) a set of import RTs for GTM.
If the global table of a given PBR has been so configured, the PBR If the global table of a given PBR has been so configured, the PBR
will process a received MCAST-VPN route in the context of the will process a received MCAST-VPN route in the context of the
global table if and only if the route carries an RT that is one of global table if and only if the route carries an RT that is one of
the global table's import RTs, or if the route carries an the global table's import RTs or if the route carries an upstream-
upstream-node-identifying RT whose global administrator field node-identifying RT whose Global Administrator field identifies
identifies the PBR. the PBR.
If the global tables are configured with RTs, care must be taken If the global tables are configured with RTs, care must be taken
to ensure that the RTs configured for the global table are to ensure that the RTs configured for the global table are
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, N.B.: If the "RT Constraint" procedures of [RFC4684] are deployed,
but the MCAST-VPN routes are not carrying RTs, then proper but the MCAST-VPN routes are not carrying RTs, then proper
operation requires the "default behavior" specified for the operation requires the "default behavior" specified for the
MCAST-VPN address family in Section 3 ("Default Behavior") of MCAST-VPN address family in Section 3 ("Default Behavior") of
[RTC_without_RTs]. [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.1 of
"Eligible Routes for UMH Selection") are generally routes of SAFI 128 [RFC6513], "Eligible Routes for UMH Selection") are generally routes
(Labeled VPN-IP routes) or 129 (VPN-IP multicast routes), and are of SAFI 128 (Labeled VPN-IP routes) or 129 (VPN-IP multicast routes)
required to carry RTs. These RTs determine which VRFs import which and are required to carry RTs. These RTs determine which VRFs import
such routes. However, for GTM, when the UMH-eligible routes may be which such routes. However, for GTM, when the UMH-eligible routes
routes of SAFI 1, 2, or 4, the routes are not required to carry RTs. may be routes of SAFI 1, 2, or 4, the routes are not required to
This document does NOT specify any new rules for determining whether carry RTs. This document does NOT specify any new rules for
a SAFI 1, 2, or 4 route is to be imported into the global table of determining whether a SAFI 1, 2, or 4 route is to be imported into
any PBR. the global table of any PBR.
2.3. UMH-eligible Routes 2.3. UMH-Eligible Routes
[RFC6513] section 5.1 defines procedures by which a PE router Section 5.1 of [RFC6513] 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
the "Upstream PBR". the "Upstream PBR".
The definition of the C-root of a flow is the same for GTM as for The definition of the C-root of a flow is the same for GTM as for
MVPN. MVPN.
For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source For MVPN, to determine the UMH, Upstream PE, Upstream RD, and Source
AS of a flow, one looks up the C-root of the flow in a particular AS of a flow, one looks up the C-root of the flow in a particular VRF
VRF, and finds the "UMH-eligible" routes (see section 5.1.1 of and finds the "UMH-eligible" routes (see Section 5.1.1 of [RFC6513])
[RFC6513]) that "match" the C-root. From among these, one is chosen that "match" the C-root. From among these, one is chosen as the
as the "selected UMH route". "Selected UMH Route".
For GTM, the C-root is of course looked up in the global table, For GTM, the C-root is, of course, looked up in the global table,
rather than in a VRF. For MVPN, the UMH-eligible routes are routes rather than in a VRF. For MVPN, the UMH-eligible routes are routes
of SAFI 128 or 129. For GTM, the UMH-eligible routes are routes of of SAFI 128 or 129. For GTM, the UMH-eligible routes are routes of
SAFI 1, SAFI 4, or SAFI 2. If the global table has imported routes SAFI 1, SAFI 4, or SAFI 2. If the global table has imported routes
of SAFI 2, then these are the UMH-eligible routes. Otherwise, routes of SAFI 2, then these are the UMH-eligible routes. Otherwise, routes
of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of of SAFI 1 or SAFI 4 are the UMH-eligible routes. For the purpose of
UMH determination, if a SAFI 1 route and a SAFI 4 route contain the UMH determination, if a SAFI 1 route and a SAFI 4 route contain the
same IP prefix in their respective NLRI fields, then the two routes same IP prefix in their respective NLRI fields, then the two routes
are considered by the BGP bestpath selection process to be are considered by the BGP best-path selection process to be
comparable. comparable.
[RFC6513] defines procedures for determining which of the UMH- [RFC6513] defines procedures for determining which of the UMH-
eligible routes that match a particular C-root is to become the eligible routes that match a particular C-root is to become the
"Selected UMH route". With one exception, these procedures are also Selected UMH Route. With one exception, these procedures are also
applicable to GTM. The one exception is the following. applicable to GTM. The one exception is the following.
Section 9.1.2 of [RFC6513] defines a particular method of choosing Section 9.1.2 of [RFC6513] defines a particular method of choosing
the Upstream PE, known as "Single Forwarder Selection" (SFS). This the Upstream PE, known as "Single Forwarder Selection" (SFS). This
procedure MUST NOT be used for GTM (see Section 2.3.4 for an procedure MUST NOT be used for GTM (see Section 2.3.4 for an
explanation of why the SFS procedure cannot be applied to GTM). explanation of why the SFS procedure cannot be applied to GTM).
In GTM, the "Upstream RD" of a multicast flow is always considered to In GTM, the "Upstream RD" of a multicast flow is always considered to
be zero, and is NOT determined from the Selected UMH route. be zero and is NOT determined from the Selected UMH Route.
The MVPN specifications require that when BGP is used for The MVPN specifications require that when BGP is used for
distributing multicast routing information, the UMH-eligible routes distributing multicast routing information, the UMH-eligible routes
MUST carry the VRF Route Import EC and the Source AS EC. To MUST carry the VRF Route Import EC and the Source AS EC. To
determine the Upstream PE and Source AS for a particular multicast determine the Upstream PE and Source AS for a particular multicast
flow, the Upstream PE and Source AS are determined, respectively, flow, the Upstream PE and Source AS are determined, respectively,
from the VRF Route Import EC and the Source AS EC of the Selected UMH from the VRF Route Import EC and the Source AS EC of the Selected UMH
route for that flow. These ECs are generally attached to the UMH- Route for that flow. These ECs are generally attached to the UMH-
eligible routes by the PEs that originate the routes. eligible routes by the PEs that originate the routes.
In GTM, there are certain situations in which it is allowable to omit In GTM, there are certain situations in which it is allowable to omit
the VRF Route Import EC and/or the Source AS EC from the UMH-eligible the VRF Route Import EC and/or the Source AS EC from the UMH-eligible
routes. The following sub-sections specify the various options for routes. The following sub-sections specify the various options for
determining the Upstream PBR and the Source AS in GTM. determining the Upstream PBR and the Source AS in GTM.
The procedures in Section 2.3.1 MUST be implemented. The procedures The procedures in Section 2.3.1 MUST be implemented. The procedures
in Section 2.3.2 and Section 2.3.3 are OPTIONAL to implement. It in Sections 2.3.2 and 2.3.3 are OPTIONAL to implement. It should be
should be noted that while the optional procedures may be useful in noted that while the optional procedures may be useful in particular
particular deployment scenarios, there is always the potential for deployment scenarios, there is always the potential for
interoperability problems when relying on OPTIONAL procedures. interoperability problems when relying on OPTIONAL procedures.
2.3.1. Routes of SAFI 1, 2 or 4 with MVPN ECs 2.3.1. Routes of SAFI 1, 2, or 4 with MVPN ECs
If the UMH-eligible routes have a SAFI of 1, 2 or 4, then they MAY If the UMH-eligible routes have a SAFI of 1, 2, or 4, then they MAY
carry the VRF Route Import EC and/or the Source AS EC. If the carry the VRF Route Import EC and/or the Source AS EC. If the
selected UMH route is a route of SAFI 1, 2 or 4 that carries the VRF Selected UMH Route is a route of SAFI 1, 2, or 4 that carries the VRF
Route Import EC, then the Upstream PBR is determined from that EC. Route Import EC, then the Upstream PBR is determined from that EC.
Similarly, if the selected UMH route is a route of SAFI 1, 2, or 4 Similarly, if the Selected UMH Route is a route of SAFI 1, 2, or 4
route that carries the Source AS EC, the Source AS is determined from that carries the Source AS EC, the Source AS is determined from that
that EC. EC.
When the procedure of this section is used, a PBR that distributes a When the procedure of this section is used, a PBR that distributes a
UMH-eligible route to other PBRs is responsible for ensuring that the UMH-eligible route to other PBRs is responsible for ensuring that the
VRF Route Import and Source AS ECs are attached to it. VRF Route Import and Source AS ECs are attached to it.
If the selected UMH-eligible route has a SAFI of 1, 2 or 4, but is If the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is
not carrying a VRF Route Import EC, then the Upstream PBR is not carrying a VRF Route Import EC, then the Upstream PBR is
determined as specified in Section 2.3.2 or Section 2.3.3 below. determined as specified in Sections 2.3.2 or 2.3.3.
If the selected UMH-eligible route has a SAFI of 1, 2 or 4, but is If the selected UMH-eligible route has a SAFI of 1, 2, or 4 but is
not carrying a Source AS EC, then the Source AS is considered to be not carrying a Source AS EC, then the Source AS is considered to be
the local AS. the local AS.
2.3.2. MVPN ECs on the Route to the Next Hop 2.3.2. MVPN ECs on the Route to the Next Hop
Some service providers may consider it to be undesirable to have the Some service providers may consider it to be undesirable to have the
PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or PBRs put the VRF Route Import EC on all the UMH-eligible routes. Or
there may be deployment scenarios in which the UMH-eligible routes there may be deployment scenarios in which the UMH-eligible routes
are not advertised by the PBRs at all. The procedures described in are not advertised by the PBRs at all. The procedures described in
this section provide an alternative that can be used under certain this section provide an alternative that can be used under certain
circumstances. circumstances.
The procedures of this section are OPTIONAL. The procedures in this section are OPTIONAL.
In this alternative procedure, each PBR MUST originate a BGP route of In this alternative procedure, each PBR MUST originate a BGP route of
SAFI 1, 2 or 4 whose NLRI is an IP address of the PBR itself. This SAFI 1, 2, or 4 whose NLRI is an IP address of the PBR itself. This
route MUST carry a VRF Route Import EC that identifies the PBR. The route MUST carry a VRF Route Import EC that identifies the PBR. The
address that appears in the Global Administrator field of that EC address that appears in the Global Administrator field of that EC
MUST be the same address that appears in the NLRI and in the Next Hop MUST be the same address that appears in the NLRI and in the Next Hop
field of that route. This route MUST also carry a Source AS EC field of that route. This route MUST also carry a Source AS EC
identifying the AS of the PBR. identifying the AS of the PBR.
Whenever the PBR distributes a UMH-eligible route for which it sets Whenever the PBR distributes a UMH-eligible route for which it sets
itself as next hop, it MUST use this same IP address as the Next Hop itself as Next Hop, it MUST use this same IP address as the Next Hop
of the UMH-eligible route that it used in the route discussed in the of the UMH-eligible route that it used in the route discussed in the
prior paragraph. prior paragraph.
When the procedure of his section is used, then when a PBR is When the procedure in this section is used and when a PBR is
determining the Selected UMH Route for a given multicast flow, it may determining the Selected UMH Route for a given multicast flow, it may
find that the Selected UMH Route has no VRF Route Import EC. In this find that the Selected UMH Route has no VRF Route Import EC. In this
case, the PBR will look up (in the global table) the route to the case, the PBR will look up (in the global table) the route to the
Next Hop of the Selected UMH route. If the route to the Next Hop has Next Hop of the Selected UMH Route. If the route to the Next Hop has
a VRF Route Import EC, that EC will be used to determine the Upstream a VRF Route Import EC, that EC will be used to determine the Upstream
PBR, just as if the EC had been attached to the Selected UMH Route. PBR, just as if the EC had been attached to the Selected UMH Route.
If recursive route resolution is required in order to resolve the If recursive route resolution is required in order to resolve the
next hop, the Upstream PBR will be determined from the first route Next Hop, the Upstream PBR will be determined from the first route
with a VRF Route Import EC that is encountered during the recursive with a VRF Route Import EC that is encountered during the recursive
route resolution process. (The recursive route resolution process route resolution process. (The recursive route resolution process
itself is not modified by this document.) itself is not modified by this document.)
The same procedure can be applied to find the Source AS, except that The same procedure can be applied to find the Source AS, except that
the Source AS EC is used instead of the VRF Route Import EC. the Source AS EC is used instead of the VRF Route Import EC.
Note that this procedure is only applicable in scenarios where it is Note that this procedure is only applicable in scenarios where it is
known that the Next Hop of the UMH-eligible routes is not be changed known that the Next Hop of the UMH-eligible routes is not changed by
by any router that participates in the distribution of those routes; any router that participates in the distribution of those routes;
this procedure MUST NOT be used in any scenario where the next hop this procedure MUST NOT be used in any scenario where the Next Hop
may be changed between the time one PBR distributes the route and may be changed between the time one PBR distributes the route and
another PBR receives it. The PBRs have no way of determining another PBR receives it. The PBRs have no way of determining
dynamically whether the procedure is applicable in a particular dynamically whether the procedure is applicable in a particular
deployment; this must be made known to the PBRs by provisioning. deployment; this must be made known to the PBRs by provisioning.
Some scenarios in which this procedure can be used are: Some scenarios in which this procedure can be used are:
o all PBRs are in the same AS, or o All PBRs are in the same AS.
o the UMH-eligible routes are distributed among the PBRs by a Route o The UMH-eligible routes are distributed among the PBRs by a Route
Reflector (that does not change the next hop), or Reflector (that does not change the Next Hop).
o the UMH-eligible routes are distributed from one AS to another o The UMH-eligible routes are distributed from one AS to another
through ASBRs that do not change the next hop. through ASBRs that do not change the Next Hop.
If the procedures of this section are used in scenarios where they If the procedures of this section are used in scenarios where they
are not applicable, GTM will not function correctly. are not applicable, GTM will not function correctly.
2.3.3. Non-BGP Routes as the UMH-eligible Routes 2.3.3. Non-BGP Routes as the UMH-Eligible Routes
In particular deployment scenarios, there may be specific procedures In particular deployment scenarios, there may be specific procedures
that can be used, in those particular scenarios, to determine the that can be used, in those particular scenarios, to determine the
Upstream PBR for a given multicast flow. Upstream PBR for a given multicast flow.
Suppose the PBRs neither put the VRF Route Import EC on the UMH- Suppose the PBRs neither put the VRF Route Import EC on the UMH-
eligible routes, nor do they distribute BGP routes to themselves. It eligible routes, nor distribute BGP routes with their own addresses
may still be possible to determine the Upstream PBR for a given in the NLRI. It may still be possible, by using specific knowledge
multicast flow, using specific knowledge about the deployment. about the deployment, to determine the Upstream PBR for a given
multicast flow.
For example, suppose it is known that all the PBRs are in the same For example, suppose it is known that all the PBRs are in the same
OSPF area. It may be possible to determine the Upstream PBR for a OSPF area. It may be possible to determine the Upstream PBR for a
given multicast flow by looking at the link state database to see given multicast flow by looking at the link state database to see
which router is attached to the flow's C-root. which router is attached to the flow's C-root.
As another example, suppose it is known that the set of PBRs is fully As another example, suppose it is known that the set of PBRs is fully
meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in meshed via Traffic Engineering (TE) tunnels. When a PBR looks up, in
its global table, the C-root of a particular multicast flow, it may its global table, the C-root of a particular multicast flow, it may
find that the next hop interface is a particular TE tunnel. If it find that the next-hop interface is a particular TE tunnel. If it
can determine the identify of the router at the other end of that TE can determine the identity of the router at the other end of that TE
tunnel, it can deduce that that router is the Upstream PBR for that tunnel, it can deduce that the router is the Upstream PBR for that
flow. flow.
This is not an exhaustive set of examples. Any procedure that This is not an exhaustive set of examples. Any procedure that
correctly determines the Upstream PBR in a given deployment scenario correctly determines the Upstream PBR in a given deployment scenario
MAY be used in that scenario. MAY be used in that scenario.
2.3.4. Why SFS Does Not Apply to GTM 2.3.4. Why SFS Does Not Apply to GTM
To see why the SFS procedure cannot be applied to GTM, consider the To see why the SFS procedure cannot be applied to GTM, consider the
following example scenario. Suppose some multicast source S is homed following example scenario. Suppose some multicast source S is homed
to both PBR1 and PBR2, and suppose that both PBRs export a route (of to both PBR1 and PBR2, and suppose that both PBRs export a route (of
SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S. SAFI 1, 2, or 4) whose NLRI is a prefix matching the address of S.
These two routes will be considered comparable by the BGP decision These two routes will be considered comparable by the BGP decision
process. A route reflector receiving both routes may thus choose to process. A route reflector receiving both routes may thus choose to
redistribute just one of the routes to S, the one chosen by the redistribute just one of the routes to S, the one chosen by the best-
bestpath algorithm. Different route reflectors may even choose path algorithm. Different route reflectors may even choose different
different routes to redistribute (i.e., one route reflector may routes to redistribute (i.e., one route reflector may choose the
choose the route to S via PBR1 as the bestpath, while another chooses route to S via PBR1 as the best path, while another chooses the route
the route to S via PBR2 as the bestpath). As a result, some PBRs may to S via PBR2 as the best path). As a result, some PBRs may receive
receive only the route to S via PBR1 and some may receive only the only the route to S via PBR1, and some may receive only the route to
route to S via PBR2. In that case, it is impossible to ensure that S via PBR2. In that case, it is impossible to ensure that all PBRs
all PBRs will choose the same route to S. will choose the same route to S.
The SFS procedure works in VPN context as long as the following The SFS procedure works in VPN context as long as the following
assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2, assumption holds: if S is homed to VRF-x in PE1 and to VRF-y in PE2,
then VRF-x and VRF-y have been configured with different RDs. In VPN then VRF-x and VRF-y have been configured with different RDs. In VPN
context, the route to S is of SAFI 128 or 129, and thus has an RD in context, the route to S is of SAFI 128 or 129 and thus has an RD in
its NLRI. So the route to S via PE1 will not have the same NLRI as its NLRI. So the route to S via PE1 will not have the same NLRI as
the route to S via PE2. As a result, all PEs will see both routes, the route to S via PE2. As a result, all PEs will see both routes,
and the PEs can implement a procedure that ensures that they all pick and the PEs can implement a procedure that ensures that they all pick
the same route to S. the same route to S.
That is, the SFS procedure of [RFC6513] relies on the UMH-eligible That is, the SFS procedure of [RFC6513] relies on the UMH-eligible
routes being of SAFI 128 or 129, and relies on certain VRFs being routes being of SAFI 128 or 129 and relies on certain VRFs being
configured with distinct RDs. Thus the procedure cannot be applied configured with distinct RDs. Thus, the procedure cannot be applied
to GTM. to GTM.
One might think that the SFS procedure could be applied to GTM as One might think that the SFS procedure could be applied to GTM as
long as the procedures defined in [ADD-PATH] are applied to the UMH- long as the procedures defined in [ADD-PATH] are applied to the UMH-
eligible routes. Using the [ADD-PATH] procedures, the BGP speakers eligible routes. Using the [ADD-PATH] procedures, the BGP speakers
could advertise more than one path to a given prefix. Typically could advertise more than one path to a given prefix. Typically,
[ADD-PATH] is used to report the n best paths, for some small value [ADD-PATH] is used to report the n best paths, for some small value
of n. However, this is not sufficient to support SFS, as can be seen of n. However, this is not sufficient to support SFS, as can be seen
by examining the following scenario. by examining the following scenario:
AS-X | AS-Y | AS-Z AS-X | AS-Y | AS-Z
| | | |
S--PBR1---ASBR1--|--ASBR2--|---ASBR5 S--PBR1---ASBR1--|--ASBR2--|---ASBR5
| \______/ | | | \______/ | |
| / \ | | | / \ | |
|--PBR2---ASBR3--|--ASBR4--|---ASBR6 |--PBR2---ASBR3--|--ASBR4--|---ASBR6
| | | |
In AS-X, PBR1 reports to both ASBR1 and ASBR3 that it has a route to In AS-X, PBR1 reports to both ASBR1 and ASBR3 that it has a route to
S. Similarly, PBR2 reports to both ASBR1 and ASBR3 that it has a S. Similarly, PBR2 reports to both ASBR1 and ASBR3 that it has a
route to S. Using [ADD-PATH], ASBR1 reports both routes to ASBR2, route to S. Using the procedures in [ADD-PATH], ASBR1 reports both
and ASBR3 reports both routes to ASBR4. Now AS-Y sees 4 paths to S. routes to ASBR2, and ASBR3 reports both routes to ASBR4. Now AS-Y
The AS-Z ASBRs will each see eight paths (four via ASBR2 and four via sees 4 paths to S. The AS-Z ASBRs will each see eight paths (four
ASBR4). To avoid this explosion in the number of paths, a BGP via ASBR2 and four via ASBR4). To avoid this explosion in the number
speaker that uses [ADD-PATH] is usually considered to report only the of paths, a BGP speaker that uses [ADD-PATH] is usually considered to
n best paths. However, there is then no guarantee that the reported report only the n best paths. However, there is then no guarantee
set of paths will contain at least one path via PBR1 and at least one that the reported set of paths will contain at least one path via
path via PBR2. Without such a guarantee, the SFS procedure will not PBR1 and at least one path via PBR2. Without such a guarantee, the
work. SFS procedure will not work.
2.4. Inclusive and Selective Tunnels 2.4. Inclusive and Selective Tunnels
The MVPN specifications allow multicast flows to be carried on either The MVPN specifications allow multicast flows to be carried on either
Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an Inclusive Tunnels or on Selective Tunnels. When a flow is sent on an
Inclusive Tunnel of a particular VPN, it is sent to all PEs in that Inclusive Tunnel of a particular VPN, it is sent to all PEs in that
VPN. When sent on a Selective Tunnel of a particular VPN, it may be VPN. When sent on a Selective Tunnel of a particular VPN, it may be
sent to only a subset of the PEs in that VPN. sent to only a subset of the PEs in that VPN.
This document allows the use of either Inclusive Tunnels or Selective This document allows the use of either Inclusive Tunnels or Selective
Tunnels for GTM. However, any service provider electing to use Tunnels for GTM. However, any service provider electing to use
Inclusive Tunnels for GTM should carefully consider whether sending a Inclusive Tunnels for GTM should carefully consider whether sending a
multicast flow to ALL its PBRs would result in problems of scale. multicast flow to ALL its PBRs would result in problems of scale.
There are potentially many more MBRs for GTM than PEs for a There are potentially many more PBRs for GTM than PEs for a
particular VPN. If the set of PBRs is large and growing, but most particular VPN. If the set of PBRs is large and growing, but most
multicast flows do not need to go to all the PBRs, the exclusive use multicast flows do not need to go to all the PBRs, the exclusive use
of Selective Tunnels may be a better option. of Selective Tunnels may be a better option.
2.5. I-PMSI A-D Routes 2.5. I-PMSI A-D Routes
2.5.1. Intra-AS I-PMSI A-D Routes 2.5.1. Intra-AS I-PMSI A-D Routes
Per [MVPN-BGP}, there are certain conditions under which is it NOT Per [RFC6514], there are certain conditions under which it is NOT
required for a PE router implementing MVPN to originate one or more required for a PE router implementing MVPN to originate one or more
Intra-AS I-PMSI A-D routes. These conditions apply as well to PBRs Intra-AS Inclusive Provider Multicast Service Interface (I-PMSI) A-D
implementing GTM. routes. These conditions also apply to PBRs implementing GTM.
In addition, a PBR implementing GTM is NOT required to originate an In addition, a PBR implementing GTM is NOT required to originate an
Intra-AS I-PMSI A-D route if both of the following conditions hold: Intra-AS I-PMSI A-D route if both of the following conditions hold:
o The PBR is not using Inclusive Tunnels for GTM, and o The PBR is not using Inclusive Tunnels for GTM, and
o The distribution of the C-multicast Shared Tree Join and o The distribution of the C-multicast Shared Tree Join and
C-multicast Source Tree Join routes is done in such a manner that C-multicast Source Tree Join routes is done in such a manner that
the next hop of those routes does not change. the Next Hop of those routes does not change.
Please see also the sections on RD and RT usage (Sections 2.1 and 2.2 Please see also the sections on RD and RT usage (Sections 2.1 and
respectively). 2.2, respectively).
2.5.2. Inter-AS I-PMSI A-D Routes 2.5.2. Inter-AS I-PMSI A-D Routes
There are no GTM-specific procedures for the origination, There are no GTM-specific procedures for the origination,
distribution, and processing of these routes, other than those distribution, and processing of these routes, other than those
specified in the sections on RD and RT usage. specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
2.6. S-PMSI A-D Routes 2.6. S-PMSI A-D Routes
There are no GTM-specific procedures for the origination, There are no GTM-specific procedures for the origination,
distribution, and processing of these routes, other than those distribution, and processing of these routes, other than those
specified in the sections on RD and RT usage. specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
2.7. Leaf A-D Routes 2.7. Leaf A-D Routes
There are no GTM-specific procedures for the origination, There are no GTM-specific procedures for the origination,
distribution, and processing of these routes, other than those distribution, and processing of these routes, other than those
specified in the sections on RD and RT usage. specified in the sections on RD and RT usage (Sections 2.1 and 2.2).
2.8. Source Active A-D Routes 2.8. Source Active A-D Routes
Please see the sections on RD and RT usage for information applies to Please see the sections on RD and RT usage (Sections 2.1 and 2.2) for
the origination and distribution of Source Active A-D routes. information that applies to the origination and distribution of
Additional procedures governing the use of Source Active A-D routes Source Active A-D routes. Additional procedures governing the use of
are given in the sub-sections of this section. Source Active A-D routes are given in the sub-sections of this
section.
2.8.1. Finding the Originator of an SA A-D Route 2.8.1. Finding the Originator of an SA A-D Route
To carry out the procedures specified in [RFC6514] (e.g., in To carry out the procedures specified in [RFC6514] (e.g., in
Section 13.2 of that document), it is sometimes necessary for an Section 13.2 of that document), it is sometimes necessary for an
egress PE to determine the ingress PE that originated a given Source egress PE to determine the ingress PE that originated a given Source
Active A-D route. The procedure used in [RFC6514] to find the Active A-D route. The procedure used in [RFC6514] to find the
originator of a Source Active A-D route assumes that no two routes originator of a Source Active A-D route assumes that no two routes
have the same RD unless they have been originated by the same PE. have the same RD unless they have been originated by the same PE.
However, this assumption is not valid in GTM, because each Source However, this assumption is not valid in GTM, because each Source
skipping to change at page 15, line 6 skipping to change at page 14, line 46
procedure for determining the originator of a Source Active A-D procedure for determining the originator of a Source Active A-D
route. route.
In GTM, the procedure for determining the originating PE of a Source In GTM, the procedure for determining the originating PE of a Source
Active A-D route is the following: Active A-D route is the following:
o When a Source Active A-D route is originated, the originating PE o When a Source Active A-D route is originated, the originating PE
MAY attach a VRF Route Import Extended Community to the route. MAY attach a VRF Route Import Extended Community to the route.
o When a Source Active A-D route is distributed by one BGP speaker o When a Source Active A-D route is distributed by one BGP speaker
to another, then to another, then:
* if the Source Active A-D route does not carry the VRF Route * If the Source Active A-D route does not carry the VRF Route
Import EC, the BGP speaker distributing the route MUST NOT Import EC, the BGP speaker distributing the route MUST NOT
change the route's next hop field; change the route's Next Hop field.
* if the Source Active A-D route does carry the VRF Route Import * If the Source Active A-D route does carry the VRF Route Import
EC, the BGP speaker distributing the route MAY change the EC, the BGP speaker distributing the route MAY change the
route's next hop field to itself. route's Next Hop field to itself.
o When an egress PE needs to determine the originator of a Source o When an egress PE needs to determine the originator of a Source
Active A-D route, then Active A-D route, then:
* if the Source Active A-D route carries the VRF Route Import EC, * If the Source Active A-D route carries the VRF Route Import EC,
the originating PE is the PE identified in the Global the originating PE is the PE identified in the Global
Administrator field of that EC; Administrator field of that EC.
* if the Source Active A-D route does not carry the VRF Route * If the Source Active A-D route does not carry the VRF Route
Import EC, the originating PE is the PE identified in the Import EC, the originating PE is the PE identified in the
route's next hop field. route's Next Hop field.
2.8.2. Optional Additional Constraints on Distribution 2.8.2. Optional Additional Constraints on Distribution
If some site has receivers for a particular ASM group G, then it is If some site has receivers for a particular ASM group G, then it is
possible (by the procedures of [RFC6514]) that every PBR attached to possible (by the procedures of [RFC6514]) that every PBR attached to
a site with a source for group G will originate a Source Active A-D a site with a source for group G will originate a Source Active A-D
route whose NLRI identifies that source and group. These Source route whose NLRI identifies that source and group. These Source
Active A-D routes may be distributed to every PBR. If only a Active A-D routes may be distributed to every PBR. If only a
relatively small number of PBRs are actually interested in traffic relatively small number of PBRs are actually interested in traffic
from group G, but there are many sources for group G, this could from group G, but there are many sources for group G, this could
skipping to change at page 15, line 51 skipping to change at page 15, line 44
group G. This can be done using the following OPTIONAL procedures: group G. This can be done using the following OPTIONAL procedures:
o If a PBR originates a C-multicast Shared Tree Join whose NLRI o If a PBR originates a C-multicast Shared Tree Join whose NLRI
contains (RD=0,*,G), then it dynamically creates an import RT for contains (RD=0,*,G), then it dynamically creates an import RT for
its global table, where the Global Administrator field of the RT its global table, where the Global Administrator field of the RT
contains the group address G, and the Local Administrator field contains the group address G, and the Local Administrator field
contains zero. (Note that an IPv6-address-specific RT would need contains zero. (Note that an IPv6-address-specific RT would need
to be used if the group address is an IPv6 address.) to be used if the group address is an IPv6 address.)
o When a PBR creates such an import RT, it uses "RT Constraint" o When a PBR creates such an import RT, it uses "RT Constraint"
[RFC4684] procedures to advertise its interest in routes that procedures [RFC4684] to advertise its interest in routes that
carry this RT. carry this RT.
o When a PBR originates a Source Active A-D route from its global o When a PBR originates a Source Active A-D route from its global
table, it attaches the RT described above. table, it attaches the RT described above.
o When the C-multicast Shared Tree Join is withdrawn, so is the o When the C-multicast Shared Tree Join is withdrawn, so is the
corresponding RT constrain route, and the corresponding RT is corresponding RT constrain route, and the corresponding RT is
removed as an import RT of its global table. removed as an import RT of its global table.
These procedures enable a PBR to automatically filter all Source These procedures enable a PBR to automatically filter all Source
Active A-D routes that are about multicast groups in which the PBR Active A-D routes that are about multicast groups in which the PBR
has no interest. has no interest.
This procedure does introduce the overhead of distributing additional This procedure does introduce the overhead of distributing additional
"RT Constraint" routes, and therefore may not be cost-effective in "RT Constraint" routes and therefore may not be cost-effective in all
all scenarios, especially if the number of sources per ASM group is scenarios, especially if the number of sources per ASM group is
small. This procedure may also result in increased join latency. small. This procedure may also result in increased join latency.
2.9. C-multicast Source/Shared Tree Joins 2.9. C-Multicast Source/Shared Tree Joins
Section 11.1.3 of [RFC6514] describes how to determine the IP- Section 11.1.3 of [RFC6514] describes how to determine the IP-
address-specific RT(s) that should be attached to a C-multicast address-specific RT(s) that should be attached to a C-multicast
route. The "upstream PE", "upstream RD", and "source AS" (as defined route. The "Upstream PE", "Upstream RD", and "Source AS" (as defined
in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are in Section 5 of [RFC6513]) for the NLRI of the C-multicast route are
first determined. An IP-address-specific RT whose "global first determined. An IP-address-specific RT whose Global
administrator" field carries the IP address of the upstream PE is Administrator field carries the IP address of the Upstream PE is then
then attached to the C-multicast route. This procedure applies as attached to the C-multicast route. This procedure also applies to
well to GTM, except that the "upstream PE" is actually an "upstream GTM, except that the "Upstream PE" is actually an "Upstream PBR".
PBR".
Section 11.1.3 of [RFC6514] also specifies that a second IP-address Section 11.1.3 of [RFC6514] also specifies that a second IP-address-
specific RT be attached to the C-multicast route, if the source AS of specific RT be attached to the C-multicast route, if the Source AS of
the NLRI of that route is different than the AS of the PE originating the NLRI of that route is different than the AS of the PE originating
the route. The procedure for creating this RT may be summarized as: the route. The procedure for creating this RT may be summarized as:
(a) determine the upstream PE, upstream RD,and source AS (a) Determine the Upstream PE, Upstream RD, and Source AS
corresponding to the NLRI of the route; corresponding to the NLRI of the route.
(b) find the corresponding Inter-AS or Intra-AS I-PMSI A-D route (b) Find the corresponding Inter-AS or Intra-AS I-PMSI A-D route
based on (a); based on (a).
(c) find the next hop of that A-D route; (c) Find the Next Hop of that A-D route.
(d) place the IP address of that next hop in the global (d) Place the IP address of that Next Hop in the Global
administrator field of the RT. Administrator field of the RT.
However, for GTM, in scenarios where it is known a priori by a PBR However, for GTM, in scenarios where it is known a priori by a PBR
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 second RT not change during the distribution of those routes, the second RT
(the one based on the next hop of an I-PMSI A-D route) is not needed, (the one based on the Next Hop of an I-PMSI A-D route) is not needed
and should not be present. In other scenarios, the procedure of and should not be present. In other scenarios, the procedure of
section 11.1.3 of [RFC6513] (as modified by this document's sections Section 11.1.3 of [RFC6514] (as modified by Sections 2.1 and 2.2 of
on "RD usage" and "RT usage") is applied by the PBRs. this document) is applied by the PBRs.
3. Differences from other MVPN-like GTM Procedures 3. Differences from Other MVPN-Like GTM Procedures
The document [RFC7524] also defines a procedure for GTM that is based [RFC7524] also defines a procedure for GTM that is based on the BGP
on the BGP procedures that were developed for MVPN. procedures that were developed for MVPN.
However, the GTM procedures of [RFC7524] are different than and are However, the GTM procedures of [RFC7524] are different than and are
NOT interoperable with the procedures defined in this document. NOT interoperable with the procedures defined in this 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 [RFC7524] procedures for GTM do not use C-multicast Shared o The procedures for GTM described in [RFC7524] do not use
Tree Joins or C-multicast Source Tree Joins at all. The C-multicast Shared Tree Joins or C-multicast Source Tree Joins at
procedures of this document use these C-multicast routes for GTM, all. The procedures of this document use these C-multicast routes
setting the RD field of the NLRI to zero. for GTM, setting the RD field of the NLRI to zero.
o The [RFC7524] procedures for GTM use Leaf A-D routes instead of o The procedures for GTM described in [RFC7524] use Leaf A-D routes
C-multicast Shared/Source Tree Join routes. Leaf A-D routes used instead of C-multicast Shared/Source Tree Join routes. Leaf A-D
in that manner can be distinguished from Leaf A-D routes used as routes used in that manner can be distinguished from Leaf A-D
specified in [RFC6514] by means of the NLRI format; [RFC7524] routes used as specified in [RFC6514] by means of the NLRI format;
defines a new NLRI format for Leaf A-D routes. Whether a given [RFC7524] defines a new NLRI format for Leaf A-D routes. Whether
Leaf A-D route is being used according to the [RFC7524] procedures or not a given Leaf A-D route is being used according to the
or not can be determined from its NLRI. (See [RFC7524] section procedures described in [RFC7524] can be determined from its NLRI.
"Leaf A-D Route for Global Table Multicast".) (See Section 6.2.2 ("Leaf A-D Route for Global Table Multicast")
of [RFC7524]).
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 [RFC7524]. The procedures assumed by this document for defined in [RFC7524]. The procedures assumed by this document for
originating and processing Leaf A-D routes are as specified in originating and processing Leaf A-D routes are as specified in
[RFC6514], NOT as specified in [RFC7524]. [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. [RFC7524] uses two are inferred from the fact that RD is zero. [RFC7524] uses 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 [RFC7524]. all egress PBRs use the GTM procedures of [RFC7524]).
4. IANA Considerations
This document has no IANA considerations.
5. Security Considerations 4. 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].
The protocols and procedures described in this document make use of a The protocols and procedures described in this document make use of a
type of route (routes with the "MCAST-VPN" BGP SAFI) that was type of route (routes with the "MCAST-VPN" BGP SAFI) that was
originally designed for use in VPN contexts only. The protocols and originally designed for use in VPN contexts only. The protocols and
procedures described in this document also make use of various BGP procedures described in this document also make use of various BGP
path attributes and extended communities (VRF Route Import Extended path attributes and extended communities (VRF Route Import Extended
Community, Source AS Extended Community, Route Target Extended Community, Source AS Extended Community, and Route Target Extended
Community) that were originally intended for use in VPN contexts. If Community) that were originally intended for use in VPN contexts. If
these routes, attributes, and/or extended communities leak out into these routes, attributes, and/or extended communities leak out into
"the wild", multicast data flows may be distributed in an unintended the wild, multicast data flows may be distributed in an unintended
and/or unauthorized manner. and/or unauthorized manner.
When VPNs are provisioned, each VRF is configured with import RTs and When VPNs are provisioned, each VRF is configured with import RTs and
export RTs. These RTs constrain the distribution and the import of export RTs. These RTs constrain the distribution and the import of
the VPN routes, making it difficult to cause a route to be the VPN routes, making it difficult to cause a route to be
distributed to and imported by a VRF that is not authorized to import distributed to and imported by a VRF that is not authorized to import
that route. Additionally, VPN routes do not go into the "global that route. Additionally, VPN routes do not go into the "global
table" with the "ordinary Internet routes" (i.e., non-VPN routes), table" with the "ordinary Internet routes" (i.e., non-VPN routes),
and non-VPN routes do not impact the flow of multicast data within a and non-VPN routes do not impact the flow of multicast data within a
VPN. In GTM, some of these protections against improper VPN. In GTM, some of these protections against improper
skipping to change at page 19, line 6 skipping to change at page 18, line 44
Internet Service Providers often make extensive use of BGP extended Internet Service Providers often make extensive use of BGP extended
communities, sometimes adding, deleting, and/or modifying a route's communities, sometimes adding, deleting, and/or modifying a route's
extended communities as the route is distributed throughout the extended communities as the route is distributed throughout the
network. Care should be taken to avoid deleting or modifying the VRF network. Care should be taken to avoid deleting or modifying the VRF
Route Import Extended Community and Source AS Extended Community. Route Import Extended Community and Source AS Extended Community.
Incorrect manipulation of these extended communities may result in Incorrect manipulation of these extended communities may result in
multicast streams being lost or misrouted. multicast streams being lost or misrouted.
The procedures of this document require certain BGP routes to carry The procedures of this document require certain BGP routes to carry
IP multicast group addresses. Generally such group addresses are IP multicast group addresses. Generally, such group addresses are
only valid within a certain scope. If a BGP route containing a group only valid within a certain scope. If a BGP route containing a group
address is distributed outside the boundaries where the group address address is distributed outside the boundaries where the group address
is meaningful, unauthorized distribution of multicast data flows may is meaningful, unauthorized distribution of multicast data flows may
occur. occur.
6. Additional Contributors 5. References
Jason Schiller
Google
Suite 400
1818 Library Street
Reston, Virginia 20190
United States
Email: jschiller@google.com
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Wei Meng
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: wang.cui1@zte.com.cn
Shunwan Zhuang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
7. Acknowledgments
The authors and contributors would like to thank Rahul Aggarwal,
Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas
and comments.
8. References
8.1. Normative References 5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
skipping to change at page 20, line 38 skipping to change at page 19, line 32
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <http://www.rfc-editor.org/info/rfc6514>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
Addresses in BGP Updates for Multicast VPN", RFC 6515, Addresses in BGP Updates for Multicast VPN", RFC 6515,
DOI 10.17487/RFC6515, February 2012, DOI 10.17487/RFC6515, February 2012,
<http://www.rfc-editor.org/info/rfc6515>. <http://www.rfc-editor.org/info/rfc6515>.
8.2. Informative References 5.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", Work in
"Advertisement of Multiple Paths in BGP", internet-draft Progress, draft-ietf-idr-add-paths-12, November 2015.
draft-ietf-idr-add-paths-10, October 2014.
[MVPN-extranet] [MVPN-extranet]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet- Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in
draft draft-ietf-bess-mvpn-extranet-02, May 2015. Progress, draft-ietf-bess-mvpn-extranet-04, November 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, Protocol Specification (Revised)", RFC 4601,
DOI 10.17487/RFC4601, August 2006, DOI 10.17487/RFC4601, August 2006,
<http://www.rfc-editor.org/info/rfc4601>. <http://www.rfc-editor.org/info/rfc4601>.
[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
skipping to change at page 21, line 38 skipping to change at page 20, line 32
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>. <http://www.rfc-editor.org/info/rfc7524>.
[RTC_without_RTs] [RTC_without_RTs]
Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route Rosen, E., Ed., Patel, K., Haas, J., and R. Raszuk, "Route
Target Constrained Distribution of Routes with no Route Target Constrained Distribution of Routes with no Route
Targets", internet-draft draft-ietf-idr-rtc-no-rt-01, June Targets", Work in Progress, draft-ietf-idr-rtc-no-rt-04,
2015. November 2015.
Acknowledgments
The authors and contributors would like to thank Rahul Aggarwal,
Huajin Jeng, Hui Ni, Yakov Rekhter, and Samir Saad for their ideas
and comments.
Contributors
Jason Schiller
Google
Suite 400
1818 Library Street
Reston, Virginia 20190
United States
Email: jschiller@google.com
Zhenbin Li
Huawei Technologies
Huawei Blvd., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Wei Meng
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: meng.wei2@zte.com.cn,vally.meng@gmail.com
Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: wang.cui1@zte.com.cn
Shunwan Zhuang
Huawei Technologies
Huawei Blvd., No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Authors' Addresses Authors' Addresses
Zhaohui Zhang Zhaohui Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US United States
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
Herndon, Virginia 20171 Herndon, Virginia 20171
US United States
Email: lenny@juniper.net Email: lenny@juniper.net
Eric C. Rosen (editor) Eric C. Rosen (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, Massachusetts 01886 Westford, Massachusetts 01886
US United States
Email: erosen@juniper.net Email: erosen@juniper.net
Karthik Subramanian Karthik Subramanian
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US United States
Email: kartsubr@cisco.com Email: kartsubr@cisco.com
Dante J. Pacella Dante J. Pacella
Verizon Verizon
22001 Loudoun County Parkway 22001 Loudoun County Parkway
Ashburn, Virginia 95134 Ashburn, Virginia 95134
US United States
Email: dante.j.pacella@verizonbusiness.com Email: dante.j.pacella@verizonbusiness.com
 End of changes. 124 change blocks. 
321 lines changed or deleted 317 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/