tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7524

 
 
 

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

Part 3 of 3, p. 27 to 42
Prev RFC Part

 


prevText      Top      Up      ToC       Page 27 
8.  Ingress ABR Procedures

   When an ingress 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 ingress ABR follows the same procedures as in Section
   7, with egress ABR replaced by ingress ABR, backbone area replaced by
   ingress area, and backbone area segment replaced by ingress area
   segment.

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

8.1.  P2MP LSP as the Intra-Area LSP in the Backbone Area

   The procedures for binding the backbone area segment of an inter-area
   P2MP LSP to the intra-area P2MP LSP in the backbone area are the same
   as in Sections 7 and 7.2, with egress PE being replaced by egress
   ABR, egress ABR being replaced by ingress ABR, and egress area being
   replaced by backbone area.  This applies to the inter-area P2MP LSPs
   associated with either MVPN, VPLS, or global table multicast.

   It is to be noted that, in the case of global table multicast, if the
   backbone area uses wildcard S-PMSI, then the egress area also SHOULD
   use wildcard S-PMSI for global table multicast, or the egress ABRs
   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.

8.2.  Ingress Replication in the Backbone Area

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

   The ingress ABR MUST forward packets received from the ingress area
   intra-area segment, for a particular inter-area P2MP LSP, to all the
   egress ABRs from which the ingress ABR has imported a Leaf A-D route
   for the inter-area P2MP LSP.  A packet to a particular egress ABR is
   encapsulated, by the ingress ABR, using an MPLS label stack the
   bottom label of which is the egress ABR downstream-assigned label.

Top      Up      ToC       Page 28 
   The top label is the P2P RSVP-TE or the MP2P LDP label to reach the
   egress ABR.

9.  Ingress PE/ASBR Procedures

   This section describes the ingress PE/ASBR procedures for
   constructing segmented inter-area P2MP LSPs.

   When an ingress PE/ASBR receives a Leaf A-D route and the Route
   Target Extended Community carried by the route contains the IP
   address of this PE/ASBR, 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 ingress PE/ASBR 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 or else it
   MUST be discarded.  If the Leaf A-D route is accepted, then it MUST
   be processed as per MVPN or VPLS procedures.

   If the RD of the received 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 this is the first Leaf A-D route for the Route Key
   carried in the route, the PIM implementation MUST set its upstream
   (S/RP,G) state machine to Joined state for the (S/RP,G) received via
   a Leaf A-D route update.  Likewise, if this is the withdrawal of the
   last Leaf A-D route whose Route Key matches a particular (S/RP,G)
   state, the PIM implementation MUST set its upstream (S/RP,G) state
   machine to Prune state for the (S/RP,G).

9.1.  P2MP LSP as the Intra-Area LSP in the Ingress Area

   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 (which indicates that
   the Leaf A-D route was originated in response to an S-PMSI or I-PMSI
   A-D route), and P2MP LSP is used as the intra-area LSP in the ingress
   area, then the procedures for binding the ingress area segment of the
   inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area
   are the same as in Sections 7 and 7.2.

   When the RD of the received Leaf A-D route is all zeros or all ones,
   as is the case where the inter-area service P2MP LSP is associated
   with the global table multicast service, the ingress PE MAY originate
   an S-PMSI A-D route with the RD, multicast source, and multicast
   group fields being the same as those in the received Leaf A-D route.

Top      Up      ToC       Page 29 
   Further, in the case of global table multicast, an ingress PE MAY
   originate a wildcard S-PMSI A-D route as per the procedures in
   [RFC6625] with the RD set to 0.  This route may be originated by the
   ingress PE based on configuration or based on the import of a Leaf
   A-D route with the RD set to 0.  If an ingress PE originates such a
   route, then the ingress PE MAY decide not to originate (S,G) or (*,G)
   S-PMSI A-D routes.

   The wildcard S-PMSI A-D route MUST carry the Inter-Area P2MP
   Segmented Next-Hop Extended Community.  This Extended Community is
   constructed following the procedures in Section 4.

   It is to be noted that, in the case of global table multicast, if the
   ingress area uses wildcard S-PMSI, then the backbone area also SHOULD
   use wildcard S-PMSI for global table multicast, or the ingress ABRs
   MUST be able to disaggregate traffic carried over the wildcard S-PMSI
   onto the backbone area (S,G) or (*,G) S-PMSIs.  The procedures for
   such disaggregation require IP processing on the ingress ABRs.

9.2.  Ingress Replication in the Ingress Area

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

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

10.  Common Tunnel Type in the Ingress and Egress Areas

   For a given inter-area service P2MP LSP, the PE/ASBR that is the root
   of that LSP controls the type of the intra-area P-tunnel that carries
   the ingress area segment of that LSP.  However, the type of the
   intra-area P-tunnel that carries the backbone area segment of that
   LSP may be different from the type of the intra-area P-tunnels that
   carry the ingress area segment and the egress area segment of that
   LSP.  In that situation, if, for a given inter-area P2MP LSP, it is
   desirable/necessary to use the same type of tunnel for the intra-area
   P-tunnels that carry the ingress area segment and for the intra-area

Top      Up      ToC       Page 30 
   P-tunnels that carry the egress area segment of that LSP, then the
   following procedures on the ingress ABR and egress ABR provide this
   functionality.

   When an ingress ABR re-advertises into the backbone area a BGP MVPN
   I-PMSI, S-PMSI A-D route, or VPLS A-D route, the ingress ABR places
   the PMSI Tunnel attribute of this route into the ATTR_SET BGP
   attribute [RFC6368], adds this attribute to the re-advertised route,
   and then replaces the original PMSI Tunnel attribute with a new one
   (note that the Tunnel Type of the new attribute may be different from
   the Tunnel Type of the original attribute).

   When an egress ABR re-advertises into the egress area a BGP MVPN
   I-PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries
   the ATTR_SET BGP attribute [RFC6368], the ABR sets the Tunnel Type of
   the PMSI Tunnel attribute in the re-advertised route to the Tunnel
   Type of the PMSI Tunnel attribute carried in the ATTR_SET BGP
   attribute, and removes the ATTR_SET from the route.

11.  Placement of Ingress and Egress PEs

   As described in the earlier sections, procedures in this document
   allow the placement of ingress and egress PEs in the backbone area.
   They also allow the placement of egress PEs in the ingress area or
   the placement of ingress PEs in the egress area.

   For instance, suppose that in the ingress and egress areas, a global
   table multicast service is being provided, and the data is being sent
   over PIM-based IP/GRE P-tunnels.  Suppose also that it is desired to
   carry that data over the backbone area through MPLS P-tunnels.  This
   can be done if the ABR connecting the ingress area to the backbone
   follows the procedures that this document specifies for ingress PEs
   providing the global table multicast service, and if the ABR
   connecting the egress area to the backbone follows the procedures
   that this document specifies for egress PEs providing the global
   table multicast service.

   If MVPN service is being provided in the ingress and egress areas,
   with the MVPN data carried in PIM-based IP/GRE P-tunnels, this same
   technique enables the MVPN data to be carried over the backbone in
   MPLS P-tunnels.  The PIM-based IP/GRE P-tunnels in the ingress and
   egress areas are treated as global table multicasts, and the ABRs
   provide the ingress and egress PE functionality.

Top      Up      ToC       Page 31 
12.  MVPN with Virtual Hub-and-Spoke

   Procedures described in this document could be used in conjunction
   with the Virtual Hub-and-Spoke procedures [RFC7024].

   This document does not place any restrictions on the placement of
   Virtual Hubs and Virtual Spokes.

   In addition to I-PMSI/S-PMSI A-D routes, the procedures described in
   this document are applicable to Associated-V-spoke-only I-PMSI A-D
   routes.

   In the scenario where a V-hub, as a result of importing an S-PMSI A-D
   route in its VRF, originates an S-PMSI A-D route targeted to its
   V-spokes (as specified in Section 7.8.2 of [RFC7024]), the V-hub
   SHOULD be able to control via configuration whether the Inter-Area
   P2MP Segmented Next-Hop Extended Community, if present in the
   received S-PMSI A-D route, should also be carried in the originated
   S-PMSI A-D route.  By default, if the received S-PMSI A-D route
   carries the Inter-Area P2MP Segmented Next-Hop Extended Community,
   then the originated S-PMSI A-D route SHOULD also carry this Extended
   Community.

13.  Data Plane

   This section describes the data plane procedures on the ABRs, ingress
   PEs, egress PEs, and transit routers.

13.1.  Data Plane Procedures on ABRs

   When procedures in this document are followed to signal inter-area
   P2MP segmented LSPs, ABRs are required to perform only MPLS
   switching.  When an ABR receives an MPLS packet from an "incoming"
   intra-area segment of the inter-area P2MP segmented LSP, it forwards
   the packet, based on MPLS switching, on to another "outgoing" intra-
   area segment of the inter-area P2MP segmented LSP.

   If the outgoing intra-area segment is instantiated using a P2MP LSP,
   and if there is a one-to-one mapping between the outgoing intra-area
   segment and the P2MP LSP, then the ABR MUST pop the incoming
   segment's label stack and push the label stack of the outgoing P2MP
   LSP.  If there is a many-to-one mapping between outgoing intra-area
   segments and the P2MP LSP, then the ABR MUST pop the incoming
   segment's label stack and first push the upstream-assigned label
   corresponding to the outgoing intra-area segment, if such a label has
   been assigned, and then push the label stack of the outgoing P2MP
   LSP.

Top      Up      ToC       Page 32 
   If the outgoing intra-area segment is instantiated using ingress
   replication, then the ABR must pop the incoming segment's label stack
   and replicate the packet once to each leaf ABR or PE of the outgoing
   intra-area segment.  The label stack of the packet sent to each such
   leaf MUST first include a downstream-assigned label assigned by the
   leaf to the segment, followed by the label stack of the P2P or MP2P
   LSP to the leaf.

13.2.  Data Plane Procedures on Egress PEs

   An egress PE must first identify the inter-area P2MP segmented LSP
   based on the incoming label stack.  After this identification, the
   egress PE must forward the packet using the application that is bound
   to the inter-area P2MP segmented LSP.

   Note that the application-specific forwarding for MVPN service may
   require the egress PE to determine whether the packets were received
   from the expected sender PE.  When the application is MVPN, the FEC
   of an inter-area P2MP segmented LSP is at the granularity of the
   sender PE.  Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D
   routes both carry the Originating Router's IP Address.  Thus, an
   egress PE could associate the data arriving on P-tunnels advertised
   by these routes with the Originating Router's IP Address carried by
   these routes, which is the same as the ingress PE.  Since a unique
   label stack is associated with each such FEC, the egress PE can
   determine the sender PE from the label stack.

   Likewise for VPLS service, for the purposes of Media Access Control
   (MAC) learning the egress, the PE must be able to determine the
   "VE-ID" (VPLS Edge Device Identifier) from which the packets have
   been received.  The FEC of the VPLS A-D routes carries the VE-ID.
   Thus, an egress PE could associate the data arriving on P-tunnels
   advertised by these routes with the VE-ID carried by these routes.
   Since a unique label stack is associated with each such FEC, the
   egress PE can perform MAC learning for packets received from a given
   VE-ID.

   When the application is global table multicast, it is sufficient for
   the label stack to include identification of the sender upstream
   node.  When P2MP LSPs are used, this requires that PHP MUST be turned
   off.  When ingress replication is used, the egress PE knows the
   incoming downstream-assigned label to which it has bound a particular
   (S/*,G) and must accept packets with only that label for that
   (S/*,G).

Top      Up      ToC       Page 33 
13.3.  Data Plane Procedures on Ingress PEs

   An Ingress PE must perform application-specific forwarding procedures
   to identify the outgoing intra-area segment of an incoming packet.

   If the outgoing intra-area segment is instantiated using a P2MP LSP,
   and if there is a one-to-one mapping between the outgoing intra-area
   segment and the P2MP LSP, then the ingress PE MUST encapsulate the
   packet in the label stack of the outgoing P2MP LSP.  If there is a
   many-to-one mapping between outgoing intra-area segments and the P2MP
   LSP, then the PE MUST first push the upstream-assigned label
   corresponding to the outgoing intra-area segment, if such a label
   has been assigned, and then push the label stack of the outgoing
   P2MP LSP.

   If the outgoing intra-area segment is instantiated using ingress
   replication, then the PE must replicate the packet once to each leaf
   ABR or PE of the outgoing intra-area segment.  The label stack of the
   packet sent to each such leaf MUST first include a downstream-
   assigned label assigned by the leaf to the segment, followed by the
   label stack of the P2P or MP2P LSP to the leaf.

13.4.  Data Plane Procedures on Transit Routers

   When procedures in this document are followed to signal inter-area
   P2MP segmented LSPs, transit routers in each area perform only MPLS
   switching.

14.  Support for Inter-Area Transport LSPs

   This section describes OPTIONAL procedures that allow multiple
   (inter-area) P2MP LSPs to be aggregated into a single inter-area P2MP
   "transport LSP".  The segmentation procedures, as specified in this
   document, are then applied to these inter-area P2MP transport LSPs,
   rather than being applied directly to the individual LSPs that are
   aggregated into the transport.  In the following, the individual LSPs
   that are aggregated into a single transport LSP will be known as
   "service LSPs".

14.1.  "Transport Tunnel" Tunnel Type

   For the PMSI Tunnel attribute, we define a new Tunnel Type, called
   "Transport Tunnel", whose Tunnel Identifier is a tuple <Source PE
   Address, Local Number>.  This Tunnel Type is assigned a value of 8.
   The Source PE Address is the address of the PE that originates the
   (service) A-D route that carries this attribute, and the Local Number
   is a number that is unique to the Source PE.  The length of the Local
   Number part is the same as the length of the Source PE Address.

Top      Up      ToC       Page 34 
   Thus, if the Source PE Address is an IPv4 address, then the Local
   Number part is 4 octets; if the Source PE Address is an IPv6 address,
   then the Local Number part is 16 octets.

14.2.  Discovering Leaves of the Inter-Area P2MP Service LSP

   When aggregating multiple P2MP LSPs using P2MP LSP hierarchy,
   determining the leaf nodes of the LSPs being aggregated is essential
   for being able to trade-off the overhead due to the P2MP LSPs versus
   suboptimal use of bandwidth due to the partial congruency of the LSPs
   being aggregated.

   Therefore, if a PE that is a root of a given service P2MP LSP wants
   to aggregate this LSP with other (service) P2MP LSPs rooted at the
   same PE into an inter-area P2MP transport LSP, the PE should first
   determine all the leaf nodes of that service LSP, as well as those of
   the other service LSPs being aggregated.

   To accomplish this, the PE sets the PMSI Tunnel attribute of the
   service A-D route (an I-PMSI or S-PMSI A-D route for MVPN or VPLS
   service) associated with that LSP as follows.  The Tunnel Type is set
   to "No tunnel information present", and the "Leaf Information
   Required" flag is set to 1.  The route MUST NOT carry the Inter-Area
   P2MP Segmented Next-Hop Extended Community.  In contrast to the
   procedures for the MVPN and VPLS A-D routes described so far, the
   Route Reflectors that participate in the distribution of this route
   need not be ABRs.

14.3.  Discovering P2MP FEC of P2MP Transport LSP

   Once the ingress PE determines all the leaves of a given P2MP service
   LSP, the PE (using some local criteria) selects a particular inter-
   area transport P2MP LSP to be used for carrying the (inter-area)
   service P2MP LSP.

   Once the PE selects the transport P2MP LSP, the PE (re-)originates
   the service A-D route.  The PMSI Tunnel attribute of this route now
   carries the Tunnel Identifier of the selected transport LSP, with the
   Tunnel Type set to "Transport Tunnel".  If the transport LSP carries
   multiple P2MP service LSPs, then the MPLS Label field in the
   attribute carries an upstream-assigned label assigned by the PE that
   is bound to the P2MP FEC of the inter-area P2MP service LSP.
   Otherwise, this field is set to Implicit NULL.

   As described earlier, this service A-D route MUST NOT carry the
   Inter-Area P2MP Segmented Next-Hop Extended Community, and the Route
   Reflectors that participate in the distribution of this route need
   not be ABRs.

Top      Up      ToC       Page 35 
14.4.  Egress PE Procedures for P2MP Transport LSP

   When an egress PE receives and accepts an MVPN or VPLS service A-D
   route, if the "Leaf Information Required" flag in the PMSI Tunnel
   attribute of the received A-D route is set to 1, and the route does
   not carry the Inter-Area P2MP Segmented Next-Hop Extended Community,
   then the egress PE, following the "regular" MVPN or VPLS procedures
   associated with the received A-D route (as specified in [RFC6514] and
   [RFC7117]), originates a Leaf A-D route.

   In addition, if the Tunnel Type in the PMSI Tunnel attribute of the
   received service A-D route is set to "Transport Tunnel", the egress
   PE originates yet another Leaf A-D route.

   The format of the Route Key field of the MCAST-VPN NLRI of this
   additional Leaf A-D route is the same as defined in Section 6.2.2.
   The Route Key field of the MCAST-VPN NLRI of this route is
   constructed as follows:

      RD (8 octets) - set to 0

      Multicast Source Length, Multicast Source - constructed from the
          Source PE Address part of the Tunnel Identifier carried in the
          PMSI Tunnel attribute of the received service S-PMSI A-D
          route.

      Multicast Group Length, Multicast Group - constructed from the
          Local Number part of the Tunnel Identifier carried in the PMSI
          Tunnel attribute of the received service S-PMSI A-D route.

      Ingress PE IP Address - set to the Source PE Address part of the
          Tunnel Identifier carried in the PMSI Tunnel attribute of the
          received service S-PMSI A-D route.

   The egress PE, when determining the upstream ABR, follows the
   procedures specified in Section 6.1 for global table multicast.

   The egress PE constructs the rest of the Leaf A-D route following the
   procedures specified in Section 6.2.3.

   From that point on we follow the procedures used for the Leaf A-D
   routes for global table multicast, as outlined below.

14.5.  ABRs and Ingress PE Procedures for P2MP Transport LSP

   In this section, we specify ingress and egress ABRs, as well as
   ingress PE procedures for P2MP transport LSPs.

Top      Up      ToC       Page 36 
   When an egress ABR receives the Leaf A-D route, and P2MP LSP is used
   to instantiate the egress area segment of the inter-area transport
   LSP, the egress ABR will advertise into the egress area an S-PMSI A-D
   route.  This route is constructed following the procedures in Section
   7.2.2.1.  The egress PE(s) will import this route.

   The egress ABR will also propagate, with appropriate modifications,
   the received Leaf A-D route into the backbone area.  This is
   irrespective of whether the egress area segment is instantiated using
   P2MP LSP or ingress replication.

   If P2MP LSP is used to instantiate the backbone area segment of the
   inter-area transport LSP, then an ingress ABR will advertise into the
   backbone area an S-PMSI A-D route.  This route is constructed
   following the procedures in Section 7.1.2.1.  The egress ABR(s) will
   import this route.

   The ingress ABR will also propagate, with appropriate modifications,
   the received Leaf A-D route into the ingress area towards the
   ingress/root PE.  This is irrespective of whether the backbone area
   segment is instantiated using P2MP LSP or ingress replication.

   Finally, if P2MP LSP is used to instantiate the ingress area segment,
   the ingress PE will advertise into the ingress area an S-PMSI A-D
   route with the RD, multicast source, and multicast group fields being
   the same as those in the received Leaf A-D route.  The PMSI Tunnel
   attribute of this route contains the identity of the intra-area P2MP
   LSP used to instantiate the ingress area segment, and an upstream-
   assigned MPLS label.  The ingress ABR(s) and other PE(s) in the
   ingress area, if any, will import this route.  The ingress PE will
   use the (intra-area) P2MP LSP advertised in this route for carrying
   traffic associated with the original service A-D route advertised by
   the PE.

14.6.  Discussion

   Use of inter-area transport P2MP LSPs, as described in this section,
   creates a level of indirection between (inter-area) P2MP service
   LSPs, and intra-area transport LSPs that carry the service LSPs.
   Rather than segmenting (inter-area) service P2MP LSPs, and then
   aggregating (intra-area) segments of these service LSPs into intra-
   area transport LSPs, this approach first aggregates multiple (inter-
   area) service P2MP LSPs into a single inter-area transport P2MP LSP,
   then segments such inter-area transport P2MP LSPs, and then
   aggregates (intra-area) segments of these inter-area transport LSPs
   into intra-area transport LSPs.

Top      Up      ToC       Page 37 
   On one hand, this approach could result in reducing the state (and
   the overhead associated with maintaining the state) on ABRs.  This is
   because instead of requiring ABRs to maintain state for individual
   P2MP service LSPs, ABRs would need to maintain state only for the
   inter-area P2MP transport LSPs.  Note, however, that this reduction
   is possible only if a single inter-area P2MP transport LSP aggregates
   more than one (inter-area) service LSP.  In the absence of such
   aggregation, use of inter-area transport LSPs provides no benefits,
   yet results in extra overhead.  And while such aggregation does allow
   reduced state on ABRs, it comes at a price, as described below.

   As we mentioned before, aggregating multiple P2MP service LSPs into a
   single inter-area P2MP transport LSP requires the PE rooted at these
   LSPs to determine all the leaf nodes of the service LSPs to be
   aggregated.  This means that the root PE has to track all the leaf
   PEs of these LSPs.  In contrast, when one applies segmentation
   procedures directly to the P2MP service LSPs, the root PE has to
   track only the leaf PEs in its own IGP area, plus the ingress ABR(s).
   Likewise, an ingress ABR has to track only the egress ABRs.  Finally,
   an egress ABR has to track only the leaf PEs in its own area.
   Therefore, while the total overhead of leaf tracking due to the P2MP
   service LSPs is about the same in both approaches, the distribution
   of this overhead is different.  Specifically, when one uses inter-
   area P2MP transport LSPs, this overhead is concentrated on the
   ingress PE.  When one applies segmentation procedures directly to the
   P2MP service LSPs, this overhead is distributed among the ingress PE
   and ABRs.

   Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to
   bear the overhead of leaf tracking for inter-area P2MP transport
   LSPs.  In contrast, when one applies segmentation procedures directly
   to the P2MP service LSPs, there is no such overhead (as there are no
   inter-area P2MP transport LSPs).

   Use of inter-area P2MP transport LSPs may also result in more
   bandwidth inefficiency, as compared to applying segmentation
   procedures directly to the P2MP service LSPs.  This is because with
   inter-area P2MP transport LSPs the ABRs aggregate segments of inter-
   area P2MP transport LSPs, rather than segments of (inter-area) P2MP
   service LSPs.  To illustrate this, consider the following example.

   Assume PE1 in Area 1 is an ingress PE, with two multicast streams,
   (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected
   to PE1.  Assume that PE2 in Area 2 has an MVPN site with receivers
   for (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with
   receivers for both (C-S1, C-G1) and (C-S2, C-G2).  Finally, assume
   that PE5 in Area 4 has an MVPN site with receivers for (C-S2, C-G2).

Top      Up      ToC       Page 38 
   When segmentation applies directly to the P2MP service LSPs, Area 2
   would have just one intra-area transport LSP that would carry the
   egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3
   would have just one intra-area transport LSP that would carry the
   egress area segments of both the P2MP service LSP for (C-S1, C-G1)
   and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one
   intra-area transport LSP that would carry the egress area segment of
   the P2MP service LSP for (C-S2, C-G2).  Note that there is no
   bandwidth inefficiency in this case at all.

   When using inter-area P2MP transport LSPs, to achieve the same state
   overhead on the routers within each of the egress areas (except for
   egress ABRs), PE1 would need to aggregate the P2MP service LSP for
   (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same
   inter-area P2MP transport LSP.  While such aggregation would reduce
   state on ABRs, it would also result in bandwidth inefficiency, as
   (C-S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but
   also to PE5, which has no receivers for this stream.  Likewise,
   (C-S2, C-G2) will be delivered not just to PE3, PE4, and PE5, but
   also to PE2, which has no receivers for this stream.

15.  IANA Considerations

   This document defines a new BGP Extended Community called "Inter-Area
   P2MP Segmented Next-Hop" (see Section 4).  This may be either a
   Transitive IPv4-Address-Specific Extended Community or a Transitive
   IPv6-Address-Specific Extended Community.  IANA has assigned the
   value 0x12 in the "Transitive IPv4-Address-Specific Extended
   Community Sub-Types" registry, and IANA has assigned the value 0x0012
   in the "Transitive IPv6-Address-Specific Extended Community Types"
   registry.  This document is the reference for both code points.

   IANA has assigned the value 0x08 in the "P-Multicast Service
   Interface Tunnel (PMSI Tunnel) Tunnel Types" registry [RFC7385] as
   "Transport Tunnel" (see Section 14).

   This document makes use of a Route Distinguisher whose value is all
   ones.  The two-octet type field of this Route Distinguisher thus has
   the value 65535.  IANA has assigned this value in the "Route
   Distinguisher Type Field" registry as "For Use Only in Certain Leaf
   A-D Routes", with this document as the reference.

16.  Security Considerations

   Procedures described in this document are subject to security threats
   similar to those experienced by any MPLS deployment.  It is
   recommended that baseline security measures are considered as
   described in "Security Framework for MPLS and GMPLS Networks"

Top      Up      ToC       Page 39 
   [RFC5920], in the mLDP specification [RFC6388], and in the P2MP
   RSVP-TE specification [RFC3209].  The security considerations of
   [RFC6513] are also applicable.

17.  References

17.1.  Normative References

   [RFC1997]   Chandra, R., Traina, P., and T. Li, "BGP Communities
               Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
               <http://www.rfc-editor.org/info/rfc1997>.

   [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>.

   [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>.

   [RFC4360]   Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
               Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
               February 2006, <http://www.rfc-editor.org/info/rfc4360>.

   [RFC4456]   Bates, T., Chen, E., and R. Chandra, "BGP Route
               Reflection: An Alternative to Full Mesh Internal BGP
               (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
               <http://www.rfc-editor.org/info/rfc4456>.

   [RFC4684]   Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
               R., Patel, K., and J. Guichard, "Constrained Route
               Distribution for Border Gateway Protocol/MultiProtocol
               Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
               Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
               November 2006, <http://www.rfc-editor.org/info/rfc4684>.

   [RFC4760]   Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
               "Multiprotocol Extensions for BGP-4", RFC 4760,
               DOI 10.17487/RFC4760, January 2007,
               <http://www.rfc-editor.org/info/rfc4760>.

   [RFC4761]   Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
               LAN Service (VPLS) Using BGP for Auto-Discovery and
               Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
               <http://www.rfc-editor.org/info/rfc4761>.

Top      Up      ToC       Page 40 
   [RFC4875]   Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
               Yasukawa, Ed., "Extensions to Resource Reservation
               Protocol - Traffic Engineering (RSVP-TE) for Point-to-
               Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
               DOI 10.17487/RFC4875, May 2007,
               <http://www.rfc-editor.org/info/rfc4875>.

   [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>.

   [RFC5331]   Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
               Label Assignment and Context-Specific Label Space",
               RFC 5331, DOI 10.17487/RFC5331, August 2008,
               <http://www.rfc-editor.org/info/rfc5331>.

   [RFC5332]   Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
               "MPLS Multicast Encapsulations", RFC 5332,
               DOI 10.17487/RFC5332, August 2008,
               <http://www.rfc-editor.org/info/rfc5332>.

   [RFC6074]   Rosen, E., Davie, B., Radoaca, V., and W. Luo,
               "Provisioning, Auto-Discovery, and Signaling in Layer 2
               Virtual Private Networks (L2VPNs)", RFC 6074,
               DOI 10.17487/RFC6074, January 2011,
               <http://www.rfc-editor.org/info/rfc6074>.

   [RFC6368]   Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T.
               Yamagata, "Internal BGP as the Provider/Customer Edge
               Protocol for BGP/MPLS IP Virtual Private Networks
               (VPNs)", RFC 6368, DOI 10.17487/RFC6368, September 2011,
               <http://www.rfc-editor.org/info/rfc6368>.

   [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>.

   [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>.

Top      Up      ToC       Page 41 
   [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>.

   [RFC7117]   Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
               C. Kodeboniya, "Multicast in Virtual Private LAN Service
               (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
               <http://www.rfc-editor.org/info/rfc7117>.

   [RFC7385]   Andersson, L. and G. Swallow, "IANA Registry for
               P-Multicast Service Interface (PMSI) Tunnel Type Code
               Points", RFC 7385, DOI 10.17487/RFC7385, October 2014,
               <http://www.rfc-editor.org/info/rfc7385>.

17.2.  Informative References

   [GTM]       Zhang, J, Giuliano, L, Rosen, E., Ed., Subramanian, K.,
               Pacella, D., and J. Schiller, "Global Table Multicast
               with BGP-MVPN Procedures", Work in Progress, draft-ietf-
               bess-mvpn-global-table-mcast-00, November 2014.

   [RFC5920]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
               Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
               <http://www.rfc-editor.org/info/rfc5920>.

   [RFC7024]   Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter,
               Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS
               VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013,
               <http://www.rfc-editor.org/info/rfc7024>.

   [SEAMLESS-MPLS]
               Leymann, N., Ed., Decraene, B., Filsfils, C.,
               Konstantynowicz, M., Ed., and D. Steinberg, "Seamless
               MPLS Architecture", Work in Progress,
               draft-ietf-mpls-seamless-mpls-07, June 2014.

Acknowledgements

   We would like to thank Loa Andersson and Qin Wu for their review and
   comments.

Top      Up      ToC       Page 42 
Authors' Addresses

   Yakov Rekhter
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   United States

   Eric C Rosen
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886
   United States
   EMail: erosen@juniper.net

   Rahul Aggarwal
   EMail: raggarwa_1@yahoo.com

   Thomas Morin
   Orange
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   EMail: thomas.morin@orange.com

   Irene Grosclaude
   Orange
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   EMail: irene.grosclaude@orange.com

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21
   Berlin 10781
   Germany
   EMail: n.leymann@telekom.de

   Samir Saad
   AT&T
   EMail: samirsaad1@outlook.com