6.  Egress PE/ASBR Signaling Procedures

   This section describes the egress PE/ASBR procedures for constructing
   segmented inter-area P2MP LSPs.  The procedures in this section apply
   irrespective of whether the egress PE/ASBR is in a leaf IGP area, the
   backbone area, or even in the same IGP area as the ingress PE/ASBR.

   An egress PE/ASBR applies procedures specified in this section to
   MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the
   Inter-Area P2MP Segmented Next-Hop Extended Community.  An egress PE
   applies procedures specified in this section to VPLS A-D routes or
   VPLS S-PMSI A-D routes only if these routes carry the Inter-Area P2MP
   Segmented Next-Hop Extended Community.

   In order to support global table multicast, an egress PE MUST be
   auto-configured to import routes that carry an AS-specific Route
   Target Extended Community ([RFC4360]) with the Global Administrator
   field set to the AS of the PE and the Local Administrator field set
   to 0.

   Once an egress PE/ASBR discovers the P2MP FEC of an inter-area
   segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in
   order to construct the segmented inter-area P2MP service LSP.  This
   propagation uses BGP Leaf A-D routes.

6.1.  Determining the Upstream ABR/PE/ASBR (Upstream Node)

   An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP
   segmented service LSP as described in Section 5.  Once the egress
   PE/ASBR discovers this P2MP FEC, it MUST determine the upstream node
   to reach such a FEC.  If the egress PE/ASBR and the ingress PE/ASBR
   are not in the same area, and the egress PE/ASBR is not in the
   backbone IGP area, then this upstream node would be an egress ABR.
   If the egress PE/ASBR is in the backbone area and the ingress PE/ASBR
   is not in the backbone area, then this upstream node would be an
   ingress ABR.  If the egress PE/ASBR is in the same area as the
   ingress PE/ASBR, then this upstream node would be the ingress
   PE/ASBR.

6.1.1.  Upstream Node for MVPN or VPLS

   If the application is MVPN or VPLS, then the upstream node's IP
   address is the IP address determined from the Global Administrator
   field of the Inter-Area P2MP Segmented Next-Hop Extended Community.
   As described in Section 5, this Extended Community MUST be carried in
   the MVPN or VPLS A-D route from which the P2MP FEC of the inter-area
   P2MP segmented service LSP is determined.

6.1.2.  Upstream Node for Global Table Multicast

   If the application is global table multicast, then the unicast routes
   to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended
   Community [RFC6514] where the IP address in the Global Administrator
   field is set to the IP address of the PE or ASBR advertising the
   unicast route.  The Local Administrator field of this Extended
   Community MUST be set to 0 (note that this is in contrast to the case
   of MVPN, where the Local Administrator field carries a non-zero value
   that identifies a particular VRF on a PE that originates VPN-IP
   routes).  If it is not desirable to advertise the VRF Route Import
   Extended Community in unicast routes, then unicast routes to
   multicast sources/RPs MUST be advertised using the multicast
   Subsequent Address Family Identifier (SAFI), i.e., SAFI 2, and such
   routes MUST carry the VRF Route Import Extended Community.

   Further, if the application is global table multicast, then the BGP
   unicast routes that advertise the routes to the IP addresses of
   PEs/ASBRs/ABRs SHOULD carry the Inter-Area P2MP Segmented Next-Hop
   Extended Community.  The IP address in the Global Administrator field
   of this Extended Community MUST be set to the IP address of the PE,
   ASBR, or ABR advertising the unicast route.  The Local Administrator
   field of this Extended Community MUST be set to 0.  If it is not
   desirable to advertise the Inter-Area P2MP Segmented Next-Hop
   Extended Community in BGP unicast routes, then the BGP unicast routes
   to the IP addresses of PEs/ASBRs/ABRs MUST be advertised using the
   multicast SAFI, i.e., SAFI 2, and such routes MUST carry the Inter-
   Area P2MP Segmented Next-Hop Extended Community.  The procedures for
   handling the BGP Next Hop attribute of SAFI 2 routes are the same as
   those of handling regular unicast routes and MAY follow
   [SEAMLESS-MPLS].

   If the application is global table multicast, then in order to
   determine the upstream node address, the egress PE first determines
   the ingress PE.  In order to determine the ingress PE, the egress PE
   determines the best route to reach the S/RP.  The ingress PE address
   is the IP address determined from the Global Administrator field of
   the VRF Route Import Extended Community that is carried in this
   route.  Then, the egress PE finds the best unicast route to reach the
   ingress PE.  The upstream node address is the IP address determined
   from the Global Administrator field of the Inter-Area P2MP Segmented
   Next-Hop Extended Community that is carried in this route.

6.2.  Originating a Leaf A-D Route

   If the P2MP FEC was derived from an MVPN or VPLS A-D route, and if
   the route carries a PMSI Tunnel attribute with the "Leaf Information
   Required" flag set, then the egress PE MUST originate a Leaf A-D
   route.

   If the P2MP FEC was derived from a global table multicast (S/*,G),
   and the upstream node's address is not the same as the egress PE,
   then the egress PE MUST originate a Leaf A-D route.

6.2.1.  Leaf A-D Route for MVPN and VPLS

   If the P2MP FEC was derived from MVPN or VPLS A-D routes, then the
   Route Key field of the Leaf A-D route contains the NLRI of the A-D
   route from which the P2MP FEC was derived.  This follows procedures
   for constructing Leaf A-D routes described in [RFC6514] [RFC7117].

6.2.2.  Leaf A-D Route for Global Table Multicast

   If the application is global table multicast, then the MCAST-VPN NLRI
   of the Leaf A-D route is constructed as follows.

   The Route Key field of the MCAST-VPN NLRI has the following format:

                   +-----------------------------------+
                   |      RD   (8 octets)              |
                   +-----------------------------------+
                   | Multicast Source Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Source (Variable)      |
                   +-----------------------------------+
                   |  Multicast Group Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Group   (Variable)     |
                   +-----------------------------------+
                   |  Ingress PE's IP Address          |
                   +-----------------------------------+

   RD is set to 0 for (S,G) state and all ones for (*,G) state,
   Multicast Source is set to S for (S,G) state or RP for (*,G) state,
   Multicast Group is set to G, and Multicast Source Length and
   Multicast Group Length are set to either 4 or 16 (depending on
   whether S/RP and G are IPv4 or IPv6 addresses).

   The Ingress PE's IP address is determined as described in
   Section 6.1.

   The Originating Router's IP Address field of the MCAST-VPN NLRI is
   set to the address of the local PE (the PE that originates the
   route).

   Thus, the entire MCAST-VPN NLRI of the route has the following
   format:

                   +-----------------------------------+
                   |      Route Type = 4 (1 octet)     |
                   +-----------------------------------+
                   |         Length (1 octet)          |
                   +-----------------------------------+
                   |          RD   (8 octets)          |
                   +-----------------------------------+
                   | Multicast Source Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Source (Variable)      |
                   +-----------------------------------+
                   |  Multicast Group Length (1 octet) |
                   +-----------------------------------+
                   |  Multicast Group   (Variable)     |
                   +-----------------------------------+
                   |  Ingress PE's IP Address          |
                   +-----------------------------------+
                   |  Originating Router's IP Address  |
                   +-----------------------------------+

   Note that the encoding of the MCAST-VPN NLRI for the Leaf A-D routes
   used for global table multicast is different from the encoding used
   by the Leaf A-D routes originated in response to S-PMSI or I-PMSI A-D
   routes.  A router that receives a Leaf A-D route can distinguish
   between these two cases by examining the third octet of the MCAST-VPN
   NLRI of the route.  If the value of this octet is 0x01, 0x02, or
   0x03, then this Leaf A-D route was originated in response to an
   S-PMSI or I-PMSI A-D route.  If the value of this octet is either
   0x00 or 0xff, and octets 3 through 10 contain either all 0x00 or all
   0xff, then this is a Leaf A-D route used for global table multicast.

   When the PE deletes (S,G)/(*,G) state that was created as a result of
   receiving PIM or IGMP messages on one of its IP multicast interfaces,
   if the PE previously originated a Leaf A-D route for that state, the
   PE SHOULD withdraw that route.

   An AS with an IPv4 network may provide global table multicast service
   for customers that use IPv6, and an AS with an IPv6 network may
   provide global table multicast service for customers that use IPv4.
   Therefore, the address family of the Ingress PE's IP Address field
   and the Originating Router's IP Address field in the Leaf A-D routes

   used for global table multicast MUST NOT be inferred from the AFI
   field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute of
   these routes.  The address family is determined from the length of
   the address (a length of 4 octets for IPv4 addresses or a length of
   16 octets for IPv6 addresses).

   For example, if an AS with an IPv4 network is providing IPv6
   multicast service to a customer, the Ingress PE's IP Address and
   Originating Router's IP Address in the Leaf A-D routes used for IPv6
   global table multicast will be a 4-octet IPv4 address, even though
   the AFI of those routes will have the value 2.

   Note that the Ingress PE's IP Address and the Originating Router's IP
   Address must be either both IPv4 or both IPv6 addresses; thus, they
   must be of the same length.  Since the two variable-length fields
   (Multicast Source and Multicast Group) in the Leaf A-D routes used
   for global table multicast have their own Length field, from these
   two Length fields, and the Length field of the MCAST-VPN NLRI, one
   can compute the length of the Ingress PE's IP Address field and the
   Originating Router's IP Address field.  If the computed length of
   these fields is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be
   considered to be "incorrect", and MUST be handled as specified in
   Section 7 of [RFC4760].

6.2.3.  Constructing the Rest of the Leaf A-D Route

   The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
   be set to the same IP address as the one carried in the Originating
   Router's IP Address field of the route.

   When ingress replication is used to instantiate the egress area
   segment, the Leaf A-D route MUST carry a downstream-assigned label in
   the PMSI Tunnel attribute where the PMSI Tunnel Type is set to
   ingress replication.  A PE MUST assign a distinct MPLS label for each
   Leaf A-D route originated by the PE.

   To constrain distribution of this route, the originating PE
   constructs an IP-based Route Target Extended Community by placing the
   IP address of the upstream node in the Global Administrator field of
   the Extended Community, with the Local Administrator field of this
   community set to 0.  The originating PE then adds this Route Target
   Extended Community to this Leaf A-D route.  The upstream node's
   address is determined as specified in Section 6.1.

   The PE then advertises this route to the upstream node.

6.3.  PIM-SM in ASM Mode for Global Table Multicast

   This specification allows two options for supporting global table
   multicast that are initiated using PIM-SM in ASM mode.  The first
   option does not carry IP multicast shared trees over the MPLS
   network.  The second option does carry shared trees over the MPLS
   network and provides support for switching from shared trees to
   source trees.

6.3.1.  Option 1

   This option does not carry IP multicast shared trees over the MPLS
   network.  Therefore, when an (egress) PE creates (*,G) state (as a
   result of receiving PIM or IGMP messages on one of its IP multicast
   interfaces), the PE does not propagate this state using Leaf A-D
   routes.

6.3.1.1.  Originating Source Active A-D Routes

   Whenever an RP that is co-located with a PE discovers a new multicast
   source (as a result of receiving PIM Register or MSDP messages), the
   RP/PE SHOULD originate a BGP Source Active A-D route.  Similarly,
   whenever, as a result of receiving MSDP messages, a PE that is not
   configured as an RP discovers a new multicast source, the PE SHOULD
   originate a BGP Source Active A-D route.  The BGP Source Active A-D
   route carries a single MCAST-VPN NLRI constructed as follows:

   + The RD in this NLRI is set to 0.

   + The Multicast Source field MUST be set to S.  The Multicast Source
     Length field is set appropriately to reflect this.

   + The Multicast Group field MUST be set to G.  The Multicast Group
     Length field is set appropriately to reflect this.

   The Route Target of this Source Active A-D route is an AS-specific
   Route Target Extended Community with the Global Administrator field
   set to the AS of the advertising RP/PE and the Local Administrator
   field set to 0.

   To constrain distribution of the Source Active A-D route to the AS of
   the advertising RP, this route SHOULD carry the NO_EXPORT Community
   ([RFC1997]).

   Using the normal BGP procedures, the Source Active A-D route is
   propagated to all other PEs within the AS.

   Whenever the RP/PE discovers that the source is no longer active, the
   RP MUST withdraw the Source Active A-D route, if such a route was
   previously advertised by the RP.

6.3.1.2.  Receiving BGP Source Active A-D Route by PE

   As a result of receiving PIM or IGMP messages on one of its IP
   multicast interfaces, when an egress PE creates in its Tree
   Information Base (TIB) a new (*,G) entry with a non-empty outgoing
   interface list that contains one or more IP multicast interfaces, the
   PE MUST check if it has any Source Active A-D routes for that G.  If
   there is such a route, S of that route is reachable via an MPLS
   interface, and the PE does not have (S,G) state in its TIB for (S,G)
   carried in the route, then the PE originates a Leaf A-D route
   carrying that (S,G), as specified in Section 6.2.2.

   When an egress PE receives a new Source Active A-D route, the PE MUST
   check if its TIB contains an (*,G) entry with the same G as carried
   in the Source Active A-D route.  If such an entry is found, S is
   reachable via an MPLS interface, and the PE does not have (S,G) state
   in its TIB for (S,G) carried in the route, then the PE originates a
   Leaf A-D route carrying that (S,G), as specified in Section 6.2.2.

6.3.1.3.  Handling (S,G,rpt) State

   Creation and deletion of (S,G,rpt) state on a PE that resulted from
   receiving PIM messages on one of its IP multicast interfaces do not
   result in any BGP actions by the PE.

6.3.2.  Option 2

   This option does carry IP multicast shared trees over the MPLS
   network.  Therefore, when an egress PE creates (*,G) state (as a
   result of receiving PIM or IGMP messages on one of its IP multicast
   interfaces), the PE does propagate this state using Leaf A-D routes.

6.3.2.1.  Originating Source Active A-D Routes

   Whenever a PE creates an (S,G) state as a result of receiving Leaf
   A-D routes associated with the global table multicast service, if S
   is reachable via one of the IP multicast-capable interfaces, and the
   PE determines that G is in the PIM-SM in ASM mode range, the PE MUST
   originate a BGP Source Active A-D route.  The route carries a single
   MCAST-VPN NLRI constructed as follows:

   + The RD in this NLRI is set to 0.

   + The Multicast Source field MUST be set to S.  The Multicast Source
     Length field is set appropriately to reflect this.

   + The Multicast Group field MUST be set to G.  The Multicast Group
     Length field is set appropriately to reflect this.

   The Route Target of this Source Active A-D route is an AS-specific
   Route Target Extended Community with the Global Administrator field
   set to the AS of the advertising PE and the Local Administrator field
   set to 0.

   To constrain distribution of the Source Active A-D route to the AS of
   the advertising PE, this route SHOULD carry the NO_EXPORT Community
   [RFC1997].

   Using the normal BGP procedures, the Source Active A-D route is
   propagated to all other PEs within the AS.

   Whenever the PE deletes the (S,G) state that was previously created
   as a result of receiving a Leaf A-D route for (S,G), the PE that
   deletes the state MUST also withdraw the Source Active A-D route, if
   such a route was advertised when the state was created.

6.3.2.2.  Receiving BGP Source Active A-D Route

   Procedures for receiving BGP Source Active A-D routes are the same as
   with Option 1.

6.3.2.3.  Pruning Sources Off the Shared Tree

   After receiving a new Source Active A-D route for (S,G), if a PE
   determines that (a) it has the (*,G) entry in its TIB, (b) the
   incoming interface (iif) list for that entry contains one of the IP
   interfaces, (c) an MPLS LSP is in the outgoing interface (oif) list
   for that entry, and (d) the PE does not originate a Leaf A-D route
   for (S,G), then the PE MUST transition the (S,G,rpt) downstream state
   to the Prune state.  [Conceptually the PIM state machine on the PE
   will act "as if" it had received Prune(S,G,Rpt) from some other PE,
   without actually having received one.]  Depending on the (S,G,rpt)
   state on the iifs, this may result in the PE using PIM procedures to
   prune S off the Shared (*,G) tree.

   Transitioning the state machine to the Prune state SHOULD be done
   after a delay that is controlled by a timer.  The value of the timer
   MUST be configurable.  The purpose of this timer is to ensure that S
   is not pruned off the shared tree until all PEs have had time to
   receive the Source Active A-D route for (S,G).

   The PE MUST keep the (S,G,rpt) downstream state machine in the Prune
   state for as long as (a) the outgoing interface list (oif) for (*,G)
   contains an MPLS LSP, (b) the PE has at least one Source Active A-D
   route for (S,G), and (c) the PE does not originate the Leaf A-D route
   for (S,G).  Once any of these conditions become no longer valid, the
   PE MUST transition the (S,G,rpt) downstream state machine to the
   NoInfo state.

   Note that, except for the scenario described in the first paragraph
   of this section, in all scenarios relying solely on PIM procedures on
   the PE is sufficient to ensure the correct behavior when pruning
   sources off the shared tree.

6.3.2.4.  More on Handling (S,G,rpt) State

   Creation and deletion of (S,G,rpt) state on a PE that resulted from
   receiving PIM messages on one of its IP multicast interfaces do not
   result in any BGP actions by the PE.

7.  Egress ABR Procedures

   This section describes the egress ABR procedures for constructing
   segmented inter-area P2MP LSPs.

7.1.  Handling Leaf A-D Route on Egress ABR

   When an egress ABR receives a Leaf A-D route and the Route Target
   Extended Community carried by the route contains the IP address of
   this ABR, the following procedures will be executed.

   If the value of the third octet of the MCAST-VPN NLRI of the received
   Leaf A-D route is either 0x01, 0x02, or 0x03, this indicates that the
   Leaf A-D route was originated in response to an S-PMSI or I-PMSI A-D
   route (see Section 6.2.2).  In this case, the egress ABR MUST find an
   S-PMSI or I-PMSI route whose NLRI has the same value as the Route Key
   field of the received Leaf A-D route.  If such a matching route is
   found, then the Leaf A-D route MUST be accepted.  If the Leaf A-D
   route is accepted and if it is the first Leaf A-D route update for
   the Route Key field in the route, or the withdrawal of the last Leaf
   A-D route for the Route Key field, then the following procedures will
   be executed.

   If the RD of the received Leaf A-D route is set to all zeros or all
   ones, then the received Leaf A-D route is for the global table
   multicast service.

   If the received Leaf A-D route is the first Leaf A-D route update for
   the Route Key field carried in the route, then the egress ABR
   originates a Leaf A-D route, whose MCAST-VPN NLRI is constructed as
   follows.

   The Route Key field of the MCAST-VPN NLRI is the same as the Route
   Key field of the MCAST-VPN NLRI of the received Leaf A-D route.  The
   Originating Router's IP Address field of the MCAST-VPN NLRI is set to
   the address of the local ABR (the ABR that originates the route).

   The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD
   be set to the same IP address as the one carried in the Originating
   Router's IP Address field of the route.

   To constrain distribution of this route, the originating egress ABR
   constructs an IP-based Route Target Extended Community by placing the
   IP address of the upstream node in the Global Administrator field of
   the Extended Community, with the Local Administrator field of this
   Extended Community set to 0, and sets the Extended Communities
   attribute of this Leaf A-D route to that Extended Community.

   The upstream node's IP address is the IP address determined from the
   Global Administrator field of the Inter-Area P2MP Segmented Next-Hop
   Extended Community, where this Extended Community is obtained as
   follows.  When the Leaf A-D route is for MVPN or VPLS, this Extended
   Community is the one carried in the I-PMSI/S-PMSI A-D route that
   matches the Leaf A-D route.  When the Leaf A-D route is for global
   table multicast, this Extended Community is the one carried in the
   best unicast route to the Ingress PE.  The Ingress PE address is
   determined from the received Leaf A-D route.  The best unicast route
   MUST first be determined from multicast SAFI, i.e., SAFI 2 routes, if
   present.

   The ABR then advertises this Leaf A-D route to the upstream node in
   the backbone area.

   Mechanisms specified in [RFC4684] for constrained BGP route
   distribution can be used along with this specification to ensure that
   only the needed PE/ABR will have to process a said Leaf A-D route.

   When ingress replication is used to instantiate the backbone area
   segment, the Leaf A-D route originated by the egress ABR MUST carry a
   downstream-assigned label in the PMSI Tunnel attribute where the
   Tunnel Type is set to ingress replication.  The ABR MUST assign a
   distinct MPLS label for each Leaf A-D route that it originates.

   In order to support global table multicast, an egress ABR MUST auto-
   configure an import AS-based Route Target Extended Community with the
   Global Administrator field set to the AS of the ABR and the Local
   Administrator field set to 0.

   If the received Leaf A-D route is the withdrawal of the last Leaf A-D
   route for the Route Key carried in the route, then the egress ABR
   must withdraw the Leaf A-D route associated with that Route Key that
   has been previously advertised by the egress ABR in the backbone
   area.

7.2.  P2MP LSP as the Intra-Area LSP in the Egress Area

   This section describes procedures for using intra-area P2MP LSPs in
   the egress area.  The procedures that are common to both P2MP RSVP-TE
   and P2MP LDP are described first, followed by procedures that are
   specific to the signaling protocol.

   When P2MP LSPs are used as the intra-area LSPs, note that an existing
   intra-area P2MP LSP may be used solely for a particular inter-area
   P2MP service LSP or for other inter-area P2MP service LSPs as well.

   The choice between the two options is purely local to the egress ABR.
   The first option provides one-to-one mapping between inter-area P2MP
   service LSPs and intra-area P2MP LSPs; the second option provides
   many-to-one mapping, thus allowing the aggregation of forwarding
   state.

7.2.1.  Received Leaf A-D Route Is for MVPN or VPLS

   If the value of the third octet of the MCAST-VPN NLRI of the received
   Leaf A-D route is either 0x01, 0x02, or 0x03, this indicates that the
   Leaf A-D route was originated in response to an MVPN or VPLS S-PMSI
   or I-PMSI A-D route (see Section 6.2.2).  In this case, the ABR MUST
   re-advertise in the egress area the MVPN/VPLS A-D route that matches
   the Leaf A-D route to signal the binding of the intra-area P2MP LSP
   to the inter-area P2MP service LSP.  This must be done if and only if
   (a) such a binding hasn't already been advertised or (b) the binding
   has changed.  The re-advertised route MUST carry the Inter-area P2MP
   Segmented Next-Hop Extended Community.

   The PMSI Tunnel attribute of the re-advertised route specifies either
   an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted
   at the ABR and MUST also carry an upstream-assigned MPLS label.  The
   upstream-assigned MPLS label MUST be set to Implicit NULL if the
   mapping between the inter-area P2MP service LSP and the intra-area
   P2MP LSP is one-to-one.  If the mapping is many-to-one, the intra-
   area segment of the inter-area P2MP service LSP (referred to as the

   "inner" P2MP LSP) is constructed by nesting the inter-area P2MP
   service LSP in an intra-area P2MP LSP (referred to as the "outer"
   intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream-
   assigned MPLS labels [RFC5332].

   If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried
   over a given intra-area P2MP LSP, each of these segments MUST carry a
   distinct upstream-assigned label, even if all these service LSPs are
   for (C-S/*,C-G/*)s from the same MVPN/VPLS.  Therefore, an ABR
   maintains a Label Forwarding Information Base (LFIB) state for each
   such S-PMSI traversing the ABR (that applies to both the ingress and
   the egress ABRs).

7.2.2.  Received Leaf A-D Route Is for Global Table Multicast

   When the RD of the received Leaf A-D route is set to all zeros or all
   ones, this is the case of inter-area P2MP service LSP being
   associated with the global table multicast service.  The procedures
   for this are described below.

7.2.2.1.  Global Table Multicast and S-PMSI A-D Routes

   This section applies only if it is desired to send a particular (S,G)
   or (*,G) global table multicast flow to only those egress PEs that
   have receivers for that multicast flow.

   If the egress ABR has not previously received (and re-advertised) an
   S-PMSI A-D route for (S,G) or (*,G) that has been originated by an
   ingress PE/ASBR (see Section 9.1), then the egress ABR MUST originate
   an S-PMSI A-D route.  The PMSI Tunnel attribute of the route MUST
   contain the identity of the intra-area P2MP LSP and an upstream-
   assigned MPLS label (although this label may be an Implicit NULL --
   see Section 3).  The RD, Multicast Source Length, Multicast Source,
   Multicast Group Length (1 octet), and Multicast Group fields of the
   NLRI of this route are the same as those of the received Leaf A-D
   route.  The Originating Router's IP Address field in the S-PMSI A-D
   route is the same as the Ingress PE's IP Address field in the
   received Leaf A-D route.  The Route Target of this route is an AS-
   specific Route Target Extended Community with the Global
   Administrator field set to the AS of the advertising ABR and the
   Local Administrator field set to 0.  The route MUST carry the Inter-
   Area P2MP Segmented Next-Hop Extended Community.  This Extended
   Community is constructed following the procedures in Section 4.

   The egress ABR MUST advertise this route into the egress area.  PEs
   in the egress area that participate in the global table multicast
   will import this route based on the Route Target carried by the
   route.

   A PE in the egress area that originated the Leaf A-D route SHOULD
   join the P2MP LSP advertised in the PMSI Tunnel attribute of the
   S-PMSI A-D route.

7.2.2.2.  Global Table Multicast and Wildcard S-PMSI A-D Routes

   It may be desirable for an ingress PE to carry multiple multicast
   flows associated with the global table multicast over the same inter-
   area P2MP service LSP.  This can be achieved using wildcard, i.e.,
   (*,*) S-PMSI A-D routes [RFC6625].  An ingress PE MAY advertise a
   wildcard S-PMSI A-D route as described in Section 9.

   If the ingress PE originates a wildcard S-PMSI A-D route, and the
   egress ABR receives this route from the ingress ABR, then the egress
   ABR either (a) MUST re-advertise this route into the egress area with
   the PMSI Tunnel attribute containing the identifier of the intra-area
   P2MP LSP in the egress area and an upstream-assigned label (note that
   this label may be an Implicit NULL -- see Section 3) assigned to the
   inter-area wildcard S-PMSI or (b) MUST be able to disaggregate
   traffic carried over the wildcard S-PMSI onto the egress area (S,G)
   or (*,G) S-PMSIs.  The procedures for such disaggregation require IP
   processing on the egress ABRs.

   If the egress ABR advertises a wildcard S-PMSI A-D route into the
   egress area, this route MUST carry an AS-specific Route Target
   Extended Community with the Global Administrator field set to the AS
   of the advertising ABR and the Local Administrator field set to 0.
   PEs in the egress area that participate in the global table multicast
   will import this route.

   A PE in the egress area SHOULD join the P2MP LSP advertised in the
   PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the
   Originating Router's IP Address field in the S-PMSI A-D route has the
   same value as the Ingress PE's IP Address in at least one of the Leaf
   A-D routes for global table multicast originated by the PE and (b)
   the upstream ABR for the Ingress PE's IP address in that Leaf A-D
   route is the egress ABR that advertises the wildcard S-PMSI A-D
   route.

7.2.3.  Global Table Multicast and the Expected Upstream Node

   If the mapping between the inter-area P2MP service LSP for global
   table multicast service and the intra-area P2MP LSP is many-to-one,
   then an egress PE must be able to determine whether a given multicast
   packet for a particular (S,G) is received from the "expected"
   upstream node.  The expected node is the node towards which the Leaf
   A-D route is sent by the egress PE.  Packets received from another
   upstream node for that (S,G) MUST be dropped.  To allow the egress PE

   to determine the sender upstream node, the intra-area P2MP LSP MUST
   be signaled with no Penultimate Hop Popping (PHP), when the mapping
   between the inter-area P2MP service LSP for global table multicast
   service and the intra-area P2MP LSP is many-to-one.

   Further, the egress ABR MUST first push onto the label stack the
   upstream-assigned label advertised in the S-PMSI A-D route, if the
   label is not the Implicit NULL.

7.2.4.  P2MP LDP LSP as the Intra-Area P2MP LSP

   The above procedures are sufficient if P2MP LDP LSPs are used as the
   intra-area P2MP LSP in the egress area.

7.2.5.  P2MP RSVP-TE LSP as the Intra-Area P2MP LSP

   If P2MP RSVP-TE LSP is used as the intra-area LSP in the egress area,
   then the egress ABR can either (a) graft the leaf (whose IP address
   is specified in the received Leaf A-D route) into an existing P2MP
   LSP rooted at the egress ABR, and use that LSP for carrying traffic
   for the inter-area segmented P2MP service LSP or (b) originate a new
   P2MP LSP to be used for carrying (S,G).

   When the RD of the received Leaf A-D route is all zeros or all ones,
   the procedures are as described in Section 7.2.2.

   Note also that the SESSION object that the egress ABR would use for
   the intra-area P2MP LSP need not encode the P2MP FEC from the
   received Leaf A-D route.

7.3.  Ingress Replication in the Egress Area

   When ingress replication is used to instantiate the egress area
   segment, the Leaf A-D route advertised by the egress PE MUST carry a
   downstream-assigned label in the PMSI Tunnel attribute where the
   Tunnel Type is set to ingress replication.  We will call this label
   the egress PE downstream-assigned label.

   The egress ABR MUST forward packets received from the backbone area
   intra-area segment, for a particular inter-area P2MP LSP, to all the
   egress PEs from which the egress ABR has imported a Leaf A-D route
   for the inter-area P2MP LSP.  A packet to a particular egress PE is
   encapsulated, by the egress ABR, using an MPLS label stack the bottom
   label of which is the egress PE downstream-assigned label.  The top
   label is the P2P RSVP-TE or the MP2P LDP label to reach the
   egress PE.

   Note that these procedures ensure that an egress PE always receives
   packets only from the upstream node expected by the egress PE.