doc: Add RFC documents

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]
+