summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7988.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7988.txt')
-rw-r--r--doc/rfc/rfc7988.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7988.txt b/doc/rfc/rfc7988.txt
new file mode 100644
index 0000000..2d428be
--- /dev/null
+++ b/doc/rfc/rfc7988.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Rosen, Ed.
+Request for Comments: 7988 Juniper Networks, Inc.
+Updates: 6513, 6514 K. Subramanian
+Category: Standards Track Sproute Networks
+ISSN: 2070-1721 Z. Zhang
+ Juniper Networks, Inc.
+ October 2016
+
+
+ Ingress Replication Tunnels in Multicast VPN
+
+Abstract
+
+ RFCs 6513, 6514, and other RFCs describe procedures by which a
+ Service Provider may offer Multicast VPN (MVPN) service to its
+ customers. These procedures create point-to-multipoint (P2MP) or
+ multipoint-to-multipoint (MP2MP) trees across the Service Provider's
+ backbone. One type of P2MP tree that may be used is known as an
+ "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node
+ need not be directly connected to its child nodes. When a parent
+ node has to send a multicast data packet to its n child nodes, it
+ does not use Layer 2 multicast, IP multicast, or MPLS multicast to do
+ so. Rather, it makes n individual copies, and then unicasts each
+ copy, through an IP or MPLS unicast tunnel, to exactly one child
+ node. While the prior MVPN specifications allow the use of IR
+ tunnels, those specifications are not always very clear or explicit
+ about how the MVPN protocol elements and procedures are applied to IR
+ tunnels. This document updates RFCs 6513 and 6514 by adding
+ additional details that are specific to the use of IR tunnels.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ 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/rfc7988.
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 1]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5
+ 3. How are IR P-tunnels identified? . . . . . . . . . . . . . . 7
+ 4. How to Join an IR P-Tunnel . . . . . . . . . . . . . . . . . 9
+ 4.1. Advertised IR P-Tunnels . . . . . . . . . . . . . . . . . 9
+ 4.1.1. If the Leaf Information Required Bit Is Set . . . . . 10
+ 4.1.2. If the Leaf Information Required Bit Is Not Set . . . 10
+ 4.2. Unadvertised IR P-Tunnels . . . . . . . . . . . . . . . . 11
+ 5. The PTA's Tunnel Identifier Field . . . . . . . . . . . . . . 11
+ 6. A Note on IR P-Tunnels and Discarding Packets from the Wrong
+ PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 7. The PTA's MPLS Label Field . . . . . . . . . . . . . . . . . 14
+ 7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14
+ 7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 16
+ 7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17
+ 8. How A Child Node Prunes Itself from an IR P-Tunnel . . . . . 17
+ 9. Parent Node Actions upon Receiving Leaf A-D Route . . . . . . 18
+ 10. Use of Timers When Switching UMH . . . . . . . . . . . . . . 19
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
+ 12.2. Informative References . . . . . . . . . . . . . . . . . 21
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 2]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+1. Introduction
+
+ RFCs 6513, 6514, and other RFCs describe procedures by which a
+ Service Provider (SP) may offer Multicast VPN (MVPN) service to its
+ customers. These procedures create point-to-multipoint (P2MP) or
+ multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels"
+ (provider tunnels), across the SP's backbone network. Customer
+ multicast traffic is carried through the P-tunnels.
+
+ A number of different P-tunnel technologies are supported. One of
+ the supported P-tunnel technologies is known as "ingress replication"
+ or "unicast replication". We will use the acronym "IR" to refer to
+ this P-tunnel technology.
+
+ An IR P-tunnel is a P2MP tree, but a given node on the tree is not
+ necessarily directly attached to its parent node or to its child
+ nodes. To send a multicast data packet from a parent node to one of
+ its child nodes, the parent node encapsulates the packet and then
+ unicasts it through a tunnel to the child node. The tunnel may be a
+ P2P or MP2P MPLS LSP (Label Switched Path) or a unicast IP tunnel.
+ If a node on an IR tree has n child nodes, and has a multicast data
+ packet that must be sent along the tree, the parent node makes n
+ individual copies of the data packet, and then sends each copy,
+ through a unicast tunnel, to exactly one child node. No lower-layer
+ multicast technology is used when sending traffic from a parent node
+ to a child node; therefore, multiple copies of the packet may be sent
+ out a single interface.
+
+ With the single exception of IR, the P-tunnel technologies supported
+ by the MVPN specifications are preexisting IP multicast or MPLS
+ multicast technologies. Each such technology has its own set of
+ specifications, its own setup and maintenance protocols, its own
+ syntax for identifying specific multicast trees, and its own
+ procedures for enabling a router to be added to or removed from a
+ particular multicast tree. For IR P-tunnels, on the other hand,
+ there is no prior specification for setting up and maintaining the
+ P2MP trees; the procedures and protocol elements used for setting up
+ and maintaining the P2MP trees are specified in the MVPN
+ specifications themselves, and all the signaling/setup is done by
+ using the BGP Auto-Discovery (A-D) routes that are defined in
+ [RFC6514]. (The unicast tunnels used to transmit multicast data from
+ one node to another in an IR P-tunnel may of course have their own
+ setup and maintenance protocols, e.g., [RFC5036], [RFC3209].)
+
+ Since the transmission of a multicast data packet along an IR
+ P-tunnel is done by transmitting the packet through a unicast tunnel,
+ previous RFCs sometimes describe an IR P-tunnel as "consisting of" a
+ set of unicast tunnels. However, that description is not quite
+
+
+
+Rosen, et al. Standards Track [Page 3]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ accurate. For one thing, it obscures the fact that an IR P-tunnel is
+ really a P2MP tree, whose nodes must maintain multicast state in both
+ the control and data planes. For another, it obscures the fact the
+ unicast tunnels used by a particular IR P-tunnel need not be specific
+ to that P-tunnel; a single unicast tunnel can carry the multicast
+ traffic of many different IR P-tunnels (and can also carry unicast
+ traffic as well).
+
+ In this document, we provide a clearer and more explicit conceptual
+ model for IR P-tunnels, clarifying the relationship between an IR
+ P-tunnel and the unicast tunnels that are used for data transmission
+ along the IR P-tunnel.
+
+ Section 5 of [RFC6514] defines a BGP Path Attribute known as the
+ "PMSI (Provider Multicast Service Interface) Tunnel attribute" (PTA).
+ This attribute contains a field known as the "Tunnel Identifier"
+ field. For most P-tunnel technologies, the PTA's "Tunnel Identifier"
+ field is used to identify a P-tunnel (i.e., to identify a P2MP or
+ MP2MP tree). However, when IR P-tunnels are used, the PTA "Tunnel
+ Identifier" field does not actually identify an IR P-tunnel. In some
+ cases, it identifies one of the P-tunnel's constituent unicast
+ tunnels; in other cases, it is not used to identify a tunnel at all.
+ In this document, we provide an explicit specification for how IR
+ P-tunnels are actually identified.
+
+ Some of the MVPN specifications specify procedures that require a PE
+ router to join the P-tunnel that has been identified in a particular
+ MVPN route. However, up to now, there has not been an explicit
+ specification of how to identify an IR P-tunnel, of how a router
+ joins such a P-tunnel, or of how a router prunes itself from such a
+ P-tunnel. In this document, we make these procedures more explicit.
+
+ [RFC6514] does provide a method for binding an MPLS label to a
+ P-tunnel, but does not discuss the label allocation policies that are
+ needed for correct operation when the P-tunnel is an IR P-tunnel.
+ Those policies are discussed in this document.
+
+ This document does not provide any new protocol elements or any
+ fundamentally new procedures; its purpose is to make explicit just
+ how a router is to use the protocol elements and procedures of
+ [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR
+ P-tunnel, and to prune itself from an IR P-tunnel.
+
+ This document also discusses the MPLS label allocation policies that
+ need to be supported when binding MPLS labels to IR P-tunnels, and
+ the timer policies that need to be supported when switching a
+ customer multicast flow from one IR P-tunnel to another. These are
+ procedures that are not clearly specified in [RFC6513] or [RFC6514].
+
+
+
+Rosen, et al. Standards Track [Page 4]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ As the material in this document must be understood in order to
+ properly implement IR P-tunnels, this document updates [RFC6513] and
+ [RFC6514].
+
+ This document also discusses the application of "seamless multicast"
+ [RFC7524] and "extranet" [RFC7900] procedures to IR P-tunnels.
+
+ This document does not discuss the use of IR P-tunnels to support a
+ VPN customer's use of Bidirectional Protocol Independent Multicast
+ (BIDIR-PIM). [RFC7740] explains how to adapt the procedures of
+ [RFC6513], [RFC6514], and [RFC7582] so that a customer's use of
+ BIDIR-PIM can be supported by IR P-tunnels.
+
+ In the event of any conflict between this document and either
+ [RFC6513] or [RFC6514], this document takes precedence.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL", when and only when appearing in all capital letters, are
+ to be interpreted as described in [RFC2119].
+
+2. What is an IR P-tunnel?
+
+ An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that
+ support the MVPN procedures of [RFC6514] and related RFCs. In
+ general, the nodes of an IR P-tunnel are either Provider Edge (PE)
+ routers, Autonomous System Border Routers (ASBRs), or (if [RFC7524]
+ is supported) Area Border Routers (ABRs). (MVPN procedures are
+ sometimes used to support non-MVPN, or "global table" multicast; one
+ way of doing this is defined in [RFC7524]. Another way is defined in
+ [RFC7716]. In such cases, IR P-tunnels can be used outside the
+ context of MVPN.)
+
+ MVPN P-tunnels may be either "segmented" or "non-segmented" (as these
+ terms are defined in [RFC6513] and [RFC6514]).
+
+ A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting
+ only of a root node and a set of nodes that are children of the root
+ node. When used in an MVPN context, the root is an ingress PE, and
+ the child nodes of the root are the egress PEs.
+
+ In a segmented P-tunnel, IR may be used for some or all of the
+ segments. If a particular segment of a segmented P-tunnel uses IR,
+ then the root of that segment may have child nodes that are ABRs or
+ ASBRs, rather than egress PEs.
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 5]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ As with any type of P2MP tree, each node of an IR P-tunnel holds
+ "multicast state" for the P-tunnel. That is, each node knows the
+ identity of its parent node on the tree, and each node knows the
+ identities of its child nodes on the tree. In the MVPN specs, the
+ "parent" node is also known as the "Upstream Multicast Hop" or "UMH".
+ Note that the UMH may be a PE, an ASBR, or (if procedures from
+ [RFC7524] are being used) an ABR. (In [RFC7524], the term "upstream
+ node" is used instead of "UMH".)
+
+ What distinguishes an IR P-tunnel from any other kind of P2MP tree is
+ the method by which a data packet is transmitted from a parent node
+ to a child node. To transmit a multicast data packet from a parent
+ node to a child node along a particular IR P-tunnel, the parent node
+ does the following:
+
+ o It labels the packet with a label (call it a "P-tunnel label")
+ that the child node has assigned to that P-tunnel.
+
+ o It then places the packet in a unicast encapsulation and unicasts
+ the packet to the child node. That is, the parent node sends the
+ packet through a unicast tunnel to a particular child node. This
+ unicast tunnel need not be specially created to be part of the IR
+ P-tunnel; it can be any P2P or MP2P unicast tunnel that will get
+ the packets from the parent node to the child node. A single such
+ unicast tunnel may be carrying multicast data packets of several
+ different P2MP trees and may also be carrying unicast data
+ packets.
+
+ The parent node repeats this process for each child node, creating
+ one copy for each child node, and sending each copy through a unicast
+ tunnel to corresponding child node. It does not use Layer 2
+ multicast, IP multicast, or MPLS multicast to transmit packets to its
+ child nodes. As a result, multiple copies of each packet may be sent
+ out a single interface; this may happen, e.g., if that interface is
+ the next-hop interface, according to unicast routing, from the parent
+ node to several of the child nodes.
+
+ Since data traveling along an IR P-tunnel is always unicast from
+ parent node to child node, it can be convenient to think of an IR
+ P-tunnel as a P2MP tree whose arcs are unicast tunnels. However, it
+ is important to understand that the unicast tunnels need not be
+ specific to any particular IR P-tunnel. If R1 is the parent node of
+ R2 on two different IR P-tunnels, a single unicast tunnel from R1 to
+ R2 may be used to carry data along both IR P-tunnels. All that is
+ required is that when the data packets arrive at R2, R2 will see the
+ "P-tunnel label" at the top of the packets' label stack; R2's further
+
+
+
+
+
+Rosen, et al. Standards Track [Page 6]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ processing of the packets will depend upon that label. Note that the
+ same unicast tunnel between R1 and R2 may also be carrying unicast
+ data packets.
+
+ Typically, the unicast tunnels are the LSPs that already exist to
+ carry unicast traffic; either MP2P LSPs created by the Label
+ Distribution Protocol (LDP) [RFC5036] or P2P LSPs created by Resource
+ Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209].
+ However, any other kind of unicast tunnel may be used. A unicast
+ tunnel may have an arbitrary number of intermediate routers; those
+ routers do not maintain any multicast state for the IR P-tunnel and,
+ in general, are not even aware of its existence.
+
+ As with all other P-tunnel types, an IR P-tunnel may be used to
+ instantiate either an Inclusive PMSI (I-PMSI) or a Selective PMSI
+ (S-PMSI). See Section 3.2 of [RFC6513] for an explanation of those
+ concepts.
+
+3. How are IR P-tunnels identified?
+
+ There are four MVPN BGP route types in which P-tunnels can be
+ identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes,
+ S-PMSI A-D routes, and Leaf A-D routes. (These route types are all
+ defined in [RFC6514]).
+
+ Whenever it is necessary to identify a P-tunnel in a route of one of
+ these types, a "PMSI Tunnel Attribute" (PTA) is added to the route.
+ As defined in Section 5 of [RFC6514], the PTA contains four fields:
+ Tunnel Type, MPLS Label, Tunnel Identifier, and Flags. [RFC6514]
+ defines only one bit in the Flags field, the Leaf Information
+ Required bit.
+
+ If a route identifies an IR P-tunnel, the Tunnel Type field of its
+ PTA is set to the value 6, meaning "Ingress Replication".
+
+ Most types of P-tunnel are associated with specific protocols that
+ are used to set up and maintain tunnels of that type. For example,
+ if the Tunnel Type field is set to 2, meaning "mLDP P2MP LSP", the
+ associated setup protocol is Multipoint LDP (mLDP) [RFC6388]. The
+ associated setup protocol always has a method of identifying the
+ tunnels that it sets up. For example, mLDP uses an FEC element
+ (Forwarding Equivalence Class element) to identify a tree. If the
+ Tunnel Type field is set to 3, meaning "PIM-SSM Tree", where "SSM"
+ stands for Source-Specific Multicast, the associated setup protocol
+ is PIM, and "(S,G)" is used to identify the tree. In these cases,
+ the Tunnel Identifier field of the PTA carries a tree identifier as
+ defined by the setup protocol used for the particular tunnel type.
+
+
+
+
+Rosen, et al. Standards Track [Page 7]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ IR P-tunnels, on the other hand, are entirely setup and maintained by
+ the use of BGP A-D routes and are not associated with any other setup
+ protocol. (The unicast tunnels used to transmit multicast data along
+ an IR P-tunnel may have their own setup and maintenance protocols, of
+ course.) The means of identifying a P-tunnel is very different for
+ IR P-tunnels than for other types of P-tunnel:
+
+ When an IR P-tunnel is identified in an S-PMSI A-D route, an
+ Intra-AS I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we
+ will refer to these three route types as "advertising A-D
+ routes"), its identifier is hereby defined to be the NLRI (Network
+ Layer Reachability Information) of that route. See Sections 4.1,
+ 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs.
+ Note that the IR P-tunnel identifier includes the Route Type and
+ Length fields (see Section 4 of [RFC6514]) of the NLRI.
+
+ To reiterate:
+
+ The identifier of the IR P-tunnel does not appear in the PTA at
+ all; the Tunnel Identifier field of the PTA does not contain the
+ identifier of the IR P-tunnel.
+
+ Rather, the identifier of the IR P-tunnel appears in the Network
+ Layer Reachability Information (NLRI) field of the A-D routes that
+ are used to advertise and to setup the IR P-tunnel.
+
+ Note that an advertising A-D route is considered to identify an IR
+ P-tunnel only if it carries a PTA whose Tunnel Type field is set to
+ "IR".
+
+ When an IR P-tunnel is identified in an S-PMSI A-D route or in an
+ Inter-AS I-PMSI A-D route, the Leaf Information Required bit of the
+ Flags field of the PTA MUST be set.
+
+ In an advertising A-D route:
+
+ o If the Leaf Information Required bit of the Flags field of the PTA
+ is set, then the Tunnel Identifier field of the PTA has no
+ significance whatsoever and MUST be ignored upon reception.
+
+ Note that, per RFC 6514, the length of the Tunnel Identifier field
+ of the PTA is variable and is inferred from the length of the PTA.
+ Even when this field is of no significance, its length MUST be the
+ length of an IP address in the address space of the SP's backbone,
+ as specified in Section 4.2 of [RFC6515]. In this case, it is
+ RECOMMENDED that it be set to a routable address of the router
+ that constructed the PTA. (While it might make more sense to
+
+
+
+
+Rosen, et al. Standards Track [Page 8]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ allow or even require the field to be omitted entirely, that might
+ raise issues of backwards compatibility with implementations that
+ were designed prior to the publication of this document.)
+
+ o If the Leaf Information Required bit is not set, the Tunnel
+ Identifier field of the PTA does have significance, but it does
+ not identify the IR P-tunnel. The use of the PTA's Tunnel
+ Identifier field in this case is discussed in Section 5 of this
+ document.
+
+ Note that according to the above definition, there is no way for two
+ different advertising A-D routes (i.e., two advertising A-D routes
+ with different NLRIs) to advertise the same IR P-tunnel. In the
+ terminology of [RFC6513], an IR P-tunnel can instantiate only a
+ single PMSI. If an ingress PE, for example, wants to bind two
+ customer multicast flows to a single IR P-tunnel, it must advertise
+ that IR P-tunnel either in an I-PMSI A-D route or in an S-PMSI A-D
+ route whose NLRI contains wildcards [RFC6625].
+
+ When an IR P-tunnel is identified in a Leaf A-D route, its identifier
+ is the Route Key field of the route's NLRI. See Section 4.4 of
+ [RFC6514].
+
+ A Leaf A-D route is considered to identify an IR P-tunnel only if it
+ carries a PTA whose Tunnel Type field is set to "IR". In this type
+ of route, the Tunnel Identifier field of the PTA does have
+ significance, but it does not identify the IR P-tunnel. The use of
+ the PTA's Tunnel Identifier field in this case is discussed in
+ Section 5.
+
+4. How to Join an IR P-Tunnel
+
+ The procedures for joining an IR P-tunnel depend upon whether the
+ P-tunnel has been previously advertised, and, if so, upon how the
+ P-tunnel was advertised. Note that joining an unadvertised IR
+ P-tunnel is only possible when using the "global table multicast"
+ procedures of [RFC7524].
+
+4.1. Advertised IR P-tunnels
+
+ The procedures in this section apply when the IR P-tunnel to be
+ joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI
+ A-D route, or an Intra-AS I-PMSI A-D route.
+
+ The procedures for joining an advertised IR P-tunnel depend upon
+ whether the A-D route that advertises the IR P-tunnel has the Leaf
+ Information Required bit set in its PTA.
+
+
+
+
+Rosen, et al. Standards Track [Page 9]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+4.1.1. If the Leaf Information Required Bit Is Set
+
+ The procedures in this section apply when the P-tunnel to be joined
+ has been advertised in a route whose PTA has the Leaf Information
+ Required bit set.
+
+ The router joining a particular IR P-tunnel must determine its UMH
+ for that P-tunnel. If the route that advertised the IR P-tunnel
+ contains a P2MP Segmented Next Hop Extended Community, the UMH is
+ determined from the value of this community (see [RFC7524]).
+ Otherwise, the UMH is determined from the route's next hop (see
+ [RFC6514]).
+
+ Once the UMH is determined, the router joining the IR P-tunnel
+ originates a Leaf A-D route. The NLRI of the Leaf A-D route is
+ formed following the procedures of [RFC6514]. As a result, the NLRI
+ of the Leaf A-D route will contain the IR P-tunnel identifier defined
+ in Section 3 above as its "route key". The UMH MUST be identified by
+ attaching an "IP-address-specific Route Target" (or an "IPv6-address-
+ specific Route Target") to the Leaf A-D route. The IP address of the
+ UMH appears in the Global Administrator field of the Route Target
+ (RT). Details can be found in [RFC6514] and [RFC7524].
+
+ The Leaf A-D route MUST also contain a PTA whose fields are set as
+ follows:
+
+ o The Tunnel Type field is set to "IR".
+
+ o The Tunnel Identifier field is set as described in Section 5 of
+ this document. (Note that this field does not contain the IR
+ P-tunnel Identifier that is defined in Section 3.)
+
+ o The MPLS Label field is set to a non-zero value. This is the
+ "P-tunnel label". The value must be chosen so as to satisfy
+ various constraints, as discussed in Section 7 this document.
+
+4.1.2. If the Leaf Information Required Bit Is Not Set
+
+ The procedures in this section apply when the IR P-tunnel to be
+ joined has been advertised in a route whose PTA does not have the
+ Leaf Information Required bit set. This can only be the case if the
+ IR P-tunnel was advertised in an Intra-AS I-PMSI A-D route.
+
+ If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes
+ originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can
+ be thought of as being instantiated by a set of IR P-tunnels. Each
+ PE is the root of one such IR P-tunnel, and the other PEs are
+
+
+
+
+Rosen, et al. Standards Track [Page 10]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ children of the root. A PE simultaneously joins all these P-tunnels
+ by originating (if it hasn't already done so) an Intra-AS I-PMSI A-D
+ route with a PTA whose fields are set as follows:
+
+ o The Tunnel Type field is set to "IR".
+
+ o The Tunnel Identifier field is set as described in Section 5 of
+ this document. (Note that this field does not contain the IR
+ P-tunnel identifier that is defined in Section 3.)
+
+ o The MPLS Label field MUST be set to a non-zero value. This label
+ value will be used by the child node to associate a received
+ packet with the I-PMSI of a particular MVPN. The MPLS label
+ allocation policy must be such as to ensure that the binding from
+ label to I-PMSI is one to one.
+
+ The NLRI and the RTs of the originated I-PMSI A-D route are set as
+ specified in [RFC6514].
+
+4.2. Unadvertised IR P-Tunnels
+
+ In [RFC7524], a procedure is defined for "global table multicast", in
+ which a P-tunnel can be joined even if the P-tunnel has not been
+ previously advertised. See Sections 6.2.2 and 6.2.3 of [RFC7524]:
+ "Leaf A-D Route for Global Table Multicast" and "Constructing the
+ Rest of the Leaf A-D Route". The route key of the Leaf A-D route has
+ the form of the "S-PMSI Route-Type Specific NLRI" (see Section 4.3 of
+ [RFC6514]) in this case, and that should be considered to be the IR
+ P-tunnel identifier. Note that the procedure for finding the UMH is
+ different in this case; the UMH is the next hop of the best UMH-
+ eligible route towards the "ingress PE". See Section 6.1 of
+ [RFC7524], entitled "Determining the Upstream ABR/PE/ASBR (Upstream
+ Node)".
+
+5. The PTA's Tunnel Identifier Field
+
+ As discussed in Section 1, when the Tunnel Type field of a PTA is set
+ to "IR", the Tunnel Identifier field of that PTA does not contain the
+ IR P-tunnel identifier. This section specifies the procedures for
+ setting the Tunnel Identifier field of the PTA when the Tunnel Type
+ field of the PTA is set to "IR".
+
+
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 11]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ If the Tunnel Type field of a PTA is set to "IR", its Tunnel
+ Identifier field is significant only when one of the following two
+ conditions holds:
+
+ o The PTA is carried by a Leaf A-D route, or
+
+ o The Leaf Information Required bit of the Flags field of the PTA is
+ not set.
+
+ If one of these conditions holds, then the Tunnel Identifier field
+ must contain a routable IP address of the originator of the route.
+ (See Sections 9.2.3.2.1 and 9.2.3.4.1 of [RFC6514] for the detailed
+ specification of the contents of this field.) This address is used
+ by the UMH to determine the unicast tunnel that it will use in order
+ to send data, along the IR P-tunnel identified by the route key, to
+ the originator of the Leaf A-D route.
+
+ The means by which the unicast tunnel is determined from this IP
+ address is outside the scope of this document. The means by which
+ the unicast tunnel is set up and maintained is also outside the scope
+ of this document.
+
+ Section 4 of [RFC6515] MUST be applied when a PTA is carried in a
+ Leaf A-D route. It describes how to determine whether the Tunnel
+ Identifier field carries an IPv4 or an IPv6 address.
+
+ If neither of the above conditions hold, then the Tunnel Identifier
+ field is of no significance and MUST be ignored upon reception.
+
+6. A Note on IR P-Tunnels and Discarding Packets from the Wrong PE
+
+ Section 9.1.1 of [RFC6513] specifies a procedure known as "Discarding
+ Packets from the Wrong PE". When an egress PE receives a multicast
+ data packet, this procedure requires it to determine the packet's
+ ingress PE.
+
+ In this document, we assume that when a packet has reached an egress
+ PE via an IR P-tunnel, the egress PE will infer the identity of the
+ packet's ingress PE by examining the packet's P-tunnel label.
+
+ Section 7 specifies certain constraints on the way in which the
+ P-tunnel label is allocated for a given P-tunnel. In general, if
+ these constraints are followed, an egress PE will be able to infer
+ the identity of a packet's ingress PE from the P-tunnel label, and
+ hence will be able to apply the procedures of Section 9.1.1 of
+ [RFC6513]. This method of identifying a packet's ingress PE works
+ exactly the same when the unicast tunnels are IP tunnels as it does
+ when the unicast tunnels are MPLS LSPs.
+
+
+
+Rosen, et al. Standards Track [Page 12]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ However, if the egress PE joined a particular IR P-tunnel using the
+ procedures of Section 4.1.2, then when the egress PE receives a
+ packet through that P-tunnel, it will not be able to infer the
+ identity of the packet's ingress PE from the P-tunnel label, and thus
+ will not be able to apply the procedures of Section 9.1.1 of
+ [RFC6513].
+
+ One might think that if a particular IR P-tunnel uses IP unicast
+ tunnels rather than MPLS LSPs, an egress PE could identify the
+ ingress PE by inspecting the IP source address field of the
+ encapsulating IP header. However, there are several reasons why this
+ procedure is not desirable:
+
+ o When segmented P-tunnels are being used, the IP source address
+ field of the encapsulating IP header might not contain the address
+ of the ingress PE.
+
+ o Even if the IP source address field of the encapsulating IP header
+ does identify the ingress PE, there is no guarantee that the IP
+ source address in that header is the same as the IP address used
+ by the ingress PE for the MVPN signaling procedures.
+
+ o To apply the procedures of Section 9.1.1 of [RFC6513] when
+ extranet functionality [RFC7900] is supported, it is necessary to
+ infer a packet's ingress VRF (Virtual Routing and Forwarding
+ table), not merely its ingress PE. This can be inferred from the
+ P-tunnel label (assuming that the label is allocated following the
+ procedures of Section 7), but it cannot be inferred from the IP
+ source address of the encapsulating IP header.
+
+ We therefore assume in this document that if the procedures of
+ Section 9.1.1 of [RFC6513] are to be applied to packets traveling
+ through IR P-tunnels, those procedures will be based on the P-tunnel
+ label, even if the IR P-tunnel is using IP unicast tunnels.
+
+ This means that if an egress PE joined a particular IR P-tunnel using
+ the procedures of Section 4.1.2, duplicate prevention on that IR
+ P-tunnel requires the use of either Single Forwarder Selection
+ (Section 9.1.2 of [RFC6513]) or native PIM procedures (Section 9.1.3
+ of [RFC6513]).
+
+
+
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 13]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+7. The PTA's MPLS Label Field
+
+ When the Tunnel Type field of a PTA is set to "IR", the MPLS Label
+ field is not always significant. It is significant only under the
+ following conditions:
+
+ 1. Either the PTA is being carried in a Leaf A-D route, or
+
+ 2. the Leaf Information Required flag of the PTA is NOT set.
+
+ Note that the Leaf Information Required flag of the PTA is always set
+ when a PTA specifying an IR P-tunnel is carried in an S-PMSI A-D
+ route or in an Inter-AS I-PMSI A-D route; thus, the MPLS Label field
+ of the PTA is never significant when the PTA is carried by one of
+ these route types. The MPLS Label field is significant only when the
+ PTA appears either in a Leaf A-D route or in an Intra-AS I-PMSI A-D
+ route that does not have the Leaf Information Required bit set. In
+ these cases, the MPLS label is the label that the originator of the
+ route is assigning to the IR P-tunnel(s) identified by the route's
+ NLRI. (That is, the MPLS label assigned in the PTA is what we have
+ called the "P-tunnel label".)
+
+ In those cases where the MPLS Label field is not significant, it
+ SHOULD be set to zero upon transmission and MUST be ignored upon
+ reception.
+
+7.1. Leaf A-D Route Originated by an Egress PE
+
+ As previously stated, when a Leaf A-D route is used to join an IR
+ P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel
+ identifier.
+
+ We now define the notion of the "root of an IR P-tunnel".
+
+ o If the identifier of an IR P-tunnel is of the form of an S-PMSI
+ NLRI, the "root" of the IR P-tunnel is the router identified in
+ the Originating Router's IP Address field of that NLRI.
+
+ o If the identifier of an IR P-tunnel is of the form specified in
+ Section 6.2.2 of [RFC7524] ("Leaf A-D Route for Global Table
+ Multicast"), the "root" of the IR P-tunnel is the router
+ identified in the Ingress PE's IP Address field of that NLRI.
+
+ o If the identifier of an IR P-tunnel is of the form of an Intra-AS
+ I-PMSI NLRI, the "root" of the IR P-tunnel is the router
+ identified in the Originating Router's IP Address field of that
+ NLRI.
+
+
+
+
+Rosen, et al. Standards Track [Page 14]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ o If the identifier of an IR P-tunnel is of the form of an Inter-AS
+ I-PMSI NLRI, the "root" of the IR P-tunnel is same as the
+ identifier of the IR P-tunnel, i.e., the combination of a Route
+ Distinguisher (RD) and an AS.
+
+ Note that if an IR P-tunnel is segmented, the root of the IR
+ P-tunnel, by this definition, is actually the root of the entire
+ P-tunnel, not the root of the local segment. In this case, there may
+ be segments upstream that are not IR P-tunnels themselves. However,
+ the egress PE is aware only of the final segment of the P-tunnel, and
+ hence considers the P-tunnel to be an IR P-tunnel.
+
+ In order to apply the procedures of Section 9.1.1 of RFC 6513
+ ("Discarding Packets from Wrong PE"), the following condition MUST be
+ met by the MPLS label allocation policy:
+
+ Suppose an egress PE originates two Leaf A-D routes, each with a
+ different route key in its NLRI, and each with a PTA specifying a
+ Tunnel Type field of "IR". Thus, each of the Leaf A-D routes
+ identifies a different IR P-tunnel. Suppose further that each of
+ those IR P-tunnels has a different root. Then, the egress PE MUST
+ NOT specify the same MPLS label in both PMSI Tunnel attributes.
+
+ That is, to apply the duplicate prevention procedures (in "Discarding
+ Packets from Wrong PE", Section 9.1.1 of [RFC6513]), the same MPLS
+ label MUST NOT be assigned to two IR P-tunnels that have different
+ roots.
+
+ If segmented P-tunnels are in use, the above rule is necessary but
+ not sufficient to prevent a PE from forwarding duplicate data to the
+ CEs. For various reasons, a given egress PE or egress ABR or egress
+ ASBR may decide to change its parent node, on a given segmented
+ P-tunnel, from one router to another. It does this by changing the
+ RT of the Leaf A-D route that it originated in order to join that
+ P-tunnel. Once the RT is changed, there may be a period of time
+ during which the old parent node and the new parent node are both
+ sending data of the same multicast flow. To ensure that the egress
+ node not forward duplicate data, whenever the egress node changes the
+ RT that it attaches to a Leaf A-D route, it MUST also change the
+ "MPLS Label" specified in the Leaf A-D route's PTA. This allows the
+ egress router to distinguish between packets arriving on a given
+ P-tunnel from the old parent and packets arriving on that same
+ P-tunnel from the new parent. At any given time, a router MUST
+ consider itself to have only a single parent node on a given P-tunnel
+ and MUST discard traffic that arrives on that P-tunnel from a
+ different parent node.
+
+
+
+
+
+Rosen, et al. Standards Track [Page 15]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ If extranet functionality [RFC7900] is not implemented in a
+ particular egress PE, or if an egress PE is provisioned with the
+ knowledge that extranet functionality is not needed, the PE may adopt
+ the policy of assigning a label that is unique for the ordered triple
+ <root, parent node, egress VRF>. This will enable the egress PE to
+ apply the duplicate prevention procedures discussed above and to
+ determine the VRF to which an arriving packet must be directed.
+
+ However, this policy is not sufficient to support the "Do Not Deliver
+ Packets from the Wrong P-tunnel" procedures that are specified in
+ Section 2.3.1 of [RFC7900]. To support those procedures, the labels
+ specified in the PTA of Leaf A-D routes originated by a given egress
+ PE MUST be unique for the ordered triple <root, root RD, parent
+ node>, where the "root RD" is taken from the RD field of the IR
+ P-tunnel identifier. (All forms of IR P-tunnel identifier contain an
+ embedded RD field.) This policy is also sufficient for supporting
+ non-extranet cases, but, in some cases, may result in the use of more
+ labels than the policy of the preceding paragraph.
+
+7.2. Leaf A-D Route Originated by an Intermediate Node
+
+ When a P-tunnel is segmented, there will be "intermediate nodes",
+ i.e., nodes that have a parent and also have children on the
+ P-tunnel. Each intermediate node is a leaf node of an "upstream
+ segment" and a root node of one or more "downstream segments". The
+ intermediate node needs to set up its forwarding state so that data
+ it receives on the upstream segment gets transmitted on the proper
+ downstream segments.
+
+ If the upstream segment is instantiated by IR, the intermediate node
+ will need to originate a Leaf A-D route to join that segment, and
+ will need to allocate a downstream-assigned MPLS label to advertise
+ in the MPLS Label field of the Leaf A-D route's PTA. Section 7.1
+ specifies constraints on the label allocation policy for egress PEs;
+ this section specifies constraints on the label allocation policy for
+ intermediate nodes.
+
+ Suppose intermediate node N originates two Leaf A-D routes, one whose
+ route key is K1, and one whose route key is K2, where K1 != K2. The
+ respective PTAs of these Leaf A-D routes MUST specify distinct non-
+ zero MPLS labels, UNLESS the following conditions all hold:
+
+ 1. N's parent node for P-tunnel K1 is the same as N's parent node
+ for P-tunnel K2.
+
+ 2. N's forwarding state is such that any packet it receives from
+ P-tunnel K1 is forwarded to the exact same set of downstream
+ neighbors as any packet it receives from P-tunnel K2.
+
+
+
+Rosen, et al. Standards Track [Page 16]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ 3. For each downstream neighbor D to which N sends the packets it
+ receives from P-tunnels K1 and K2, N's forwarding state is such
+ that it applies the exact same encapsulation to packets it
+ forwards from either tunnel to D. (For example, if N uses MPLS
+ to forward the packets to D, it pushes the exact same set of
+ labels on packets from P-tunnel K1 as it pushes on packets from
+ P-tunnel K2.)
+
+ Of course, N MAY always specify distinct non-zero labels in each of
+ the Leaf A-D routes that it originates.
+
+ Note that the rules of this section apply whenever the upstream
+ P-tunnel segment is an IR P-tunnel. These rules hold whether or not
+ some or all of the downstream segments are other types of P-tunnels.
+
+ If the P-tunnels from N to a particular downstream neighbor D are IR
+ P-tunnels, then condition 3 above will hold with respect to D only if
+ the following conditions all hold as well:
+
+ o N has received and installed a Leaf A-D route from D, whose route
+ key is K1, and which carries an IP-address-specific RT identifying
+ N,
+
+ o N has received and installed a Leaf A-D route from D, whose route
+ key is K2, and which carries an IP-address-specific RT identifying
+ N,
+
+ o Those two Leaf A-D routes specify the same MPLS label in their
+ respective PTAs.
+
+7.3. Intra-AS I-PMSI A-D Route
+
+ When a router joins a set of IR P-tunnels using the procedures of
+ Section 4.1.2 of this document, the procedures of Section 9.1.1 of
+ [RFC6513] cannot be applied, no matter what the label allocation
+ policy is. In this case, the ingress PE is the same as the UMH, but
+ it is not possible to assign a label uniquely to a particular ingress
+ PE or UMH. However, the label in the MPLS Label field of the PTA
+ MUST NOT appear in the MPLS Label field of the PTA carried by any
+ other route originated by the same router.
+
+8. How a Child Node Prunes Itself from an IR P-Tunnel
+
+ If a particular IR P-tunnel was joined via the procedures of
+ Section 4.1.2, a router can prune itself from the P-tunnel by
+ withdrawing the Intra-AS I-PMSI A-D route it used to join the
+ P-tunnel. This is not usually done unless the router is removing
+ itself entirely from a particular MVPN.
+
+
+
+Rosen, et al. Standards Track [Page 17]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ The procedures in the remainder of this section apply when a router
+ joined a particular IR P-tunnel by originating a Leaf A-D route (as
+ described in Sections 4.1.1 or 4.2).
+
+ If a router no longer has a need to receive any multicast data from a
+ given IR P-tunnel, it may prune itself from the P-tunnel by
+ withdrawing the Leaf A-D route it used to join the tunnel. This is
+ done, e.g., if the router no longer needs any of the flows traveling
+ over the P-tunnel, or if all the flows the router does need are being
+ received over other P-tunnels.
+
+ A router that is attached to a particular IR P-tunnel via a
+ particular parent node may determine that it needs to stay joined to
+ that IR P-tunnel but via a different parent node. This can happen,
+ for example, if there is a change in the Next Hop or the P2MP
+ Segmented Next-Hop Extended Community of the S-PMSI A-D route in
+ which that P-tunnel was advertised. In this case, the router changes
+ the Route Target of the Leaf A-D route it used to join the IR
+ P-tunnel, so that the Route Target now identifies the new parent
+ node.
+
+ A parent node must notice when a child node has been pruned from a
+ particular tree, as this will affect the parent node's multicast data
+ state. Note that the pruning of a child node may appear to the
+ parent node as the explicit withdrawal of a Leaf A-D route, or it may
+ appear as a change in the Route Target of a Leaf A-D route. If the
+ Route Target of a particular Leaf A-D route previously identified a
+ particular parent node, but changes so that it no longer does so, the
+ effect on the multicast state of the parent node is the same as if
+ the Leaf A-D route had been explicitly withdrawn.
+
+9. Parent Node Actions upon Receiving Leaf A-D Route
+
+ These actions are detailed in [RFC6514] and [RFC7524]. Two points of
+ clarification are made:
+
+ o If a router R1 receives and installs a Leaf A-D route originated
+ by router R2, R1's multicast state is affected only if the Leaf
+ A-D route carries an "IP-address-specific RT" (or "IPv6-address-
+ specific RT") whose Global Administrator field identifies R1.
+
+ (This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D
+ route's RT does not identify R1, but then changes so that it does
+ identify R1, R1 must take the same actions it would take if the
+ Leaf A-D route were newly received.
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 18]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ o It is possible that router R1 will receive and install a Leaf A-D
+ route originated by router R2, where:
+
+ * the route's RT identifies R1,
+
+ * the route's NLRI contains a route key whose first octet
+ indicates that it is identifying a P-tunnel advertised in an
+ S-PMSI A-D route,
+
+ * R1 has neither originated nor installed any such S-PMSI A-D
+ route.
+
+ If at some later time, R1 installs the corresponding S-PMSI A-D
+ route, and the Leaf A-D route is still installed, and the Leaf A-D
+ route's RT still identifies R1, then R1 MUST follow the same
+ procedures it would have followed if the S-PMSI A-D route had been
+ installed before the Leaf A-D route was installed. Implementers must
+ not assume that events occur in the "usual" or "expected" order.
+
+10. Use of Timers When Switching UMH
+
+ Consider a child node that has joined a particular IR P-tunnel via a
+ particular UMH. To do so, it will have originated a Leaf A-D route
+ with an RT that identifies the UMH. Suppose the child node now
+ determines (for whatever reason) that it needs to change its UMH for
+ that P-tunnel. It does this by:
+
+ o modifying the RT of the Leaf A-D route, so that the RT now
+ identifies the new parent rather than the old one, and by
+
+ o modifying the PTA of the Leaf A-D route, changing the MPLS Label
+ field as discussed in Section 7.
+
+ Note that, in accordance with the procedures of [RFC6514] and of
+ Section 4 of this document, the NLRI of the Leaf A-D route is not
+ modified; only the RT and the PTA are changed.
+
+ It is desirable for such a "switch of UMH" to be done using a "make
+ before break" technique, so that the old UMH does not stop
+ transmitting packets of the given P-tunnel to the child until the new
+ UMH has a chance to start transmitting packets of the given P-tunnel
+ to the child. However, the control-plane operation (i.e., modifying
+ the RT and PTA of the Leaf A-D route) does not permit the child node
+ to first join the IR P-tunnel via the new UMH, and then later prune
+ itself from the old UMH. Rather, a single control-plane operation
+ has both effects.
+
+
+
+
+
+Rosen, et al. Standards Track [Page 19]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ Therefore, the old UMH MUST continue transmitting to the child node
+ for a period of time after it sees the child's Leaf A-D route being
+ withdrawn (or its RT changing to identify a different UMH). This
+ timer (the "parent-continues" timer) SHOULD have a default value of
+ 60 seconds and SHOULD be configurable.
+
+ By the procedures of Section 7, the child node will have advertised a
+ different label for the IR P-tunnel to the new UMH than it had
+ advertised to the old UMH. This allows it to distinguish the packets
+ of that IR P-tunnel transmitted by the new UMH from packets of that
+ IR P-tunnel transmitted by the old UMH. At any given time, the child
+ node will accept packets of that IR P-tunnel from only one parent
+ node and will discard packets of that IR P-tunnel that are received
+ from the other. To achieve "make before break" functionality, the
+ child node needs to continue to accept packets from the old UMH for a
+ period of time. After this period, it will discard any packets from
+ the given IR P-tunnel that it receives from the old UMH and will only
+ accept such packets from the new UMH.
+
+ Once the child node modifies the RT of its Leaf A-D route, it MUST
+ run a timer (the "switch-parents-delay" timer). This timer SHOULD
+ default to 30 seconds and SHOULD be configurable. The child node
+ MUST continue to accept packets of the given IR P-tunnel from the old
+ UMH until the timer expires. However, once the child node receives a
+ packet of the given IR P-tunnel from the new UMH, it MAY consider the
+ "switch-parents-delay" timer to have expired.
+
+ The "parent-continues" timer MUST be longer than the "switch-parents-
+ delay" timer. Note that both timers are specific to a given IR
+ P-tunnel.
+
+11. Security Considerations
+
+ No security considerations are raised by this document beyond those
+ already discussed in [RFC6513] and [RFC6514].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 20]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+12. References
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
+ MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
+ February 2012, <http://www.rfc-editor.org/info/rfc6513>.
+
+ [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
+ Encodings and Procedures for Multicast in MPLS/BGP IP
+ VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
+ <http://www.rfc-editor.org/info/rfc6514>.
+
+ [RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure
+ Addresses in BGP Updates for Multicast VPN", RFC 6515,
+ DOI 10.17487/RFC6515, February 2012,
+ <http://www.rfc-editor.org/info/rfc6515>.
+
+12.2. Informative References
+
+ [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+ and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+ Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+ <http://www.rfc-editor.org/info/rfc3209>.
+
+ [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+ "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
+ October 2007, <http://www.rfc-editor.org/info/rfc5036>.
+
+ [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
+ Thomas, "Label Distribution Protocol Extensions for Point-
+ to-Multipoint and Multipoint-to-Multipoint Label Switched
+ Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
+ <http://www.rfc-editor.org/info/rfc6388>.
+
+ [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
+ Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
+ RFC 6625, DOI 10.17487/RFC6625, May 2012,
+ <http://www.rfc-editor.org/info/rfc6625>.
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 21]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+ [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
+ Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
+ Point-to-Multipoint (P2MP) Segmented Label Switched Paths
+ (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
+ <http://www.rfc-editor.org/info/rfc7524>.
+
+ [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
+ "Multicast Virtual Private Network (MVPN): Using
+ Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
+ July 2015, <http://www.rfc-editor.org/info/rfc7582>.
+
+ [RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
+ and D. Pacella, "Global Table Multicast with BGP Multicast
+ VPN (BGP-MVPN) Procedures", RFC 7716,
+ DOI 10.17487/RFC7716, December 2015,
+ <http://www.rfc-editor.org/info/rfc7716>.
+
+ [RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating
+ Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider
+ Tunnels with Ingress Replication", RFC 7740,
+ DOI 10.17487/RFC7740, January 2016,
+ <http://www.rfc-editor.org/info/rfc7740>.
+
+ [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
+ and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
+ RFC 7900, DOI 10.17487/RFC7900, June 2016,
+ <http://www.rfc-editor.org/info/rfc7900>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 22]
+
+RFC 7988 IR Tunnels in MVPN October 2016
+
+
+Acknowledgments
+
+ The authors wish to thank Yakov Rekhter for his contributions to this
+ work. We also wish to thank Huajin Jeng and Samir Saad for their
+ contributions, and to thank Thomas Morin for pointing out (both
+ before and after the document was written) some of the issues that
+ needed further elaboration. We also thank Lucy Yong for her review
+ and comments.
+
+ Section 7.1 discusses the importance of having an MPLS label
+ allocation policy that, when ingress replication is used, allows an
+ egress PE to infer the identity of a received packet's ingress PE.
+ This issue was first raised in earlier work by Xu Xiaohu.
+
+Authors' Addresses
+
+ Eric C. Rosen (editor)
+ Juniper Networks, Inc.
+ 10 Technology Park Drive
+ Westford, Massachusetts 01886
+ United States of America
+
+ Email: erosen@juniper.net
+
+
+ Karthik Subramanian
+ Sproute Networks
+
+ Email: karthik@sproute.com
+
+
+ Zhaohui Zhang
+ Juniper Networks, Inc.
+ 10 Technology Park Drive
+ Westford, Massachusetts 01886
+ United States of America
+
+ Email: zzhang@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosen, et al. Standards Track [Page 23]
+