<pre>Internet Engineering Task Force (IETF)                        Y. Rekhter
Request for Comments: 7524                                      E. Rosen
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                              R. Aggarwal
                                                                  Arktan
                                                                T. Morin
                                                           I. Grosclaude
                                                                  Orange
                                                              N. Leymann
                                                     Deutsche Telekom AG
                                                                 S. Saad
                                                                    AT&amp;T
                                                                May 2015


                 <span class="h1">Inter-Area Point-to-Multipoint (P2MP)</span>
                 <span class="h1">Segmented Label Switched Paths (LSPs)</span>

Abstract

   This document describes procedures for building inter-area point-to-
   multipoint (P2MP) segmented service label switched paths (LSPs) by
   partitioning such LSPs into intra-area segments and using BGP as the
   inter-area routing and Label Distribution Protocol (LDP).  Within
   each IGP area, the intra-area segments are either carried over intra-
   area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using
   ingress replication.  The intra-area P2MP LSPs may be signaled using
   P2MP RSVP-TE or P2MP multipoint LDP (mLDP).  If ingress replication
   is used within an IGP area, then (multipoint-to-point) LDP LSPs or
   (point-to-point) RSVP-TE LSPs may be used in the IGP area.  The
   applications/services that use such inter-area service LSPs may be
   BGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or
   global table multicast over MPLS.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7524">http://www.rfc-editor.org/info/rfc7524</a>.




<span class="grey">Rekhter, et al.              Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































<span class="grey">Rekhter, et al.              Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Specification of Requirements ...................................<a href="#page-5">5</a>
   <a href="#section-3">3</a>. General Assumptions and Terminology .............................<a href="#page-6">6</a>
   <a href="#section-4">4</a>. Inter-Area P2MP Segmented Next-Hop Extended Community ...........<a href="#page-7">7</a>
   <a href="#section-5">5</a>. Discovering P2MP FEC of Inter-Area P2MP Service LSP .............<a href="#page-8">8</a>
      <a href="#section-5.1">5.1</a>. BGP MVPN ...................................................<a href="#page-8">8</a>
           <a href="#section-5.1.1">5.1.1</a>. Routes Originated by PE or ASBR .....................<a href="#page-9">9</a>
           <a href="#section-5.1.2">5.1.2</a>. Routes Re-advertised by PE or ASBR ..................<a href="#page-9">9</a>
           <a href="#section-5.1.3">5.1.3</a>. Inter-Area Routes ...................................<a href="#page-9">9</a>
      <a href="#section-5.2">5.2</a>. LDP VPLS with BGP Auto-discovery or BGP VPLS ..............<a href="#page-10">10</a>
           <a href="#section-5.2.1">5.2.1</a>. Routes Originated by PE or ASBR ....................<a href="#page-10">10</a>
           <a href="#section-5.2.2">5.2.2</a>. Routes Re-advertised by PE or ASBR .................<a href="#page-11">11</a>
           <a href="#section-5.2.3">5.2.3</a>. Inter-Area Routes ..................................<a href="#page-11">11</a>
      <a href="#section-5.3">5.3</a>. Global Table Multicast over MPLS ..........................<a href="#page-12">12</a>
   <a href="#section-6">6</a>. Egress PE/ASBR Signaling Procedures ............................<a href="#page-13">13</a>
      <a href="#section-6.1">6.1</a>. Determining the Upstream ABR/PE/ASBR (Upstream Node) ......<a href="#page-13">13</a>
           <a href="#section-6.1.1">6.1.1</a>. Upstream Node for MVPN or VPLS .....................<a href="#page-13">13</a>
           <a href="#section-6.1.2">6.1.2</a>. Upstream Node for Global Table Multicast ...........<a href="#page-14">14</a>
      <a href="#section-6.2">6.2</a>. Originating a Leaf A-D Route ..............................<a href="#page-15">15</a>
           <a href="#section-6.2.1">6.2.1</a>. Leaf A-D Route for MVPN and VPLS ...................<a href="#page-15">15</a>
           <a href="#section-6.2.2">6.2.2</a>. Leaf A-D Route for Global Table Multicast ..........<a href="#page-15">15</a>
           <a href="#section-6.2.3">6.2.3</a>. Constructing the Rest of the Leaf A-D Route ........<a href="#page-17">17</a>
      <a href="#section-6.3">6.3</a>. PIM-SM in ASM Mode for Global Table Multicast .............<a href="#page-18">18</a>
           <a href="#section-6.3.1">6.3.1</a>. Option 1 ...........................................<a href="#page-18">18</a>
                  <a href="#section-6.3.1.1">6.3.1.1</a>. Originating Source Active A-D Routes ......<a href="#page-18">18</a>
                  6.3.1.2. Receiving BGP Source Active A-D
                           Route by PE ...............................<a href="#page-19">19</a>
                  <a href="#section-6.3.1.3">6.3.1.3</a>. Handling (S,G,rpt) State ..................<a href="#page-19">19</a>
           <a href="#section-6.3.2">6.3.2</a>. Option 2 ...........................................<a href="#page-19">19</a>
                  <a href="#section-6.3.2.1">6.3.2.1</a>. Originating Source Active A-D Routes ......<a href="#page-19">19</a>
                  <a href="#section-6.3.2.2">6.3.2.2</a>. Receiving BGP Source Active A-D Route .....<a href="#page-20">20</a>
                  <a href="#section-6.3.2.3">6.3.2.3</a>. Pruning Sources Off the Shared Tree .......<a href="#page-20">20</a>
                  <a href="#section-6.3.2.4">6.3.2.4</a>. More on Handling (S,G,rpt) State ..........<a href="#page-21">21</a>
   <a href="#section-7">7</a>. Egress ABR Procedures ..........................................<a href="#page-21">21</a>
      <a href="#section-7.1">7.1</a>. Handling Leaf A-D Route on Egress ABR .....................<a href="#page-21">21</a>
      <a href="#section-7.2">7.2</a>. P2MP LSP as the Intra-Area LSP in the Egress Area .........<a href="#page-23">23</a>
           <a href="#section-7.2.1">7.2.1</a>. Received Leaf A-D Route Is for MVPN or VPLS ........<a href="#page-23">23</a>
           7.2.2. Received Leaf A-D Route Is for Global Table
                  Multicast ..........................................<a href="#page-24">24</a>
                  7.2.2.1. Global Table Multicast and S-PMSI
                           A-D Routes ................................<a href="#page-24">24</a>
                  7.2.2.2. Global Table Multicast and
                           Wildcard S-PMSI A-D Routes ................<a href="#page-25">25</a>
           7.2.3. Global Table Multicast and the Expected
                  Upstream Node ......................................<a href="#page-25">25</a>




<span class="grey">Rekhter, et al.              Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


           <a href="#section-7.2.4">7.2.4</a>. P2MP LDP LSP as the Intra-Area P2MP LSP ............<a href="#page-26">26</a>
           <a href="#section-7.2.5">7.2.5</a>. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........<a href="#page-26">26</a>
      <a href="#section-7.3">7.3</a>. Ingress Replication in the Egress Area ....................<a href="#page-26">26</a>
   <a href="#section-8">8</a>. Ingress ABR Procedures .........................................<a href="#page-27">27</a>
      <a href="#section-8.1">8.1</a>. P2MP LSP as the Intra-Area LSP in the Backbone Area .......<a href="#page-27">27</a>
      <a href="#section-8.2">8.2</a>. Ingress Replication in the Backbone Area ..................<a href="#page-27">27</a>
   <a href="#section-9">9</a>. Ingress PE/ASBR Procedures .....................................<a href="#page-28">28</a>
      <a href="#section-9.1">9.1</a>. P2MP LSP as the Intra-Area LSP in the Ingress Area ........<a href="#page-28">28</a>
      <a href="#section-9.2">9.2</a>. Ingress Replication in the Ingress Area ...................<a href="#page-29">29</a>
   <a href="#section-10">10</a>. Common Tunnel Type in the Ingress and Egress Areas ............<a href="#page-29">29</a>
   <a href="#section-11">11</a>. Placement of Ingress and Egress PEs ...........................<a href="#page-30">30</a>
   <a href="#section-12">12</a>. MVPN with Virtual Hub-and-Spoke ...............................<a href="#page-31">31</a>
   <a href="#section-13">13</a>. Data Plane ....................................................<a href="#page-31">31</a>
      <a href="#section-13.1">13.1</a>. Data Plane Procedures on ABRs ............................<a href="#page-31">31</a>
      <a href="#section-13.2">13.2</a>. Data Plane Procedures on Egress PEs ......................<a href="#page-32">32</a>
      <a href="#section-13.3">13.3</a>. Data Plane Procedures on Ingress PEs .....................<a href="#page-33">33</a>
      <a href="#section-13.4">13.4</a>. Data Plane Procedures on Transit Routers .................<a href="#page-33">33</a>
   <a href="#section-14">14</a>. Support for Inter-Area Transport LSPs .........................<a href="#page-33">33</a>
      <a href="#section-14.1">14.1</a>. "Transport Tunnel" Tunnel Type ...........................<a href="#page-33">33</a>
      <a href="#section-14.2">14.2</a>. Discovering Leaves of the Inter-Area P2MP Service LSP ....<a href="#page-34">34</a>
      <a href="#section-14.3">14.3</a>. Discovering P2MP FEC of P2MP Transport LSP ...............<a href="#page-34">34</a>
      <a href="#section-14.4">14.4</a>. Egress PE Procedures for P2MP Transport LSP ..............<a href="#page-35">35</a>
      <a href="#section-14.5">14.5</a>. ABRs and Ingress PE Procedures for P2MP Transport LSP ....<a href="#page-35">35</a>
      <a href="#section-14.6">14.6</a>. Discussion ...............................................<a href="#page-36">36</a>
   <a href="#section-15">15</a>. IANA Considerations ...........................................<a href="#page-38">38</a>
   <a href="#section-16">16</a>. Security Considerations .......................................<a href="#page-38">38</a>
   <a href="#section-17">17</a>. References ....................................................<a href="#page-39">39</a>
      <a href="#section-17.1">17.1</a>. Normative References .....................................<a href="#page-39">39</a>
      <a href="#section-17.2">17.2</a>. Informative References ...................................<a href="#page-41">41</a>
   Acknowledgements ..................................................<a href="#page-41">41</a>
   Authors' Addresses ................................................<a href="#page-42">42</a>




















<span class="grey">Rekhter, et al.              Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document describes procedures for building inter-area point-to-
   multipoint (P2MP) segmented service LSPs by partitioning such LSPs
   into intra-area segments and using BGP as the inter-area routing and
   label distribution protocol.  Within each IGP area, the intra-area
   segments are either carried over intra-area P2MP LSPs, potentially
   using P2MP LSP hierarchy, or instantiated using ingress replication.
   The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE [<a href="./rfc4875" title="&quot;Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)&quot;">RFC4875</a>]
   or P2MP mLDP [<a href="./rfc6388" title="&quot;Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths&quot;">RFC6388</a>].  If ingress replication is used in an IGP
   area, then (multipoint-to-point) LDP LSPs [<a href="./rfc5036" title="&quot;LDP Specification&quot;">RFC5036</a>] or (point-to-
   point) RSVP-TE LSPs [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>] may be used within the IGP area.  The
   applications/services that use such inter-area service LSPs may be
   BGP Multicast VPN (BGP MVPN), VPLS multicast, or global table
   multicast over MPLS.

   The primary use case of such segmented P2MP service LSPs is when the
   Provider Edge (PE) routers are in different areas but in the same
   Autonomous System (AS) and thousands or more of PEs require P2MP
   connectivity.  For instance, this may be the case when MPLS is pushed
   further to the metro edge and the metros are in different IGP areas.
   This may also be the case when a service provider's network comprises
   multiple IGP areas in a single AS, with a large number of PEs.
   Seamless MPLS is the industry term to address this case
   [<a href="#ref-SEAMLESS-MPLS">SEAMLESS-MPLS</a>].  Thus, one of the applicabilities of this document
   is that it describes the multicast procedures for seamless MPLS.

   It is to be noted that [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] and [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>] already specify
   procedures for building segmented inter-AS P2MP service LSPs.  This
   document complements those procedures, as it extends the segmented
   P2MP LSP model such that it is applicable to inter-area P2MP service
   LSPs as well.  In fact, an inter-AS deployment could use inter-AS
   segmented P2MP LSPs as specified in [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] and [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>] where
   each intra-AS segment is constructed using inter-area segmented P2MP
   LSPs, as specified in this document.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Specification of Requirements</span>

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].










<span class="grey">Rekhter, et al.              Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  General Assumptions and Terminology</span>

   The reader is assumed to be familiar with MVPN procedures and
   terminology [<a href="./rfc6513" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">RFC6513</a>] [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] and VPLS procedures and terminology
   [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>].

   This document allows Area Border Routers (ABRs), acting as Route
   Reflectors, to follow the procedures specified in [<a href="#ref-SEAMLESS-MPLS">SEAMLESS-MPLS</a>]
   when handling the BGP Next Hop of the routes to the PEs.
   Specifically, when reflecting such routes from the non-backbone areas
   into the backbone area, the ABRs MUST set the BGP Next Hop to their
   own loopback addresses (next-hop-self), while when reflecting such
   routes from the backbone area into the non-backbone areas, the ABRs
   SHOULD NOT change the BGP Next Hop addresses (next-hop-unchanged).

   While this document allows ABRs to follow the procedures specified in
   [<a href="#ref-SEAMLESS-MPLS">SEAMLESS-MPLS</a>], procedures specified in this document are applicable
   even when ABRs do not follow the procedures specified in
   [<a href="#ref-SEAMLESS-MPLS">SEAMLESS-MPLS</a>].

   This document specifies a particular way of supporting the global
   table multicast service.  Although the document refers to this
   approach simply as "global table multicast", it does not mean to
   imply that there are no other ways to support global table multicast.

   An alternative way to support global table multicast is to use the
   procedures for MVPN that are specified in [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] and in this
   document.  That alternative is discussed in more detail in [<a href="#ref-GTM" title="&quot;Global Table Multicast with BGP-MVPN Procedures&quot;">GTM</a>].
   However, that alternative is not further considered in the current
   document.

   This document assumes that, in the context of global table multicast,
   ABRs do not carry routes to the destinations external to their own
   AS.  Furthermore, in the context of global table multicast, this
   document assumes that an Autonomous System Border Router (ASBR), when
   re-advertising into Internal BGP (IBGP) routes received from an
   external speaker (received via External BGP (EBGP)), may not change
   the BGP Next Hop to self.

   Within an AS, a P2MP service LSP is partitioned into three segments:
   ingress area segment, backbone area segment, and egress area segment.
   Within each area, a segment is carried over an intra-area P2MP LSP or
   instantiated using ingress replication.

   When intra-area P2MP LSPs are used to instantiate the intra-area
   segments, there could be either 1:1 or n:1 mapping between intra-area
   segments of the inter-area P2MP service LSP and a given intra-area
   P2MP LSP.  The latter is realized using P2MP LSP hierarchy with



<span class="grey">Rekhter, et al.              Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   upstream-assigned labels [<a href="./rfc5331" title="&quot;MPLS Upstream Label Assignment and Context-Specific Label Space&quot;">RFC5331</a>].  For simplicity of presentation,
   we assume that P2MP LSP hierarchy is used even with 1:1 mapping; in
   which case, an Implicit NULL is used as the upstream-assigned label.

   When intra-area segments of the inter-area P2MP service LSP are
   instantiated using ingress replication, multiple such segments may be
   carried in the same P2P RSVP-TE or MP2P LDP LSP.  This can be
   achieved using downstream-assigned labels alone.

   The ingress area segment of a P2MP service LSP is rooted at a PE (or
   at an ASBR in the case where the P2MP service LSP spans multiple
   ASes).  The leaves of this segment are other PEs/ASBRs and ABRs in
   the same area as the root PE.

   The backbone area segment is rooted at either an ABR that is
   connected to the ingress area (ingress ABR), an ASBR if the ASBR is
   present in the backbone area, or a PE if the PE is present in the
   backbone area.  The backbone area segment has its leaf ABRs that are
   connected to the egress area(s) or PEs in the backbone area, or ASBRs
   in the backbone area.

   The egress area segment is rooted at an ABR in the egress area
   (egress ABR), and has its leaf PEs and ASBR in that egress area (the
   latter covers the case where the P2MP service LSP spans multiple
   ASes).  For a given P2MP service LSP, note that there may be more
   than one backbone segment, each rooted at its own ingress ABR, and
   more than one egress area segment, each rooted at its own egress ABR.

   This document uses the term "A-D routes" for "auto-discovery routes".

   An implementation that supports this document MUST implement the
   procedures described in the following sections to support inter-area
   P2MP segmented service LSPs.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Inter-Area P2MP Segmented Next-Hop Extended Community</span>

   This document defines a new Transitive IPv4-Address-Specific Extended
   Community Sub-Type: "Inter-Area P2MP Next-Hop".  This document also
   defines a new BGP Transitive IPv6-Address-Specific Extended Community
   Sub-Type: "Inter-Area P2MP Next-Hop".











<span class="grey">Rekhter, et al.              Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   A PE, an ABR, or an ASBR constructs the Inter-Area P2MP Segmented
   Next-Hop Extended Community as follows:

   -  The Global Administrator field MUST be set to an IP address of the
      PE, ABR, or ASBR that originates or advertises the route carrying
      the P2MP Next-Hop Extended Community.  For example this address
      may be the loopback address or the PE, ABR, or ASBR that
      advertises the route.

   -  The Local Administrator field MUST be set to 0.

      If the Global Administrator field is an IPv4 address, the
      IPv4-Address-Specific Extended Community is used; if the Global
      Administrator field is an IPv6 address, the IPv6-Address-Specific
      Extended Community is used.

      The detailed usage of these Extended Communities is described in
      the following sections.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Discovering P2MP FEC of Inter-Area P2MP Service LSP</span>

   Each inter-area P2MP service LSP has associated with it P2MP
   Forwarding Equivalence Class (FEC).  The egress PEs need to learn
   this P2MP FEC in order to initiate the creation of the egress area
   segment of the P2MP inter-area service LSP.

   The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs
   either by configuration or based on the application-specific
   procedures (e.g., MVPN-specific procedures or VPLS-specific
   procedures).

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  BGP MVPN</span>

   Egress PEs and/or ASBRs discover the P2MP FEC of the service LSPs
   used by BGP MVPN using the Inclusive Provider Multicast Service
   Interface (I-PMSI) or Selective PMSI (S-PMSI) A-D routes that are
   originated by the ingress PEs or ASBRs following the procedures of
   [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>], along with modifications as described in this document.
   The Network Layer Reachability Information (NLRI) of such routes
   encodes the P2MP FEC.

   The procedures in this document require that at least one ABR in a
   given IGP area act as a Route Reflector for MVPN A-D routes.  Such a
   Router Reflector is responsible for re-advertising MVPN A-D routes
   across area boundaries.  When re-advertising these routes across area
   boundaries, this Route Reflector MUST follow the procedures in this





<span class="grey">Rekhter, et al.              Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   document.  Note that such a Route Reflector may also re-advertise
   MVPN A-D routes within the same area; in which case, it follows the
   plain BGP Route Reflector procedures [<a href="./rfc4456" title="&quot;BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)&quot;">RFC4456</a>].

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Routes Originated by PE or ASBR</span>

   The "Leaf Information Required" flag MUST be set in the PMSI Tunnel
   attribute carried in the MVPN A-D routes, when originated by the
   ingress PEs or ASBRs, except for the case where (a) as a matter of
   policy (provisioned on the ingress PEs or ASBRs) there is no
   aggregation of ingress area segments of the service LSPs and (b) mLDP
   is used as the protocol to establish intra-area transport LSPs in the
   ingress area.  Before any Leaf A-D route is advertised by a PE or ABR
   in the same area, as described in the following sections, an
   I-PMSI/S-PMSI A-D route is advertised either with an explicit Tunnel
   Type and Tunnel Identifier in the PMSI Tunnel attribute, if the
   Tunnel Identifier has already been assigned, or with a special Tunnel
   Type of "No tunnel information present" otherwise.

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  Routes Re-advertised by PE or ASBR</span>

   When the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress
   ABR, the "Leaf Information Required" flag MUST be set in the PMSI
   Tunnel attribute present in the routes, except for the case where
   (a) as a matter of policy (provisioned on the ingress ABR) there is
   no aggregation of backbone area segments of the service LSPs and
   (b) mLDP is used as the protocol to establish intra-area transport
   LSPs in the backbone area.  Likewise, when the I-PMSI/S-PMSI A-D
   routes are re-advertised by an egress ABR, the "Leaf Information
   Required" flag MUST be set in the PMSI Tunnel attribute present in
   the routes, except for the case where (a) as a matter of policy
   (provisioned on the egress ABR) there is no aggregation of egress
   area segments of the service LSPs and (b) mLDP is used as the
   protocol to establish intra-area transport LSPs in the egress area.

   Note that the procedures in the above paragraph apply when intra-area
   segments are realized by either intra-area P2MP LSPs or by ingress
   replication.

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Inter-Area Routes</span>

   When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or
   propagated to signal inter-area P2MP service LSPs, to indicate that
   these LSPs should be segmented using the procedures specified in this
   document, these routes MUST carry the Inter-Area P2MP Segmented
   Next-Hop Extended Community.  This Extended Community MUST be
   included in the I-PMSI/S-PMSI A-D route by the PE that originates
   such a route, or an ASBR that re-advertises such a route into its own



<span class="grey">Rekhter, et al.              Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   AS.  The Global Administrator field in this Extended Community MUST
   be set to the advertising PE or ASBR's IP address.  This Extended
   Community MUST also be included by ABRs as they re-advertise such
   routes.  An ABR MUST set the Global Administrator field of the Inter-
   Area P2MP Segmented Next-Hop Extended Community to its own IP
   address.  Presence of this Extended Community in the I-PMSI/S-PMSI
   A-D routes indicates to ABRs and PEs/ASBRs that they have to follow
   the procedures in this document when these procedures differ from
   those in [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>].

   If an ASBR receives from an IBGP peer an I-PMSI or S-PMSI A-D route
   that carries the Inter-Area P2MP Segmented Next-Hop Extended
   Community, then before re-advertising this route to an EBGP peer, the
   ASBR SHOULD remove this Extended Community from the route.

   Suppose an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP
   peer, and this route carries the Inter-Area P2MP Segmented Next-Hop
   Extended Community.  If the inter-area P2MP service LSP signaled by
   this route should not be segmented, then before re-advertising this
   route to its IBGP peers, the ASBR MUST remove this Extended Community
   from the route.

   To avoid requiring ABRs to participate in the propagation of
   C-multicast routes, this document requires that ABRs MUST NOT modify
   the BGP Next Hop when re-advertising Inter-AS I-PMSI A-D routes.  For
   consistency, this document requires that ABRs MUST NOT modify the BGP
   Next Hop when re-advertising either Intra-AS or Inter-AS
   I-PMSI/S-PMSI A-D routes.  The egress PEs may advertise the
   C-multicast routes to RRs that are different than the ABRs.  However,
   ABRs can still be configured to be the Route Reflectors for
   C-multicast routes; in which case, they will participate in the
   propagation of C-multicast routes.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  LDP VPLS with BGP Auto-discovery or BGP VPLS</span>

   Egress PEs discover the P2MP FEC of the service LSPs used by VPLS,
   using the VPLS A-D routes that are originated by the ingress PEs
   [<a href="./rfc4761" title="&quot;Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling&quot;">RFC4761</a>] [<a href="./rfc6074" title="&quot;Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)&quot;">RFC6074</a>] or VPLS S-PMSI A-D routes that are originated by
   the ingress PEs [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>].  The NLRI of such routes encodes the
   P2MP FEC.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Routes Originated by PE or ASBR</span>

   The "Leaf Information Required" flag MUST be set in the PMSI Tunnel
   attribute carried in the VPLS A-D routes or VPLS S-PMSI A-D routes,
   when originated by the ingress PEs or ASBRs, except for the case
   where (a) as a matter of policy (provisioned on the ingress PEs or
   ASBRs) there is no aggregation of ingress area segments of the



<span class="grey">Rekhter, et al.              Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   service LSPs and (b) mLDP is used as the protocol to establish intra-
   area transport LSPs in the ingress area.  Before any Leaf A-D route
   is advertised by a PE or ABR in the same area, as described in the
   following sections, a VPLS/S-PMSI A-D route is advertised either with
   an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel
   attribute, if the Tunnel Identifier has already been assigned, or
   with a special Tunnel Type of "No tunnel information present"
   otherwise.

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  Routes Re-advertised by PE or ASBR</span>

   When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR,
   the "Leaf Information Required" flag MUST be set in the PMSI Tunnel
   attribute present in the routes, except for the case where (a) as a
   matter of policy (provisioned on the ingress ABR) there is no
   aggregation of backbone area segments of the service LSPs and (b)
   mLDP is used as the protocol to establish intra-area transport LSPs
   in the backbone area.  Likewise, when the VPLS/S-PMSI A-D routes are
   re-advertised by an egress ABR, the "Leaf Information Required" flag
   MUST be set in the PMSI Tunnel attribute present in the routes,
   except for the case where (a) as a matter of policy (provisioned on
   the egress ABR) there is no aggregation of egress area segments of
   the service LSPs and (b) mLDP is used as the protocol to establish
   intra-area transport LSPs in the egress area.

<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>.  Inter-Area Routes</span>

   When VPLS A-D routes or S-PMSI A-D routes are advertised or
   propagated to signal inter-area P2MP service LSPs, to indicate that
   these LSPs should be segmented using the procedures specified in this
   document, these routes MUST carry the Inter-Area P2MP Segmented
   Next-Hop Extended Community.  This Extended Community MUST be
   included in the A-D route by the PE or ASBR that originates such a
   route, and the Global Administrator field MUST be set to the
   advertising PE or ASBR's IP address.  This Extended Community MUST
   also be included by ABRs as they re-advertise such routes.  An ABR
   MUST set the Global Administrator field of the Inter-Area P2MP
   Segmented Next-Hop Extended Community to its own IP address.
   Presence of this Extended Community in the I-PMSI/S-PMSI A-D routes
   indicates to ABRs and PEs/ASBRs that they have to follow the
   procedures in this document when these procedures differ from those
   in [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>].

   Note that the procedures in the above paragraph apply when intra-area
   segments are realized by either intra-area P2MP LSPs or by ingress
   replication.





<span class="grey">Rekhter, et al.              Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   The procedures in this document require that at least one ABR in a
   given area act as a Route Reflector for VPLS A-D routes.  Such a
   Router Reflector is responsible for re-advertising VPLS A-D routes
   across areas boundaries.  When re-advertising these routes across
   areas boundaries, this Route Reflector MUST follow the procedures
   in this document.  Note that such a Route Reflector may also
   re-advertise VPLS A-D routes within the same area; in which case,
   it follows plain BGP Route Reflector procedures [<a href="./rfc4456" title="&quot;BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)&quot;">RFC4456</a>].

   When re-advertising VPLS A-D routes, a Route Reflector MUST NOT
   modify the BGP Next Hop of these routes.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Global Table Multicast over MPLS</span>

   This section describes how the egress PEs discover the P2MP FEC when
   the application is global table multicast over an MPLS-capable
   infrastructure.  In the rest of the document, we will refer to this
   application as "global table multicast".

   When Protocol Independent Multicast - Sparse Mode (PIM-SM) is used
   for non-bidirectional ASM ("Any Source Multicast") group addresses,
   this document refers to this as "PIM-SM in ASM mode".

   In the case where global table multicast uses PIM-SM in ASM mode, the
   following assumes that an inter-area P2MP service LSP could be used
   to carry traffic either on a shared (*,G) or a source (S,G) tree.

   An egress PE learns the (S/*,G) of a multicast stream as a result of
   receiving IGMP or PIM messages on one of its IP multicast interfaces.
   This (S/*,G) forms the P2MP FEC of the inter-area P2MP service LSP.
   For each such P2MP FEC, there MAY exist a distinct inter-area P2MP
   service LSP, or multiple such FECs MAY be carried over a single P2MP
   service LSP using a wildcard (*,*) S-PMSI [<a href="./rfc6625" title="&quot;Wildcards in Multicast VPN Auto-Discovery Routes&quot;">RFC6625</a>].

   Note that this document does not require the use of (*,G) inter-area
   P2MP service LSPs when global table multicast uses PIM-SM in ASM
   mode.  In fact, PIM-SM in ASM mode may be supported entirely by using
   only (S,G) inter-area P2MP service LSPs.













<span class="grey">Rekhter, et al.              Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Egress PE/ASBR Signaling Procedures</span>

   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 ([<a href="./rfc4360" title="&quot;BGP Extended Communities Attribute&quot;">RFC4360</a>]) 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.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Determining the Upstream ABR/PE/ASBR (Upstream Node)</span>

   An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP
   segmented service LSP as described in <a href="#section-5">Section 5</a>.  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.

<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>.  Upstream Node for MVPN or VPLS</span>

   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 <a href="#section-5">Section 5</a>, 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.




<span class="grey">Rekhter, et al.              Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>.  Upstream Node for Global Table Multicast</span>

   If the application is global table multicast, then the unicast routes
   to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended
   Community [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] 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
   [<a href="#ref-SEAMLESS-MPLS">SEAMLESS-MPLS</a>].

   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.









<span class="grey">Rekhter, et al.              Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Originating a Leaf A-D Route</span>

   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.

<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>.  Leaf A-D Route for MVPN and VPLS</span>

   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 [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>].

<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>.  Leaf A-D Route for Global Table Multicast</span>

   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
   <a href="#section-6.1">Section 6.1</a>.




<span class="grey">Rekhter, et al.              Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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



<span class="grey">Rekhter, et al.              Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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
   <a href="./rfc4760#section-7">Section&nbsp;7 of [RFC4760]</a>.

<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>.  Constructing the Rest of the Leaf A-D Route</span>

   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 <a href="#section-6.1">Section 6.1</a>.

   The PE then advertises this route to the upstream node.






<span class="grey">Rekhter, et al.              Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  PIM-SM in ASM Mode for Global Table Multicast</span>

   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.

<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>.  Option 1</span>

   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.

<span class="h5"><a class="selflink" id="section-6.3.1.1" href="#section-6.3.1.1">6.3.1.1</a>.  Originating Source Active A-D Routes</span>

   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
   ([<a href="./rfc1997" title="&quot;BGP Communities Attribute&quot;">RFC1997</a>]).

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





<span class="grey">Rekhter, et al.              Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h5"><a class="selflink" id="section-6.3.1.2" href="#section-6.3.1.2">6.3.1.2</a>.  Receiving BGP Source Active A-D Route by PE</span>

   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 <a href="#section-6.2.2">Section 6.2.2</a>.

   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 <a href="#section-6.2.2">Section 6.2.2</a>.

<span class="h5"><a class="selflink" id="section-6.3.1.3" href="#section-6.3.1.3">6.3.1.3</a>.  Handling (S,G,rpt) State</span>

   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.

<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>.  Option 2</span>

   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.

<span class="h5"><a class="selflink" id="section-6.3.2.1" href="#section-6.3.2.1">6.3.2.1</a>.  Originating Source Active A-D Routes</span>

   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.





<span class="grey">Rekhter, et al.              Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   + 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
   [<a href="./rfc1997" title="&quot;BGP Communities Attribute&quot;">RFC1997</a>].

   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.

<span class="h5"><a class="selflink" id="section-6.3.2.2" href="#section-6.3.2.2">6.3.2.2</a>.  Receiving BGP Source Active A-D Route</span>

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

<span class="h5"><a class="selflink" id="section-6.3.2.3" href="#section-6.3.2.3">6.3.2.3</a>.  Pruning Sources Off the Shared Tree</span>

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




<span class="grey">Rekhter, et al.              Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h5"><a class="selflink" id="section-6.3.2.4" href="#section-6.3.2.4">6.3.2.4</a>.  More on Handling (S,G,rpt) State</span>

   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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Egress ABR Procedures</span>

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

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Handling Leaf A-D Route on Egress ABR</span>

   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 <a href="#section-6.2.2">Section 6.2.2</a>).  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.






<span class="grey">Rekhter, et al.              Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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 [<a href="./rfc4684" title="&quot;Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)&quot;">RFC4684</a>] 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.






<span class="grey">Rekhter, et al.              Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  P2MP LSP as the Intra-Area LSP in the Egress Area</span>

   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.

<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>.  Received Leaf A-D Route Is for MVPN or VPLS</span>

   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 <a href="#section-6.2.2">Section 6.2.2</a>).  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



<span class="grey">Rekhter, et al.              Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   "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 [<a href="./rfc5332" title="&quot;MPLS Multicast Encapsulations&quot;">RFC5332</a>].

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

<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>.  Received Leaf A-D Route Is for Global Table Multicast</span>

   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.

<span class="h5"><a class="selflink" id="section-7.2.2.1" href="#section-7.2.2.1">7.2.2.1</a>.  Global Table Multicast and S-PMSI A-D Routes</span>

   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 <a href="#section-9.1">Section 9.1</a>), 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 <a href="#section-3">Section 3</a>).  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 <a href="#section-4">Section 4</a>.

   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.



<span class="grey">Rekhter, et al.              Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h5"><a class="selflink" id="section-7.2.2.2" href="#section-7.2.2.2">7.2.2.2</a>.  Global Table Multicast and Wildcard S-PMSI A-D Routes</span>

   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 [<a href="./rfc6625" title="&quot;Wildcards in Multicast VPN Auto-Discovery Routes&quot;">RFC6625</a>].  An ingress PE MAY advertise a
   wildcard S-PMSI A-D route as described in <a href="#section-9">Section 9</a>.

   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 <a href="#section-3">Section 3</a>) 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.

<span class="h4"><a class="selflink" id="section-7.2.3" href="#section-7.2.3">7.2.3</a>.  Global Table Multicast and the Expected Upstream Node</span>

   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



<span class="grey">Rekhter, et al.              Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h4"><a class="selflink" id="section-7.2.4" href="#section-7.2.4">7.2.4</a>.  P2MP LDP LSP as the Intra-Area P2MP LSP</span>

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

<span class="h4"><a class="selflink" id="section-7.2.5" href="#section-7.2.5">7.2.5</a>.  P2MP RSVP-TE LSP as the Intra-Area P2MP LSP</span>

   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 <a href="#section-7.2.2">Section 7.2.2</a>.

   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.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  Ingress Replication in the Egress Area</span>

   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.





<span class="grey">Rekhter, et al.              Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


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

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Ingress ABR Procedures</span>

   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 <a href="#section-7">Section</a>
   <a href="#section-7">7</a>, 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.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  P2MP LSP as the Intra-Area LSP in the Backbone Area</span>

   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 <a href="#section-7">7</a> and <a href="#section-7.2">7.2</a>, 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.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Ingress Replication in the Backbone Area</span>

   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.



<span class="grey">Rekhter, et al.              Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   The top label is the P2P RSVP-TE or the MP2P LDP label to reach the
   egress ABR.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Ingress PE/ASBR Procedures</span>

   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 <a href="#section-6.2.2">Section 6.2.2</a>).  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).

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  P2MP LSP as the Intra-Area LSP in the Ingress Area</span>

   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 <a href="#section-7">7</a> and <a href="#section-7.2">7.2</a>.

   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.




<span class="grey">Rekhter, et al.              Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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
   [<a href="./rfc6625" title="&quot;Wildcards in Multicast VPN Auto-Discovery Routes&quot;">RFC6625</a>] 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 <a href="#section-4">Section 4</a>.

   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.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Ingress Replication in the Ingress Area</span>

   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.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Common Tunnel Type in the Ingress and Egress Areas</span>

   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




<span class="grey">Rekhter, et al.              Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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 [<a href="./rfc6368" title="&quot;Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC6368</a>], 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 [<a href="./rfc6368" title="&quot;Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)&quot;">RFC6368</a>], 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.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Placement of Ingress and Egress PEs</span>

   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.








<span class="grey">Rekhter, et al.              Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  MVPN with Virtual Hub-and-Spoke</span>

   Procedures described in this document could be used in conjunction
   with the Virtual Hub-and-Spoke procedures [<a href="./rfc7024" title="&quot;Virtual Hub-and-Spoke in BGP/MPLS VPNs&quot;">RFC7024</a>].

   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 <a href="./rfc7024#section-7.8.2">Section&nbsp;7.8.2 of [RFC7024]</a>), 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.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Data Plane</span>

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

<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>.  Data Plane Procedures on ABRs</span>

   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.




<span class="grey">Rekhter, et al.              Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>.  Data Plane Procedures on Egress PEs</span>

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







<span class="grey">Rekhter, et al.              Standards Track                   [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h3"><a class="selflink" id="section-13.3" href="#section-13.3">13.3</a>.  Data Plane Procedures on Ingress PEs</span>

   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.

<span class="h3"><a class="selflink" id="section-13.4" href="#section-13.4">13.4</a>.  Data Plane Procedures on Transit Routers</span>

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

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  Support for Inter-Area Transport LSPs</span>

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

<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>.  "Transport Tunnel" Tunnel Type</span>

   For the PMSI Tunnel attribute, we define a new Tunnel Type, called
   "Transport Tunnel", whose Tunnel Identifier is a tuple &lt;Source PE
   Address, Local Number&gt;.  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.



<span class="grey">Rekhter, et al.              Standards Track                   [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>.  Discovering Leaves of the Inter-Area P2MP Service LSP</span>

   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.

<span class="h3"><a class="selflink" id="section-14.3" href="#section-14.3">14.3</a>.  Discovering P2MP FEC of P2MP Transport LSP</span>

   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.



<span class="grey">Rekhter, et al.              Standards Track                   [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


<span class="h3"><a class="selflink" id="section-14.4" href="#section-14.4">14.4</a>.  Egress PE Procedures for P2MP Transport LSP</span>

   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 [<a href="./rfc6514" title="&quot;BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs&quot;">RFC6514</a>] and
   [<a href="./rfc7117" title="&quot;Multicast in Virtual Private LAN Service (VPLS)&quot;">RFC7117</a>]), 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 <a href="#section-6.2.2">Section 6.2.2</a>.
   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 <a href="#section-6.1">Section 6.1</a> for global table multicast.

   The egress PE constructs the rest of the Leaf A-D route following the
   procedures specified in <a href="#section-6.2.3">Section 6.2.3</a>.

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

<span class="h3"><a class="selflink" id="section-14.5" href="#section-14.5">14.5</a>.  ABRs and Ingress PE Procedures for P2MP Transport LSP</span>

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




<span class="grey">Rekhter, et al.              Standards Track                   [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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 <a href="#section-7.2.2.1">Section</a>
   <a href="#section-7.2.2.1">7.2.2.1</a>.  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 <a href="#section-7.1.2.1">Section 7.1.2.1</a>.  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.

<span class="h3"><a class="selflink" id="section-14.6" href="#section-14.6">14.6</a>.  Discussion</span>

   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.





<span class="grey">Rekhter, et al.              Standards Track                   [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


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




<span class="grey">Rekhter, et al.              Standards Track                   [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   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.

<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>.  IANA Considerations</span>

   This document defines a new BGP Extended Community called "Inter-Area
   P2MP Segmented Next-Hop" (see <a href="#section-4">Section 4</a>).  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 [<a href="./rfc7385" title="&quot;IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points&quot;">RFC7385</a>] as
   "Transport Tunnel" (see <a href="#section-14">Section 14</a>).

   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.

<span class="h2"><a class="selflink" id="section-16" href="#section-16">16</a>.  Security Considerations</span>

   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"



<span class="grey">Rekhter, et al.              Standards Track                   [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   [<a href="./rfc5920" title="&quot;Security Framework for MPLS and GMPLS Networks&quot;">RFC5920</a>], in the mLDP specification [<a href="./rfc6388" title="&quot;Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths&quot;">RFC6388</a>], and in the P2MP
   RSVP-TE specification [<a href="./rfc3209" title="&quot;RSVP-TE: Extensions to RSVP for LSP Tunnels&quot;">RFC3209</a>].  The security considerations of
   [<a href="./rfc6513" title="&quot;Multicast in MPLS/BGP IP VPNs&quot;">RFC6513</a>] are also applicable.

<span class="h2"><a class="selflink" id="section-17" href="#section-17">17</a>.  References</span>

<span class="h3"><a class="selflink" id="section-17.1" href="#section-17.1">17.1</a>.  Normative References</span>

   [<a id="ref-RFC1997">RFC1997</a>]   Chandra, R., Traina, P., and T. Li, "BGP Communities
               Attribute", <a href="./rfc1997">RFC 1997</a>, DOI 10.17487/RFC1997, August 1996,
               &lt;<a href="http://www.rfc-editor.org/info/rfc1997">http://www.rfc-editor.org/info/rfc1997</a>&gt;.

   [<a id="ref-RFC2119">RFC2119</a>]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
               DOI 10.17487/RFC2119, March 1997,
               &lt;<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-RFC3209">RFC3209</a>]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", <a href="./rfc3209">RFC 3209</a>, DOI 10.17487/RFC3209, December 2001,
               &lt;<a href="http://www.rfc-editor.org/info/rfc3209">http://www.rfc-editor.org/info/rfc3209</a>&gt;.

   [<a id="ref-RFC4360">RFC4360</a>]   Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
               Communities Attribute", <a href="./rfc4360">RFC 4360</a>, DOI 10.17487/RFC4360,
               February 2006, &lt;<a href="http://www.rfc-editor.org/info/rfc4360">http://www.rfc-editor.org/info/rfc4360</a>&gt;.

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

   [<a id="ref-RFC4684">RFC4684</a>]   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)", <a href="./rfc4684">RFC 4684</a>, DOI 10.17487/RFC4684,
               November 2006, &lt;<a href="http://www.rfc-editor.org/info/rfc4684">http://www.rfc-editor.org/info/rfc4684</a>&gt;.

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

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




<span class="grey">Rekhter, et al.              Standards Track                   [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   [<a id="ref-RFC4875">RFC4875</a>]   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)", <a href="./rfc4875">RFC 4875</a>,
               DOI 10.17487/RFC4875, May 2007,
               &lt;<a href="http://www.rfc-editor.org/info/rfc4875">http://www.rfc-editor.org/info/rfc4875</a>&gt;.

   [<a id="ref-RFC5036">RFC5036</a>]   Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
               "LDP Specification", <a href="./rfc5036">RFC 5036</a>, DOI 10.17487/RFC5036,
               October 2007, &lt;<a href="http://www.rfc-editor.org/info/rfc5036">http://www.rfc-editor.org/info/rfc5036</a>&gt;.

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

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

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

   [<a id="ref-RFC6368">RFC6368</a>]   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)", <a href="./rfc6368">RFC 6368</a>, DOI 10.17487/RFC6368, September 2011,
               &lt;<a href="http://www.rfc-editor.org/info/rfc6368">http://www.rfc-editor.org/info/rfc6368</a>&gt;.

   [<a id="ref-RFC6388">RFC6388</a>]   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", <a href="./rfc6388">RFC 6388</a>, DOI 10.17487/RFC6388, November
               2011, &lt;<a href="http://www.rfc-editor.org/info/rfc6388">http://www.rfc-editor.org/info/rfc6388</a>&gt;.

   [<a id="ref-RFC6513">RFC6513</a>]   Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
               MPLS/BGP IP VPNs", <a href="./rfc6513">RFC 6513</a>, DOI 10.17487/RFC6513,
               February 2012, &lt;<a href="http://www.rfc-editor.org/info/rfc6513">http://www.rfc-editor.org/info/rfc6513</a>&gt;.

   [<a id="ref-RFC6514">RFC6514</a>]   Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
               Encodings and Procedures for Multicast in MPLS/BGP IP
               VPNs", <a href="./rfc6514">RFC 6514</a>, DOI 10.17487/RFC6514, February 2012,
               &lt;<a href="http://www.rfc-editor.org/info/rfc6514">http://www.rfc-editor.org/info/rfc6514</a>&gt;.




<span class="grey">Rekhter, et al.              Standards Track                   [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


   [<a id="ref-RFC6625">RFC6625</a>]   Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
               Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
               <a href="./rfc6625">RFC 6625</a>, DOI 10.17487/RFC6625, May 2012,
               &lt;<a href="http://www.rfc-editor.org/info/rfc6625">http://www.rfc-editor.org/info/rfc6625</a>&gt;.

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

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

<span class="h3"><a class="selflink" id="section-17.2" href="#section-17.2">17.2</a>.  Informative References</span>

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

   [<a id="ref-RFC5920">RFC5920</a>]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
               Networks", <a href="./rfc5920">RFC 5920</a>, DOI 10.17487/RFC5920, July 2010,
               &lt;<a href="http://www.rfc-editor.org/info/rfc5920">http://www.rfc-editor.org/info/rfc5920</a>&gt;.

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

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

Acknowledgements

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










<span class="grey">Rekhter, et al.              Standards Track                   [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc7524">RFC 7524</a>             Inter-Area P2MP Segmented LSPs             May 2015</span>


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&amp;T
   EMail: samirsaad1@outlook.com









Rekhter, et al.              Standards Track                   [Page 42]
</pre>