Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7524

Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)

Pages: 42
Proposed Standard
Updated by:  8534
Part 2 of 3 – Pages 13 to 27
First   Prev   Next

Top   ToC   RFC7524 - Page 13   prevText

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.
Top   ToC   RFC7524 - Page 14

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.
Top   ToC   RFC7524 - Page 15

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.
Top   ToC   RFC7524 - Page 16
   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
Top   ToC   RFC7524 - Page 17
   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.
Top   ToC   RFC7524 - Page 18

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.
Top   ToC   RFC7524 - Page 19
   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.
Top   ToC   RFC7524 - Page 20
   + 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).
Top   ToC   RFC7524 - Page 21
   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.
Top   ToC   RFC7524 - Page 22
   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.
Top   ToC   RFC7524 - Page 23
   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
Top   ToC   RFC7524 - Page 24
   "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.
Top   ToC   RFC7524 - Page 25
   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
Top   ToC   RFC7524 - Page 26
   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.
Top   ToC   RFC7524 - Page 27
   Note that these procedures ensure that an egress PE always receives
   packets only from the upstream node expected by the egress PE.



(page 27 continued on part 3)

Next Section