idnits 2.17.1 draft-ietf-mpls-seamless-mcast-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 9, 2015) is 3394 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Rekhter 3 Internet Draft Juniper Networks 4 Intended status: Standards Track 5 Expiration Date: July 2015 6 R. Aggarwal 8 T. Morin 9 France Telecom 11 I. Grosclaude 12 France Telecom 14 N. Leymann 15 Deutsche Telekom AG 17 S. Saad 18 AT&T 20 E. Rosen 21 Juniper Networks 23 January 9, 2015 25 Inter-Area P2MP Segmented LSPs 27 draft-ietf-mpls-seamless-mcast-15.txt 29 Abstract 31 This document describes procedures for building inter-area point-to- 32 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 33 into intra-area segments and using BGP as the inter-area routing and 34 label distribution protocol. Within each IGP area the intra-area 35 segments are either carried over intra-area P2MP LSPs, using P2MP LSP 36 hierarchy, or instantiated using ingress replication. The intra-area 37 P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress 38 replication is used within an IGP area, then (multipoint-to-point) 39 LDP LSPs or (point-to-point) RSVP-TE LSPs may be used in the IGP 40 area. The applications/services that use such inter-area service LSPs 41 may be BGP Multicast VPN, VPLS multicast, or global table multicast 42 over MPLS. 44 Status of this Memo 46 This Internet-Draft is submitted to IETF in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF), its areas, and its working groups. Note that other 51 groups may also distribute working documents as Internet-Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt. 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html. 64 Copyright and License Notice 66 Copyright (c) 2014 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 This document may contain material from IETF Documents or IETF 80 Contributions published or made publicly available before November 81 10, 2008. The person(s) controlling the copyright in some of this 82 material may not have granted the IETF Trust the right to allow 83 modifications of such material outside the IETF Standards Process. 84 Without obtaining an adequate license from the person(s) controlling 85 the copyright in such materials, this document may not be modified 86 outside the IETF Standards Process, and derivative works of it may 87 not be created outside the IETF Standards Process, except to format 88 it for publication as an RFC or to translate it into languages other 89 than English. 91 Table of Contents 93 1 Introduction .......................................... 4 94 2 Specification of requirements ......................... 5 95 3 General Assumptions and Terminology ................... 5 96 4 Inter-area P2MP Segmented Next-Hop Extended Community . 7 97 5 Discovering P2MP FEC of Inter-Area P2MP Service LSP ... 8 98 5.1 BGP MVPN .............................................. 8 99 5.1.1 Routes originated by PE or ASBR ....................... 8 100 5.1.2 Routes re-avertise by PE or ASBR ...................... 9 101 5.1.3 Inter-area routes ..................................... 9 102 5.2 LDP VPLS with BGP auto-discovery or BGP VPLS .......... 10 103 5.2.1 Routes originated by PE or ASBR ....................... 10 104 5.2.2 Routes re-avertise by PE or ASBR ...................... 10 105 5.2.3 Inter-area routes ..................................... 11 106 5.3 Global Table Multicast over MPLS ...................... 12 107 6 Egress PE/ASBR Signaling Procedures ................... 12 108 6.1 Determining the Upstream ABR/PE/ASBR (Upstream Node) .. 13 109 6.1.1 Upstream Node for MVPN or VPLS ........................ 13 110 6.1.2 Upstream Node for Global Table Multicast .............. 13 111 6.2 Originating a Leaf A-D Route .......................... 14 112 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 14 113 6.2.2 Leaf A-D Route for Global Table Multicast ............. 15 114 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 17 115 6.3 PIM-SM in ASM mode for Global Table Multicast ......... 17 116 6.3.1 Option 1 .............................................. 17 117 6.3.1.1 Originating Source Active A-D Routes .................. 18 118 6.3.1.2 Receiving BGP Source Active A-D Route by PE ........... 18 119 6.3.1.3 Handling (S, G, rpt) state ............................ 19 120 6.3.2 Option 2 .............................................. 19 121 6.3.2.1 Originating Source Active A-D Routes .................. 19 122 6.3.2.2 Receiving BGP Source Active A-D Route ................. 20 123 6.3.2.3 Pruning Sources off the Shared Tree ................... 20 124 6.3.2.4 More on handling (S, G, rpt) state .................... 21 125 7 Egress ABR Procedures ................................. 21 126 7.1 Handling Leaf A-D route on Egress ABR ................. 21 127 7.2 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 23 128 7.2.1 Received Leaf A-D route is for MVPN or VPLS ........... 23 129 7.2.2 Received Leaf A-D route is for global table multicast . 24 130 7.2.2.1 Global Table Multicast and S-PMSI A-D Routes .......... 24 131 7.2.2.2 Global Table Multicast and Wildcard S-PMSI A-D Routes . 24 132 7.2.3 Global Table Multicast and the Expected Upstream Node . 25 133 7.2.4 P2MP LDP LSP as the Intra-Area P2MP LSP ............... 26 134 7.2.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP ........... 26 135 7.3 Ingress Replication in the Egress Area ................ 26 136 8 Ingress ABR Procedures ................................ 27 137 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 27 138 8.2 Ingress Replication in the Backbone Area .............. 27 139 9 Ingress PE/ASBR Procedures ............................ 28 140 9.1 P2MP LSP as the Intra-Area LSP in the Ingress Area .... 28 141 9.2 Ingress Replication in the Ingress Area ............... 29 142 10 Common Tunnel Type in the Ingress and Egress Areas .... 30 143 11 Placement of Ingress and Egress PEs ................... 30 144 12 MVPN with Virtual Hub-and-Spoke ....................... 31 145 13 Data Plane ............................................ 31 146 13.1 Data Plane Procedures on ABRs ......................... 31 147 13.2 Data Plane Procedures on Egress PEs ................... 32 148 13.3 Data Plane Procedures on Ingress PEs .................. 33 149 13.4 Data Plane Procedures on Transit Routers .............. 33 150 14 Support for Inter-Area Transport LSPs ................. 33 151 14.1 Transport Tunnel Tunnel Type .......................... 34 152 14.2 Discovering Leaves of the Inter-Area P2MP Service LSP . 34 153 14.3 Discovering P2MP FEC of P2MP Transport LSP ............ 34 154 14.4 Egress PE Procedures for P2MP Transport LSP ........... 35 155 14.5 ABRs and Ingress PE procedures for P2MP Transport LSP . 36 156 14.6 Discussion ............................................ 37 157 15 IANA Considerations ................................... 39 158 16 Security Considerations ............................... 39 159 17 Acknowledgements ...................................... 39 160 18 References ............................................ 39 161 18.1 Normative References .................................. 39 162 18.2 Informative References ................................ 41 163 19 Author's Address ...................................... 41 165 1. Introduction 167 This document describes procedures for building inter-area point-to- 168 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 169 into intra-area segments and using BGP as the inter-area routing and 170 label distribution protocol. Within each IGP area the intra-area 171 segments are either carried over intra-area P2MP LSPs, potentially 172 using P2MP LSP hierarchy, or instantiated using ingress replication. 173 The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE [RFC4875] 174 or P2MP mLDP [RFC6388]. If ingress replication is used in an IGP area 175 then (multipoint-to-point) LDP LSPs [RFC5036] or (point-to-point) 176 RSVP-TE LSPs [RFC3209] may be used within the IGP area. The 177 applications/services that use such inter-area service LSPs may be 178 BGP Multicast VPN (BGP MVPN), VPLS multicast, or global table 179 multicast over MPLS. 181 The primary use case of such segmented P2MP service LSPs is when the 182 PEs are in different areas but in the same AS and thousands or more 183 of PEs require P2MP connectivity. For instance this may be the case 184 when MPLS is pushed further to the metro edge and the metros are in 185 different IGP areas. This may also be the case when a Service 186 Provider's network comprises multiple IGP areas in a single 187 Autonomous System, with a large number of PEs. Seamless MPLS is the 188 industry term to address this case [SEAMLESS-MPLS]. Thus one of the 189 applicabilities of this document is that it describes the multicast 190 procedures for seamless MPLS. 192 It is to be noted that [RFC6514] and [RFC7117] already specify 193 procedures for building segmented inter-AS P2MP service LSPs. This 194 document complements those procedures, as it extends the segmented 195 P2MP LSP model such that it is applicable to inter-area P2MP service 196 LSPs as well. In fact an inter-AS deployment could use inter-AS 197 segmented P2MP LSPs as specified in [RFC6514, RFC7117] where each 198 intra-AS segment is constructed using inter-area segmented P2MP LSPs 199 as specified in this document. 201 2. Specification of requirements 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 3. General Assumptions and Terminology 209 The reader is suppose to be familiar with MVPN procedures and 210 terminology [RFC6513, RFC6514] and VPLS procedures and terminology 211 [RFC7117]. 213 This document allows ABRs, acting as Route Reflectors, to follow the 214 procedures specified in [SEAMLESS-MPLS] when handling BGP Next Hop of 215 the routes to the PEs. Specifically, when reflecting such routes from 216 the non-backbone areas into the backbone area, the ABRs MUST set BGP 217 Next Hop to their own loopback addresses (next-hop-self), while when 218 reflecting such routes from the backbone area into the non-backbone 219 areas, the ABRs SHOULD NOT change the BGP Next Hop addresses (next- 220 hop-unchanged). 222 While this document allows ABRs to follow the procedures specified in 224 [SEAMLESS-MPLS], procedures specified in this document are applicable 225 even when ABRs do not follow the procedures specified in [SEAMLESS- 226 MPLS]. 228 One possible way to support the global table multicast service is by 229 relying on the MVPN procedures, as specified in [RFC6514], in which 230 case the MVPN procedures specified in this document would be used to 231 support the global table multicast service. This document specifies 232 an alternative approach to support the global table multicast 233 service. This document refers to this approach as "global table 234 multicast" (although this by no means imply that this alternative 235 approach is the only way to support the global table multicast 236 service). 238 This document assumes that in the context of global table multicast 239 ABRs do not carry routes to the destinations external to their own 240 AS. Furthermore, in the context of global table multicast this 241 document assumes that an ASBR, when re-advertising into IBGP routes 242 received from an external speaker (received via EBGP) may not change 243 BGP Next Hop to self. 245 Within an AS a P2MP service LSP is partitioned into 3 segments: 246 ingress area segment, backbone area segment, and egress area segment. 247 Within each area a segment is carried over an intra-area P2MP LSP or 248 instantiated using ingress replication. 250 When intra-area P2MP LSPs are used to instantiate the intra-area 251 segments there could be either 1:1 or n:1 mapping between intra-area 252 segments of the inter-area P2MP service LSP and a given intra-area 253 P2MP LSP. The latter is realized using P2MP LSP hierarchy with 254 upstream-assigned labels [RFC5331]. For simplicity of presentation we 255 assume that P2MP LSP hierarchy is used even with 1:1 mapping, in 256 which case an Implicit NULL is used as the upstream-assigned label. 258 When intra-area segments of the inter-area P2MP service LSP are 259 instantiated using ingress replication, then multiple such segments 260 may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be 261 achieved using downstream-assigned labels alone. 263 The ingress area segment of a P2MP service LSP is rooted at a PE (or 264 at an ASBR in the case where the P2MP service LSP spans multiple 265 ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the 266 same area as the root PE. 268 The backbone area segment is rooted at an ABR that is connected to 269 the ingress area (ingress ABR), or at an ASBR if the ASBR is present 270 in the backbone area, or at a PE if the PE is present in the backbone 271 area. The backbone area segment has its leaves ABRs that are 272 connected to the egress area(s) or PEs in the backbone area, or ASBRs 273 in the backbone area. 275 The egress area segment is rooted at an ABR in the egress area 276 (egress ABR), and has its leaves PEs and ASBR in that egress area 277 (the latter covers the case where the P2MP service LSP spans multiple 278 ASes). Note that for a given P2MP service LSP there may be more than 279 one backbone segment, each rooted at its own ingress ABR, and more 280 than one egress area segment, each rooted at its own egress ABR. 282 This document uses the term "A-D routes" for "auto-discovery routes". 284 An implementation that supports this document MUST implement the 285 procedures described in the following sections to support inter-area 286 point-to-multipoint (P2MP) segmented service LSPs. 288 4. Inter-area P2MP Segmented Next-Hop Extended Community 290 This document defines a new BGP Extended Community "Inter-area P2MP 291 Next-Hop" Extended Community. This is an IP-address specific Extended 292 Community of an extended type and is transitive across AS boundaries 293 [RFC4360]. 295 A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented 296 Next-Hop Extended Community as follows: 298 - The Global Administrator field MUST be set to an IP address of 299 the PE or ASBR or ABR that originates or advertises the route, 300 which carries the P2MP Next-Hop Extended Community. For example 301 this address may be the loopback address or the PE, ASBR or ABR 302 that advertises the route. 304 - The Local Administrator field MUST be set to 0. 306 The detailed usage of this Extended Community is described in the 307 following sections. 309 5. Discovering P2MP FEC of Inter-Area P2MP Service LSP 311 Each inter-area P2MP service LSP has associated with it P2MP FEC. 312 The egress PEs need to learn this P2MP FEC in order to initiate the 313 creation of the egress area segment of the P2MP inter-area service 314 LSP. 316 The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs 317 either by configuration, or based on the application-specific 318 procedures (e.g., MVPN-specific procedures, VPLS-specific 319 procedures). 321 5.1. BGP MVPN 323 Egress PEs and/or ASBRs discover the P2MP FEC of the service LSPs 324 used by BGP MVPN using the I-PMSI or S-PMSI A-D routes that are 325 originated by the ingress PEs or ASBRs following the procedures of 326 [RFC6514], along with modifications as described in this document. 327 The NLRI of such routes encodes the P2MP FEC. 329 The procedures in this document require that at least one ABR in a 330 given IGP area acts as a Route Reflector for MVPN A-D routes. Such a 331 Router Reflector is responsible for re-advertising MVPN A-D routes 332 across area's boundaries. When re-advertising these routes across 333 area's boundaries, this Route Reflector MUST follow the procedures in 334 this document. Note that such a Route Reflector may also re-advertise 335 MVPN A-D routes within the same area, in which case it follows the 336 plain BGP Route Reflector procedures [RFC4456]. 338 5.1.1. Routes originated by PE or ASBR 340 The "Leaf Information Required" flag MUST be set in the PMSI Tunnel 341 attribute carried in the MVPN A-D routes, when originated by the 342 ingress PEs or ASBRs, except for the case where (a) as a matter of 343 policy (provisioned on the ingress PEs or ASBRs) there is no 344 aggregation of ingress area segments of the service LSPs, and (b) 345 mLDP is used as the protocol to establish intra-area transport LSPs 346 in the ingress area. Before any Leaf A-D route is advertised by a PE 347 or ABR in the same area, as described in the following sections, an 348 I-PMSI/S-PMSI A-D route is advertised either with an explicit Tunnel 349 Type and Tunnel Identifier in the PMSI Tunnel Attribute, if the 350 Tunnel Identifier has already been assigned, or with a special Tunnel 351 Type of "No tunnel information present" otherwise. 353 5.1.2. Routes re-avertise by PE or ASBR 355 When the I-PMSI/S-PMSI A-D routes are re-advertised by an ingress 356 ABR, the "Leaf Information Required" flag MUST be set in the P-Tunnel 357 attribute present in the routes, except for the case where (a) as a 358 matter of policy (provisioned on the ingress ABR) there is no 359 aggregation of backbone area segments of the service LSPs, and (b) 360 mLDP is used as the protocol to establish intra-area transport LSPs 361 in the backbone area. Likewise, when the I-PMSI/S-PMSI A-D routes are 362 re-advertised by an egress ABR, the "Leaf Information Required" flag 363 MUST be set in the P-Tunnel attribute present in the routes, except 364 for the case where (a) as a matter of policy (provisioned on the 365 egress ABR) there is no aggregation of egress area segments of the 366 service LSPs, and (b) mLDP is used as the protocol to establish 367 intra-area transport LSPs in the egress area. 369 Note that the procedures in the above paragraph apply when intra-area 370 segments are realized by either intra-area P2MP LSPs or by ingress 371 replication. 373 5.1.3. Inter-area routes 375 When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or 376 propagated to signal Inter-area P2MP service LSPs, to indicate that 377 these LSPs should be segmented using the procedures specified in this 378 document, these routes MUST carry the Inter-area P2MP Segmented Next- 379 Hop Extended Community. This Extended Community MUST be included in 380 the I-PMSI/S-PMSI A-D route by the PE that originates such a route, 381 or an ASBR that re-advertises such a route into its own AS. The 382 Global Administrator field in this Extended Community MUST be set to 383 the advertising PE or ASBR's IP address. This Extended Community MUST 384 also be included by ABRs as they re-advertise such routes. An ABR 385 MUST set the Global Administrator field of the P2MP Segmented Next- 386 Hop Extended Community to its own IP address. Presence of this 387 community in the I-PMSI/S-PMSI A-D routes indicates to ABRs and 388 PEs/ASBRs that they have to follow the procedures in this document 389 when these procedures differ from those in [RFC6514]. 391 If an ASBR receives from an IBGP peer an I-PMSI or S-PMSI A-D route 392 that carries the Inter-area P2MP Segmented Next-Hop Extended 393 Community, then before re-advertising this route to an EBGP peer the 394 ASBR SHOULD remove this Community from the route. 396 If an ASBR receives an I-PMSI/S-PMSI A-D route from an EBGP peer, and 397 this route does carry the Inter-area P2MP Segmented Next-Hop Extended 398 Community, if the inter-area P2MP service LSP signalled by this route 399 should not be segmented, then before re-advertising this route to its 400 IBGP peers the ASBR MUST remove this community from the route. 402 To avoid requiring ABRs to participate in the propagation of C- 403 multicast routes, this document requires ABRs NOT to modify BGP Next 404 Hop when re-advertising Inter-AS I-PMSI A-D routes. For consistency 405 this document requires ABRs to NOT modify BGP Next Hop when re- 406 advertising both Intra-AS and Inter-AS I-PMSI/S-PMSI A-D routes. The 407 egress PEs may advertise the C-multicast routes to RRs that are 408 different than the ABRs. However ABRs still can be configured to be 409 the Route Reflectors for C-multicast routes, in which case they will 410 participate in the propagation of C-multicast routes. 412 5.2. LDP VPLS with BGP auto-discovery or BGP VPLS 414 Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, 415 using the VPLS A-D routes that are originated by the ingress PEs 416 [RFC4761, RFC6074], or VPLS S-PMSI A-D routes that are originated by 417 the ingress PEs [RFC7117]. The NLRI of such routes encodes the P2MP 418 FEC. 420 5.2.1. Routes originated by PE or ASBR 422 The "Leaf Information Required" flag MUST be set in the P-Tunnel 423 attribute carried in the VPLS A-D routes or VPLS S-PMSI A-D routes, 424 when originated by the ingress PEs or ASBRs, except for the case 425 where (a) as a matter of policy (provisioned on the ingress PEs or 426 ASBRs) there is no aggregation of ingress area segments of the 427 service LSPs, and (b) mLDP is used as the protocol to establish 428 intra-area transport LSPs in the ingress area. Before any Leaf A-D 429 route is advertised by a PE or ABR in the same area, as described in 430 the following sections, an VPLS/S-PMSI A-D route is advertised either 431 with an explicit Tunnel Type and Tunnel Identifier in the PMSI Tunnel 432 Attribute, if the Tunnel Identifier has already been assigned, or 433 with a special Tunnel Type of "No tunnel information present" 434 otherwise. 436 5.2.2. Routes re-avertise by PE or ASBR 438 When the VPLS/S-PMSI A-D routes are re-advertised by an ingress ABR, 439 the "Leaf Information Required" flag MUST be set in the P-Tunnel 440 attribute present in the routes, except for the case where (a) as a 441 matter of policy (provisioned on the ingress ABR) there is no 442 aggregation of backbone area segments of the service LSPs, and (b) 443 mLDP is used as the protocol to establish intra-area transport LSPs 444 in the backbone area. Likewise, when the VPLS/S-PMSI A-D routes are 445 re-advertised by an egress ABR, the "Leaf Information Required" flag 446 MUST be set in the P-Tunnel attribute present in the routes, except 447 for the case where (a) as a matter of policy (provisioned on the 448 egress ABR) there is no aggregation of egress area segments of the 449 service LSPs, and (b) mLDP is used as the protocol to establish 450 intra-area transport LSPs in the egress area. 452 5.2.3. Inter-area routes 454 When VPLS A-D routes or S-PMSI A-D routes are advertised or 455 propagated to signal Inter-area P2MP service LSPs, to indicate that 456 these LSPs should be segmented using the procedures specified in this 457 document, these routes MUST carry the Inter-area P2MP Segmented Next- 458 Hop Extended Community. This Extended Community MUST be included in 459 the A-D route by the PE or ASBR that originates such a route and the 460 Global Administrator field MUST be set to the advertising PE or 461 ASBR's IP address. This Extended Community MUST also be included by 462 ABRs as they re-advertise such routes. An ABR MUST set the Global 463 Administrator field of the P2MP Segmented Next-Hop Extended Community 464 to its own IP address. Presence of this community in the I-PMSI/S- 465 PMSI A-D routes indicates to ABRs and PEs/ASBRs that they have to 466 follow the procedures in this document when these procedures differ 467 from those in [RFC7117]. 469 Note that the procedures in the above paragraph apply when intra-area 470 segments are realized by either intra-area P2MP LSPs or by ingress 471 replication. 473 The procedures in this document require that at least one ABR in a 474 given area acts as a Route Reflector for VPLS A-D routes. Such a 475 Router Reflector is responsible for re-advertising VPLS A-D routes 476 across area's boundaries. When re-advertising these routes across 477 area's boundaries, this Route Reflector MUST follow the procedures in 478 this document. Note that such a Route Reflector may also re-advertise 479 VPLS A-D routes within the same area, in which case it follows plain 480 BGP Route Reflector procedures [RFC4456]. 482 When re-advertising VPLS A-D routes a Route Reflector MUST NOT modify 483 BGP Next Hop of these routes. 485 5.3. Global Table Multicast over MPLS 487 This section describes how the egress PEs discover the P2MP FEC when 488 the application is global table multicast over an MPLS-capable 489 infrastructure. In the rest of the document we will refer to this 490 application as "global table multicast". 492 When PIM-SM is used for non-bidirectional ASM ("Any Source 493 Multicast") group addresses, this document refers to this as "PIM-SM 494 in ASM mode". 496 In the case where global table multicast uses PIM-SM in ASM mode the 497 following assumes that an inter-area P2MP service LSP could be used 498 to either carry traffic on a shared (*,G), or a source (S,G) tree. 500 An egress PE learns the (S/*, G) of a multicast stream as a result of 501 receiving IGMP or PIM messages on one of its IP multicast interfaces. 502 This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP. 503 For each such P2MP FEC there MAY exist a distinct inter-area P2MP 504 service LSP, or multiple such FECs MAY be carried over a single P2MP 505 service LSP using a wildcard (*, *) S-PMSI [RFC6625]. 507 Note that this document does not require the use of (*, G) Inter-area 508 P2MP service LSPs when global table multicast uses PIM-SM in ASM 509 mode. In fact, PIM-SM in ASM mode may be supported entirely by using 510 only (S, G) inter-area P2MP service LSPs. 512 6. Egress PE/ASBR Signaling Procedures 514 This section describes egress PE/ASBR procedures for constructing 515 segmented inter-area P2MP LSP. The procedures in this section apply 516 irrespective of whether the egress PE/ASBR is in a leaf IGP area, or 517 the backbone area, or even in the same IGP area as the ingress 518 PE/ASBR. 520 An egress PE/ASBR applies procedures specified in this section to 521 MVPN I-PMSI or S-PMSI A-D routes only if these routes carry the 522 Inter-area P2MP Segmented Next-Hop Extended Community. An egress PE 523 applies procedures specified in this section to VPLS A-D routes or 524 VPLS S-PMSI A-D routes only if these routes carry the Inter-area P2MP 525 Segmented Next-Hop Extended Community. 527 In order to support global table multicast an egress PE MUST be auto- 528 configured to import routes that carry AS-specific Route Target 529 Extended Community ([RFC4360]) with the Global Administrator field 530 set to the AS of the PE and the Local Administrator field set to 0. 532 Once an egress PE/ASBR discovers the P2MP FEC of an inter-area 533 segmented P2MP service LSP, it MUST propagate this P2MP FEC in BGP in 534 order to construct the segmented inter-area P2MP service LSP. This 535 propagation uses BGP Leaf A-D routes. 537 6.1. Determining the Upstream ABR/PE/ASBR (Upstream Node) 539 An egress PE/ASBR discovers the P2MP FEC of an inter-area P2MP 540 Segmented Service LSP as described in section 5 ("Discovering P2MP 541 FEC of the Inter-Area P2MP Service LSP"). Once the egress PE/ASBR 542 discovers this P2MP FEC, it MUST determine the upstream node to reach 543 such a FEC. If the egress PE/ASBR and the ingress PE/ASBR are not in 544 the same area, and the egress PE/ASBR is not in the backbone IGP 545 area, then this upstream node would be an egress ABR. If the egress 546 PE/ASBR is in the backbone area and the ingress PE/ASBR is not in the 547 backbone area, then this upstream node would be an ingress ABR. If 548 the egress PE/ASBR is in the same area as the ingress PE/ASBR, then 549 this upstream node would be the ingress PE/ASBR. 551 6.1.1. Upstream Node for MVPN or VPLS 553 If the application is MVPN or VPLS, then the upstream node's IP 554 address is the IP address determined from the Global Administrator 555 field of the Inter-area P2MP Segmented Next-Hop Extended Community. 556 As described in section 5 ("Discovering P2MP FEC of the Inter-Area 557 P2MP Service LSP"), this Extended Community MUST be carried in the 558 MVPN or VPLS A-D route from which the P2MP FEC of the inter-area P2MP 559 Segmented Service LSP is determined. 561 6.1.2. Upstream Node for Global Table Multicast 563 If the application is global table multicast, then the unicast routes 564 to multicast sources/RPs SHOULD carry the "VRF Route Import" Extended 565 Community [RFC6514] where the IP address in the Global Administrator 566 field is set to the IP address of the PE or ASBR advertising the 567 unicast route. The Local Administrator field of this community MUST 568 be set to 0 (note, that this is in contrast to the case of MVPN, 569 where the Global Administrator field carries a non-zero value that 570 identifies a particular VRF on a PE that originates VPN-IP routes). 571 If it is not desirable to advertise the VRF Route Import Extended 572 Community in unicast routes, then unicast routes to multicast 573 sources/RPs MUST be advertised using the multicast SAFI i.e. SAFI 2, 574 and such routes MUST carry the VRF Route Import Extended Community. 576 Further, if the application is global table multicast, then the BGP 577 unicast routes that advertise the routes to the IP addresses of 578 PEs/ASBRs/ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop 579 Extended Community. The IP address in the Global Administrator field 580 of this community MUST be set to the IP address of the PE or ASBR or 581 ABR advertising the unicast route. The Local Administrator field of 582 this community MUST be set to 0. If it is not desirable to advertise 583 the P2MP Segmented Next-Hop Extended Community in BGP unicast routes, 584 then the BGP unicast routes to the IP addresses of PEs/ASBRs/ABRs 585 MUST be advertised using the multicast SAFI i.e. SAFI 2, and such 586 routes MUST carry the Inter-area P2MP Segmented Next-Hop Extended 587 Community. The procedures for handling the BGP Next Hop attribute of 588 SAFI 2 routes are the same as those of handling regular Unicast 589 routes and MAY follow [SEAMLESS-MPLS]. 591 If the application is global table multicast, then in order to 592 determine the upstream node address the egress PE first determines 593 the ingress PE. In order to determine the ingress PE, the egress PE 594 determines the best route to reach S/RP. The ingress PE address is 595 the IP address determined from the Global Administrator field of the 596 VRF Route Import Extended Community that is carried in this route. 597 The egress PE then finds the best unicast route to reach the ingress 598 PE. The upstream node address is the IP address determined from the 599 Global Administrator field of the Inter-area P2MP Segmented Next-Hop 600 Extended Community that is carried in this route. 602 6.2. Originating a Leaf A-D Route 604 If the P2MP FEC was derived from a MVPN or VPLS A-D route then the 605 egress PE MUST originate a Leaf A-D route if the MVPN or VPLS A-D 606 route carries a P-Tunnel Attribute with the "Leaf Information 607 Required" flag set. 609 If the P2MP FEC was derived from a global table multicast (S/*, G), 610 and the upstream node's address is not the same as the egress PE, 611 then the egress PE MUST originate a Leaf A-D route. 613 6.2.1. Leaf A-D Route for MVPN and VPLS 615 If the P2MP FEC was derived from MVPN or VPLS A-D routes then the 616 Route Key field of the Leaf A-D route contains the NLRI of the A-D 617 route from which the P2MP FEC was derived. This follows procedures 618 for constructing Leaf A-D routes described in [RFC6514, RFC7117]. 620 6.2.2. Leaf A-D Route for Global Table Multicast 622 If the application is global table multicast, then the MCAST-VPN NLRI 623 of the Leaf A-D route is constructed as follows: 625 The Route Key field of MCAST-VPN NLRI has the following format: 627 +-----------------------------------+ 628 | RD (8 octets) | 629 +-----------------------------------+ 630 | Multicast Source Length (1 octet) | 631 +-----------------------------------+ 632 | Multicast Source (Variable) | 633 +-----------------------------------+ 634 | Multicast Group Length (1 octet) | 635 +-----------------------------------+ 636 | Multicast Group (Variable) | 637 +-----------------------------------+ 638 | Ingress PE's IP address | 639 +-----------------------------------+ 641 RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast 642 Source is set to S for (S,G) state or RP for (*,G) state, Multicast 643 Group is set to G, Multicast Source Length and Multicast Group Length 644 is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or 645 IPv6 addresses). 647 The Ingress PE's IP address is determined as described in the section 648 6.1 ("Determining the Upstream ABR/PE/ASBR (Upstream Node)"). 650 The Originating Router's IP address field of MCAST-VPN NLRI is set to 651 the address of the local PE (PE that originates the route). 653 Thus the entire MCAST-VPN NLRI of the route has the following format: 655 +-----------------------------------+ 656 | Route Type = 4 (1 octet) | 657 +-----------------------------------+ 658 | Length (1 octet) | 659 +-----------------------------------+ 660 | RD (8 octets) | 661 +-----------------------------------+ 662 | Multicast Source Length (1 octet) | 663 +-----------------------------------+ 664 | Multicast Source (Variable) | 665 +-----------------------------------+ 666 | Multicast Group Length (1 octet) | 667 +-----------------------------------+ 668 | Multicast Group (Variable) | 669 +-----------------------------------+ 670 | Ingress PE's IP address | 671 +-----------------------------------+ 672 | Originating Router's IP address | 673 +-----------------------------------+ 675 Note that the encoding of MCAST-VPN NLRI for the Leaf A-D routes used 676 for global table multicast is different from the encoding used by the 677 Leaf A-D routes originated in response to S-PMSI or I-PMSI A-D 678 routes. A router that receives a Leaf A-D route can distinguish 679 between these two cases by examining the third octet of the MCAST-VPN 680 NLRI of the route. If the value of this octet is 0x01 or 0x02, or 681 0x03 then this Leaf A-D route was originated in response to an S-PMSI 682 or I-PMSI A-D route. If the value of this octet is either 0x00 or 683 0xff, and octets 3 through 10 contain either all 0x00, or all 0xff 684 then this is a Leaf A-D route used for global table multicast. 686 When the PE deletes (S,G)/(*,G) state that was created as a result of 687 receiving PIM or IGMP messages on one of its IP multicast interfaces, 688 if the PE previously originated a Leaf A-D route for that state, then 689 the PE SHOULD withdraw that route. 691 An Autonomous System with an IPv4 network may provide global table 692 multicast service for customers that use IPv6, and an Autonomous 693 System with an IPv6 network may provide global table multicast 694 service for customers that use IPv4. Therefore the address family of 695 the Ingress PE's IP address and Originating Router's IP address in 696 the Leaf A-D routes used for global table multicast MUST NOT be 697 inferred from the AFI field of the associated 698 MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these routes. The address 699 family is determined from the length of the address (a length of 4 700 octets for IPv4 addresses, a length of 16 octets for IPv6 addresses). 702 For example if an Autonomous System with an IPv4 network is providing 703 IPv6 multicast service to a customer, the Ingress PE's IP address and 704 Originating Router's IP address in the Leaf A-D routes used for IPv6 705 global table multicast will be a four-octet IPv4 address, even though 706 the AFI of those routes will have the value 2. 708 Note that the Ingress PE's IP address and the Originating Router's IP 709 address must be either both IPv4 or both IPv6 addresses, and thus 710 must be of the same length. Since the two variable length fields 711 (Multicast Source and Multicast Group) in the Leaf A-D routes used 712 for global table multicast have their own length field, from these 713 two length fields, and the Length field of the MCAST-VPN NLRI, one 714 can compute length of the Ingress PE's IP address and the Originating 715 Router's IP address fields. If the computed length of these fields is 716 neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to 717 be "incorrect", and MUST be handled as specified in section 7 of 718 [RFC4760]. 720 6.2.3. Constructing the Rest of the Leaf A-D Route 722 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 723 be set to the same IP address as the one carried in the Originating 724 Router's IP Address field of the route. 726 When Ingress Replication is used to instantiate the egress area 727 segment then the Leaf A-D route MUST carry a downstream assigned 728 label in the P-Tunnel Attribute where the P-Tunnel type is set to 729 Ingress Replication. A PE MUST assign a distinct MPLS label for each 730 Leaf A-D route originated by the PE. 732 To constrain distribution of this route, the originating PE 733 constructs an IP-based Route Target community by placing the IP 734 address of the upstream node in the Global Administrator field of the 735 community, with the Local Administrator field of this community set 736 to 0. The originating PE then adds this Route Target Extended 737 Community to this Leaf A-D route. The upstream node's address is 738 determined as specified in section 6.1 ("Determining the Upstream 739 ABR/PE/ASBR (Upstream Node)"). 741 The PE then advertises this route to the upstream node. 743 6.3. PIM-SM in ASM mode for Global Table Multicast 745 This specification allows two options for supporting global table 746 multicast with PIM-SM in ASM mode. The first option does not transit 747 IP multicast shared trees over the MPLS network. The second option 748 does transit shared trees over the MPLS network and relies on shared 749 tree to source tree switchover. 751 6.3.1. Option 1 753 This option does not transit IP multicast shared trees over the MPLS 754 network. Therefore, when an (egress) PE creates (*, G) state (as a 755 result of receiving PIM or IGMP messages on one of its IP multicast 756 interfaces), the PE does not propagate this state using Leaf A-D 757 routes. 759 6.3.1.1. Originating Source Active A-D Routes 761 Whenever as a result of receiving PIM Register or MSDP messages an RP 762 that is co-located with a PE discovers a new multicast source, the 763 RP/PE SHOULD originate a BGP Source Active A-D route. Similarly 764 whenever as a result of receiving MSDP messages, a PE that is not 765 configured as a RP, discovers a new multicast source the PE SHOULD 766 originate a BGP Source Active A-D route. The BGP Source Active A-D 767 route carries a single MCAST-VPN NLRI constructed as follows: 769 + The RD in this NLRI is set to 0. 771 + The Multicast Source field MUST be set to S. The Multicast 772 Source Length field is set appropriately to reflect this. 774 + The Multicast Group field MUST be set to G. The Multicast 775 Group Length field is set appropriately to reflect this. 777 The Route Target of this Source Active A-D route is an AS-specific 778 Route Target Extended Community with the Global Administrator field 779 set to the AS of the advertising RP/PE, and the Local Administrator 780 field is set to 0. 782 To constrain distribution of the Source Active A-D route to the AS of 783 the advertising RP this route SHOULD carry the NO_EXPORT Community 784 ([RFC1997]). 786 Using the normal BGP procedures the Source Active A-D route is 787 propagated to all other PEs within the AS. 789 Whenever the RP/PE discovers that the source is no longer active, the 790 RP MUST withdraw the Source Active A-D route, if such a route was 791 previously advertised by the RP. 793 6.3.1.2. Receiving BGP Source Active A-D Route by PE 795 When as a result of receiving PIM or IGMP messages on one of its IP 796 multicast interfaces an egress PE creates in its Tree Information 797 Base (TIB) a new (*, G) entry with a non-empty outgoing interface 798 list that contains one or more IP multicast interfaces, the PE MUST 799 check if it has any Source Active A-D routes for that G. If there is 800 such a route, S of that route is reachable via an MPLS interface, and 801 the PE does not have (S, G) state in its TIB for (S, G) carried in 802 the route, then the PE originates a Leaf A-D route carrying that (S, 803 G), as specified in section 6.2.2 ("Leaf A-D Route for Global Table 804 Multicast"). 806 When an egress PE receives a new Source Active A-D route, the PE MUST 807 check if its TIB contains an (*, G) entry with the same G as carried 808 in the Source Active A-D route. If such an entry is found, S is 809 reachable via an MPLS interface, and the PE does not have (S, G) 810 state in its TIB for (S, G) carried in the route, then the PE 811 originates a Leaf A-D route carrying that (S, G), as specified in 812 section 6.2.2 ("Leaf A-D Route for Global Table Multicast"). 814 6.3.1.3. Handling (S, G, rpt) state 816 Creation and deletion of (S, G, rpt) state on a PE that resulted from 817 receiving PIM messages on one of its IP multicast interfaces does not 818 result in any BGP actions by the PE. 820 6.3.2. Option 2 822 This option does transit IP multicast shared trees over the MPLS 823 network. Therefore, when an egress PE creates (*, G) state (as a 824 result of receiving PIM or IGMP messages on one of its IP multicast 825 interfaces), the PE does propagate this state using Leaf A-D routes. 827 6.3.2.1. Originating Source Active A-D Routes 829 Whenever a PE creates an (S, G) state as a result of receiving Leaf 830 A-D routes associated with the global table multicast service, if S 831 is reachable via one of the IP multicast capable interfaces, and the 832 PE determines that G is in the PIM-SM in ASM mode range, the PE MUST 833 originate a BGP Source Active A-D route. The route carries a single 834 MCAST-VPN NLRI constructed as follows: 836 + The RD in this NLRI is set to 0. 838 + The Multicast Source field MUST be set to S. The Multicast 839 Source Length field is set appropriately to reflect this. 841 + The Multicast Group field MUST be set to G. The Multicast 842 Group Length field is set appropriately to reflect this. 844 The Route Target of this Source Active A-D route is an AS-specific 845 Route Target Extended Community with the Global Administrator field 846 set to the AS of the advertising PE, and the Local Administrator 847 field is set to 0. 849 To constrain distribution of the Source Active A-D route to the AS of 850 the advertising PE this route SHOULD carry the NO_EXPORT Community 851 ([RFC1997]). 853 Using the normal BGP procedures the Source Active A-D route is 854 propagated to all other PEs within the AS. 856 Whenever the PE deletes the (S, G) state that was previously created 857 as a result of receiving a Leaf A-D route for (S, G), the PE that 858 deletes the state MUST also withdraw the Source Active A-D route, if 859 such a route was advertised when the state was created. 861 6.3.2.2. Receiving BGP Source Active A-D Route 863 Procedures for receiving BGP Source Active A-D routes are the same as 864 with Option 1. 866 6.3.2.3. Pruning Sources off the Shared Tree 868 If after receiving a new Source Active A-D route for (S,G) a PE 869 determines that (a) it has the (*, G) entry in its TIB, (b) the 870 incoming interface list (iif) for that entry contains one of the IP 871 interfaces, (c) a MPLS LSP is in the outgoing interface list (oif) 872 for that entry, and (d) the PE does not originate a Leaf A-D route 873 for (S,G), then the PE MUST transition the (S,G,rpt) downstream state 874 to the Prune state. [Conceptually the PIM state machine on the PE 875 will act "as if" it had received Prune(S,G,Rpt) from some other PE, 876 without actually having received one.] Depending on the (S,G,rpt) 877 state on the iifs, this may result in the PE using PIM procedures to 878 prune S off the Shared (*,G) tree. 880 Transitioning the state machine to the Prune state SHOULD be done 881 after a delay that is controlled by a timer. The value of the timer 882 MUST be configurable. The purpose of this timer is to ensure that S 883 is not pruned off the shared tree until all PEs have had time to 884 receive the Source Active A-D route for (S,G). 886 The PE MUST keep the (S,G,rpt) downstream state machine in the Prune 887 state for as long as (a) the outgoing interface list (oif) for (*, G) 888 contains a MPLS LSP, and (b) the PE has at least one Source Active A- 889 D route for (S,G), and (c) the PE does not originate the Leaf A-D 890 route for (S,G). Once either of these conditions become no longer 891 valid, the PE MUST transition the (S,G,rpt) downstream state machine 892 to the NoInfo state. 894 Note that except for the scenario described in the first paragraph of 895 this section, in all other scenarios relying solely on PIM procedures 896 on the PE is sufficient to ensure the correct behavior when pruning 897 sources off the shared tree. 899 6.3.2.4. More on handling (S, G, rpt) state 901 Creation and deletion of (S, G, rpt) state on a PE that resulted from 902 receiving PIM messages on one of its IP multicast interfaces does not 903 result in any BGP actions by the PE. 905 7. Egress ABR Procedures 907 This section describes Egress ABR Procedures for constructing 908 segmented inter-area P2MP LSP. 910 7.1. Handling Leaf A-D route on Egress ABR 912 When an egress ABR receives a Leaf A-D route and the Route Target 913 Extended Community carried by the route contains the IP address of 914 this ABR, then the following procedures will be executed. 916 If the value of the third octet of the MCAST-VPN NLRI of the received 917 Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that 918 the Leaf A-D route was originated in response to an S-PMSI or I-PMSI 919 A-D route (see section "Leaf A-D Route for Global Table Multicast"). 920 In this case the egress ABR MUST find a S-PMSI or I-PMSI route whose 921 NLRI has the same value as the Route Key field of the received Leaf 922 A-D route. If such a matching route is found then the Leaf A-D route 923 MUST be accepted. If the Leaf A-D route is accepted and if it is the 924 first Leaf A-D route update for the Route Key field in the route, or 925 the withdrawal of the last Leaf A-D route for the Route Key field 926 then the following procedures will be executed. 928 If the RD of the received Leaf A-D route is set to all 0s or all 1s 929 then the received Leaf A-D route is for the global table multicast 930 service. 932 If the received Leaf A-D route is the first Leaf A-D route update for 933 the Route Key field carried in the route, then the egress ABR 934 originates a Leaf A-D route, whose MCAST-VPN NLRI is constructed as 935 follows. 937 The Route Key field of MCAST-VPN NLRI is the same as the Route Key 938 field of MCAST-VPN NLRI of the received Leaf A-D route. The 939 Originating Router's IP address field of MCAST-VPN NLRI is set to the 940 address of the local ABR (the ABR that originates the route). 942 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 943 be set to the same IP address as the one carried in the Originating 944 Router's IP Address field of the route. 946 To constrain distribution of this route the originating egress ABR 947 constructs an IP-based Route Target Extended Community by placing the 948 IP address of the upstream node in the Global Administrator field of 949 the community, with the Local Administrator field of this community 950 set to 0, and sets the Extended Communities attribute of this Leaf A- 951 D route to that community. 953 The upstream node's IP address is the IP address determined from the 954 Global Administrator field of the Inter-area P2MP Segmented Next-Hop 955 Extended Community, where this Extended Community is obtained as 956 follows. When the Leaf A-D route is for MVPN or VPLS, then this 957 Extended Community is the one carried in the I-PMSI/S-PMSI A-D route 958 that matches the Leaf A-D route. When the Leaf A-D route is for 959 global table multicast, then this Extended Community is the one 960 carried in the best unicast route to the Ingress PE. The Ingress PE 961 address is determined from the received Leaf A-D route. The best 962 unicast route MUST first be determined from multicast SAFI i.e., SAFI 963 2 routes, if present. 965 The ABR then advertises this Leaf A-D route to the upstream node in 966 the backbone area. 968 Mechanisms specific in [RFC4684] for constrained BGP route 969 distribution can be used along with this specification to ensure that 970 only the needed PE/ABR will have to process a said Leaf A-D route. 972 When Ingress Replication is used to instantiate the backbone area 973 segment then the Leaf A-D route originated by the egress ABR MUST 974 carry a downstream assigned label in the P-Tunnel Attribute where the 975 P-Tunnel type is set to Ingress Replication. The ABR MUST assign a 976 distinct MPLS label for each Leaf A-D route that it originates. 978 In order to support global table multicast an egress ABR MUST auto- 979 configure an import AS-based Route Target Extended Community with the 980 Global Administrator field set to the AS of the ABR and the Local 981 Administrator field set to 0. 983 If the received Leaf A-D route is the withdrawal of the last Leaf A-D 984 route for the Route Key carried in the route, then the egress ABR 985 must withdraw the Leaf A-D route associated with that Route Key that 986 has been previously advertised by the egress ABR in the backbone 987 area. 989 7.2. P2MP LSP as the Intra-Area LSP in the Egress Area 991 This section describes procedures for using intra-area P2MP LSPs in 992 the egress area. The procedures that are common to both P2MP RSVP-TE 993 and P2MP LDP are described first, followed by procedures that are 994 specific to the signaling protocol. 996 When P2MP LSPs are used as the intra-area LSPs, note that an existing 997 intra-area P2MP LSP may be used solely for a particular inter-area 998 P2MP service LSP, or for other inter-area P2MP service LSPs as well. 999 The choice between the two options is purely local to the egress ABR. 1000 The first option provides one-to-one mapping between inter-area P2MP 1001 service LSPs and intra-area P2MP LSPs; the second option provides 1002 many-to-one mapping, thus allowing to aggregate forwarding state. 1004 7.2.1. Received Leaf A-D route is for MVPN or VPLS 1006 If the value of the third octet of the MCAST-VPN NLRI of the received 1007 Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that 1008 the Leaf A-D route was originated in response to an MVPN or VPLS S- 1009 PMSI or I-PMSI A-D route (see section "Leaf A-D Route for Global 1010 Table Multicast"). In this case the ABR MUST re-advertise in the 1011 egress area the MVPN/VPLS A-D route that matches the Leaf A-D route 1012 to signal the binding of the intra-area P2MP LSP to the inter-area 1013 P2MP service LSP. This must be done if and only if (a) such a binding 1014 hasn't already been advertised, or (b) the binding has changed. The 1015 re-advertised route MUST carry the Inter-area P2MP Segmented Next-Hop 1016 Extended Community. 1018 The PMSI Tunnel attribute of the re-advertised route specifies either 1019 an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted 1020 at the ABR and MUST also carry an upstream assigned MPLS label. The 1021 upstream-assigned MPLS label MUST be set to implicit NULL if the 1022 mapping between the inter-area P2MP service LSP and the intra-area 1023 P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area 1024 segment of the inter-area P2MP service LSP (referred to as the 1025 "inner" P2MP LSP) is constructed by nesting the inter-area P2MP 1026 service LSP in an intra-area P2MP LSP (referred to as the "outer" 1027 intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream- 1028 assigned MPLS labels [RFC5332]. 1030 If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried 1031 over a given intra-area P2MP LSP, each of these segments MUST carry a 1032 distinct upstream-assigned label, even if all these service LSPs are 1033 for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR 1034 maintains an LFIB state for each such S-PMSI traversing the ABR (that 1035 applies to both the ingress and the egress ABRs). 1037 7.2.2. Received Leaf A-D route is for global table multicast 1039 When the RD of the received Leaf A-D route is set to all 0s or all 1040 1s, then this is the case of inter-area P2MP service LSP being 1041 associated with the global table multicast service. The procedures 1042 for this are described below. 1044 7.2.2.1. Global Table Multicast and S-PMSI A-D Routes 1046 This section applies only if it is desirable to send a particular (S, 1047 G) or (*, G) global table multicast flow only to those egress PEs 1048 that have receivers for that multicast flow. 1050 If the egress ABR have not previously received (and re-advertised) an 1051 S-PMSI A-D route for (S, G) or (*, G) that has been originated by an 1052 ingress PE/ASBR (see section "P2MP LSP as the Intra-Area LSP in the 1053 Ingress Area"), then the egress ABR MUST originate a S-PMSI A-D 1054 route. The PMSI Tunnel attribute of the route MUST contain the 1055 identity of the intra-area P2MP LSP and an upstream assigned MPLS 1056 label (although this label may be an Implicit NULL - see section 1057 "General Assumptions and Terminology"). The RD, Multicast Source 1058 Length, Multicast Source, Multicast Group Length (1 octet), and 1059 Multicast Group fields of the NLRI of this route are the same as of 1060 the received Leaf A-D route. The Originating Router's IP address 1061 field in the S-PMSI A-D route is the same as the Ingress PE's IP 1062 address field in the received Leaf A-D route. The Route Target of 1063 this route is an AS-specific Route Target Extended Community with the 1064 Global Administrator field set to the AS of the advertising ABR, and 1065 the Local Administrator field is set to 0. The route MUST carry the 1066 Inter-area P2MP Segmented Next-Hop Extended Community. This 1067 community is constructed following the procedures in section 4 1068 ("Inter-area P2MP Segmented Next-Hop Extended Community"). 1070 The egress ABR MUST advertise this route into the egress area. PEs in 1071 the egress area that participate in the global table multicast will 1072 import this route based on the Route Target carried by the route. 1074 A PE in the egress area that originated the Leaf A-D route SHOULD 1075 join the P2MP LSP advertised in the PMSI Tunnel attribute of the S- 1076 PMSI A-D route. 1078 7.2.2.2. Global Table Multicast and Wildcard S-PMSI A-D Routes 1080 It may be desirable for an ingress PE to carry multiple multicast 1081 flows associated with the global table multicast over the same inter- 1082 area P2MP service LSP. This can be achieved using wildcard, i.e., 1083 (*,*) S-PMSI A-D routes [RFC6625]. An ingress PE MAY advertise a 1084 wildcard S-PMSI A-D route as described in section 9 ("Ingress PE/ASBR 1085 Procedures"). 1087 If the ingress PE originates a wildcard S-PMSI A-D route, and the 1088 egress ABR receives this route from the ingress ABR, then the egress 1089 ABR either (a) MUST re-advertise this route into the egress area with 1090 the PMSI Tunnel Attribute containing the identifier of the intra-area 1091 P2MP LSP in the egress area and an upstream assigned label (note that 1092 this label may be an Implicit NULL - see section "General Assumptions 1093 and Terminology") assigned to the inter-area wildcard S-PMSI, or (b) 1094 MUST be able to disaggregate traffic carried over the wildcard S-PMSI 1095 onto the egress area (S, G) or (*, G) S-PMSIs. The procedures for 1096 such disaggregation require IP processing on the egress ABRs. 1098 If the egress ABR advertises a wildcard S-PMSI A-D route into the 1099 egress area, this route MUST carry AS-specific Route Target Extended 1100 Community with the Global Administrator field set to the AS of the 1101 advertising ABR, and the Local Administrator field set to 0. PEs in 1102 the egress area that participate in the global table multicast will 1103 import this route. 1105 A PE in the egress area SHOULD join the P2MP LSP advertised in the 1106 PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the 1107 Originating Router's IP Address field in the S-PMSI A-D route has the 1108 same value as the Ingress PE's IP address in at least one of the Leaf 1109 A-D routes for global table multicast originated by the PE, and (b) 1110 the upstream ABR for the Ingress PE's IP address in that Leaf A-D 1111 route is the egress ABR that advertises the wildcard S-PMSI A-D 1112 route. 1114 7.2.3. Global Table Multicast and the Expected Upstream Node 1116 If the mapping between the inter-area P2MP service LSP for global 1117 table multicast service and the intra-area P2MP LSP is many-to-one 1118 then an egress PE must be able to determine whether a given multicast 1119 packet for a particular (S, G) is received from the "expected" 1120 upstream node. The expected node is the node towards which the Leaf 1121 A-D route is sent by the egress PE. Packets received from another 1122 upstream node for that (S, G) MUST be dropped. To allow the egress PE 1123 to determine the sender upstream node, the intra-area P2MP LSP must 1124 be signaled with no PHP, when the mapping between the inter-area P2MP 1125 service LSP for global table multicast service and the intra-area 1126 P2MP LSP is many-to-one. 1128 Further the egress ABR MUST first push onto the label stack the 1129 upstream assigned label advertised in the S-PMSI A-D route, if the 1130 label is not the Implicit NULL. 1132 7.2.4. P2MP LDP LSP as the Intra-Area P2MP LSP 1134 The above procedures are sufficient if P2MP LDP LSPs are used as the 1135 Intra-area P2MP LSP in the Egress area. 1137 7.2.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP 1139 If P2MP RSVP-TE LSP is used as the intra-area LSP in the egress area, 1140 then the egress ABR can either (a) graft the leaf (whose IP address 1141 is specified in the received Leaf A-D route) into an existing P2MP 1142 LSP rooted at the egress ABR, and use that LSP for carrying traffic 1143 for the inter-area segmented P2MP service LSP, or (b) originate a new 1144 P2MP LSP to be used for carrying (S,G). 1146 When the RD of the received Leaf A-D route is all 0s or all 1s, then 1147 the procedures are as described in section "Received Leaf A-D route 1148 is for global table multicast". 1150 Note also that the SESSION object that the egress ABR would use for 1151 the intra-area P2MP LSP need not encode the P2MP FEC from the 1152 received Leaf A-D route. 1154 7.3. Ingress Replication in the Egress Area 1156 When Ingress Replication is used to instantiate the egress area 1157 segment then the Leaf A-D route advertised by the egress PE MUST 1158 carry a downstream assigned label in the P-Tunnel Attribute where the 1159 P-Tunnel type is set to Ingress Replication. We will call this label 1160 the egress PE downstream assigned label. 1162 The egress ABR MUST forward packets received from the backbone area 1163 intra-area segment, for a particular inter-area P2MP LSP, to all the 1164 egress PEs from which the egress ABR has imported a Leaf A-D route 1165 for the inter-area P2MP LSP. A packet to a particular egress PE is 1166 encapsulated, by the egress ABR, using a MPLS label stack the bottom 1167 label of which is the egress PE downstream assigned label. The top 1168 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 1169 PE. 1171 Note that these procedures ensures that an egress PE always receives 1172 packets only from the upstream node expected by the egress PE. 1174 8. Ingress ABR Procedures 1176 When an ingress ABR receives a Leaf A-D route and the Route Target 1177 Extended Community carried by the route contains the IP address of 1178 this ABR, then the ingress ABR follows the same procedures as in 1179 section 7 ("Egress ABR Procedures"), with egress ABR replaced by 1180 ingress ABR, backbone area replaced by ingress area, and backbone 1181 area segment replaced by ingress area segment. 1183 In order to support global table multicast the ingress ABR MUST be 1184 auto-configured with an import AS-based Route Target Extended 1185 Community whose Global Administrator field is set to the AS of the 1186 ABR and the Local Administrator field is set to 0. 1188 8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 1190 The procedures for binding the backbone area segment of an inter-area 1191 P2MP LSP to the intra-area P2MP LSP in the backbone area are the same 1192 as in section "Egress ABR Procedures" and sub-section "P2MP LSP as 1193 the Intra-Area LSP in the Egress Area", with egress PE being replace 1194 by egress ABR, egress ABR being replaced by ingress ABR, and egress 1195 area being replaced by backbone area. This applies to the inter-area 1196 P2MP LSPs associated with either MVPN, or VPLS, or global table 1197 multicast. 1199 It is to be noted that in the case of global table multicast, if the 1200 backbone area uses wildcard S-PMSI, then the egress area also SHOULD 1201 use wildcard S-PMSI for global table multicast, or the egress ABRs 1202 MUST be able to disaggregate traffic carried over the wildcard S-PMSI 1203 onto the egress area (S, G) or (*, G) S-PMSIs. The procedures for 1204 such disaggregation require IP processing on the egress ABRs. 1206 8.2. Ingress Replication in the Backbone Area 1208 When Ingress Replication is used to instantiate the backbone area 1209 segment then the Leaf A-D route advertised by the egress ABR MUST 1210 carry a downstream assigned label in the P-Tunnel Attribute where the 1211 P-Tunnel type is set to Ingress Replication. We will call this the 1212 egress ABR downstream assigned label. The egress ABR MUST assign a 1213 distinct MPLS label for each Leaf A-D route originated by the ABR. 1215 The ingress ABR MUST forward packets received from the ingress area 1216 intra-area segment, for a particular inter-area P2MP LSP, to all the 1217 egress ABRs from which the ingress ABR has imported a Leaf A-D route 1218 for the inter-area P2MP LSP. A packet to a particular egress ABR is 1219 encapsulated, by the ingress ABR, using a MPLS label stack the bottom 1220 label of which is the egress ABR downstream assigned label. The top 1221 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 1222 ABR. 1224 9. Ingress PE/ASBR Procedures 1226 This section describes Ingress PE/ASBR procedures for constructing 1227 segmented inter-area P2MP LSP. 1229 When an ingress PE/ASBR receives a Leaf A-D route and the Route 1230 Target Extended Community carried by the route contains the IP 1231 address of this PE/ASBR, then the following procedures will be 1232 executed. 1234 If the value of the third octet of the MCAST-VPN NLRI of the received 1235 Leaf A-D route is either 0x01, or 0x02, or 0x03, this indicates that 1236 the Leaf A-D route was originated in response to an S-PMSI or I-PMSI 1237 A-D route (see section "Leaf A-D Route for Global Table Multicast"). 1238 In this case the ingress PE/ASBR MUST find a S-PMSI or I-PMSI route 1239 whose NLRI has the same value as the Route Key field of the received 1240 Leaf A-D route. If such a matching route is found then the Leaf A-D 1241 route MUST be accepted else it MUST be discarded. If the Leaf A-D 1242 route is accepted then it MUST be processed as per MVPN or VPLS 1243 procedures. 1245 If the RD of the received A-D route is set to all 0s or all 1s, then 1246 the received Leaf A-D route is for the global table multicast 1247 service. If this is the first Leaf A-D route for the Route Key 1248 carried in the route, the PIM implementation MUST set its upstream 1249 (S/RP,G) state machine to Joined state for the (S/RP, G) received via 1250 a Leaf A-D route update. Likewise, if this is the withdrawal of the 1251 last Leaf A-D route whose Route Key matches a particular (S/RP, G) 1252 state, the PIM implementation MUST set its upstream (S/RP, G) state 1253 machine to Pruned state for the (S/RP, G). 1255 9.1. P2MP LSP as the Intra-Area LSP in the Ingress Area 1257 If the value of the third octet of the MCAST-VPN NLRI of the received 1258 Leaf A-D route is either 0x01, or 0x02, or 0x03 (which indicates that 1259 the Leaf A-D route was originated in response to an S-PMSI or I-PMSI 1260 A-D route), and P2MP LSP is used as the intra-area LSP in the ingress 1261 area, then the procedures for binding the ingress area segment of the 1262 inter-area P2MP LSP to the intra-area P2MP LSP in the ingress area, 1263 are the same as in section "Egress ABR Procedures" and sub-section 1264 "P2MP LSP as the Intra-Area LSP in the Egress Area". 1266 When the RD of the received Leaf A-D route is all 0s or all 1s, as is 1267 the case where the inter-area service P2MP LSP is associated with the 1268 global table multicast service, then the ingress PE MAY originate a 1269 S-PMSI A-D route with the RD, multicast source, multicast group 1270 fields being the same as those in the received Leaf A-D route. 1272 Further in the case of global table multicast an ingress PE MAY 1273 originate a wildcard S-PMSI A-D route as per the procedures in 1274 [RFC6625] with the RD set to 0. This route may be originated by the 1275 ingress PE based on configuration or based on the import of a Leaf A- 1276 D route with RD set to 0. If an ingress PE originates such a route, 1277 then the ingress PE MAY decide not to originate (S, G) or (*, G) S- 1278 PMSI A-D routes. 1280 The wildcard S-PMSI A-D route MUST carry the Inter-area P2MP 1281 Segmented Next-Hop Extended Community. This community is constructed 1282 following the procedures in section 4 ("Inter-area P2MP Segmented 1283 Next-Hop Extended Community"). 1285 It is to be noted that in the case of global table multicast, if the 1286 ingress area uses wildcard S-PMSI, then the backbone area also SHOULD 1287 use wildcard S-PMSI for global table multicast, or the ingress ABRs 1288 MUST be able to disaggregate traffic carried over the wildcard S-PMSI 1289 onto the backbone area (S, G) or (*, G) S-PMSIs. The procedures for 1290 such disaggregation require IP processing on the ingress ABRs. 1292 9.2. Ingress Replication in the Ingress Area 1294 When Ingress Replication is used to instantiate the ingress area 1295 segment then the Leaf A-D route advertised by the ingress ABR MUST 1296 carry a downstream assigned label in the P-Tunnel Attribute where the 1297 P-Tunnel type is set to Ingress Replication. We will call this the 1298 ingress ABR downstream assigned label. The ingress ABR MUST assign a 1299 distinct MPLS label for each Leaf A-D route originated by the ABR. 1301 The ingress PE/ASBR MUST forward packets received from the CE, for a 1302 particular inter-area P2MP LSP, to all the ingress ABRs from which 1303 the ingress PE/ASBR has imported a Leaf A-D route for the inter-area 1304 P2MP LSP. A packet to a particular ingress ABR is encapsulated, by 1305 the ingress PE/ASBR, using a MPLS label stack the bottom label of 1306 which is the ingress ABR downstream assigned label. The top label is 1307 the P2P RSVP-TE or the MP2P LDP label to reach the ingress ABR. 1309 10. Common Tunnel Type in the Ingress and Egress Areas 1311 For a given inter-area service P2MP LSP, the PE/ASBR that is the root 1312 of that LSP controls the tunnel type of the intra-area P-tunnel that 1313 carries the ingress area segment of that LSP. However, the tunnel 1314 type of the intra-area P-tunnel that carries the backbone area 1315 segment of that LSP may be different from the tunnel type of the 1316 intra-area P-tunnels that carry the ingress area segment and the 1317 egress area segment of that LSP. In that situation if for a given 1318 inter-area P2MP LSP it is desirable/necessary to use the same tunnel 1319 type for the intra-area P-tunnels that carry the ingress area segment 1320 and the egress area segment of that LSP, then the following 1321 procedures on the ingress ABR and egress ABR provide this 1322 functionality. 1324 When an ingress ABR re-advertises into the backbone area a BGP MVPN 1325 I-PMSI, or S-PMSI A-D route, or VPLS A-D route, the ingress ABR 1326 places the PMSI Tunnel attribute of this route into the ATTR_SET BGP 1327 Attribute [RFC6368], adds this attribute to the re-advertised route, 1328 and then replaces the original PMSI Tunnel attribute with a new one 1329 (note, that the Tunnel type of the new attribute may be different 1330 from the Tunnel type of the original attribute). 1332 When an egress ABR re-advertises into the egress area a BGP MVPN I- 1333 PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries the 1334 ATTR_SET BGP attribute [RFC6368], then the ABR sets the Tunnel type 1335 of the PMSI Tunnel attribute in the re-advertised route to the Tunnel 1336 type of the PMSI Tunnel attribute carried in the ATTR_SET BGP 1337 attribute, and removes the ATTR_SET from the route. 1339 11. Placement of Ingress and Egress PEs 1341 As described in the earlier sections, procedures in this document 1342 allow the placement of ingress and egress PEs in the backbone area. 1343 They also allow the placement of egress PEs in the ingress area or 1344 the placement of ingress PEs in the egress area. 1346 For instance, ABRs in the backbone area may act as ingress and egress 1347 PEs for global table multicast, as per the ingress and egress PE 1348 definition in this document. This may be the case if the service is 1349 global table multicast and relies on global table multicast in the 1350 ingress and egress areas and its desirable to carry global table 1351 multicast over MPLS in the backbone area. This may also be the case 1352 if the service is MVPN and the P-tunnel technology in the ingress and 1353 egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are 1354 concerned PIM signaling for such P-Tunnels is handled as per the 1355 ingress/egress PE global table multicast procedures specified in this 1356 document. To facilitate this the ABRs may advertise their loopback 1357 addresses in BGP using multicast-SAFI i.e., SAFI 2, if non-congruence 1358 between unicast and multicast is desired. 1360 12. MVPN with Virtual Hub-and-Spoke 1362 Procedures described in this document could be used in conjunction 1363 with the Virtual Hub-and-Spoke procedures [RFC7024]. 1365 This document does not place any restrictions on the placement of 1366 Virtual Hubs and Virtual Spokes. 1368 In addition to I-PMSI/S-PMSI A-D routes, the procedures described in 1369 this document are applicable to Associated-V-spoke-only I-PMSI A-D 1370 routes. 1372 In the scenario where a V-hub, as a result of importing an S-PMSI A-D 1373 route in its VRF, originates an S-PMSI A-D route targeted to its V- 1374 spokes (as specified in section "Case 2" of [RFC7024]), the V-hub 1375 SHOULD be able to control via configuration whether the Inter-area 1376 P2MP Segmented Next-Hop Extended Community, if present in the 1377 received S-PMSI A-D route, be also carried in the originated S-PMSI 1378 A-D route. By default if the received S-PMSI A-D route carries the 1379 Inter-area P2MP Segmented Next-Hop Extended Community, then the 1380 originated S-PMSI A-D route SHOULD also carry this community. 1382 13. Data Plane 1384 This section describes the data plane procedures on the ABRs, ingress 1385 PEs, egress PEs and transit routers. 1387 13.1. Data Plane Procedures on ABRs 1389 When procedures in this document are followed to signal inter-area 1390 P2MP Segmented LSPs, then ABRs are required to perform only MPLS 1391 switching. When an ABR receives a MPLS packet from an "incoming" 1392 intra-area segment of the inter-area P2MP Segmented LSP, it forwards 1393 the packet, based on MPLS switching, onto another "outgoing" intra- 1394 area segment of the inter-area P2MP Segmented LSP. 1396 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1397 and if there is a one-to-one mapping between the outgoing intra-area 1398 segment and the P2MP LSP, then the ABR MUST pop the incoming 1399 segment's label stack and push the label stack of the outgoing P2MP 1400 LSP. If there is a many-to-one mapping between outgoing intra-area 1401 segments and the P2MP LSP then the ABR MUST pop the incoming 1402 segment's label stack and first push the upstream assigned label 1403 corresponding to the outgoing intra-area segment, if such a label has 1404 been assigned, and then push the label stack of the outgoing P2MP 1405 LSP. 1407 If the outgoing intra-area segment is instantiated using ingress 1408 replication then the ABR must pop the incoming segment's label stack 1409 and replicate the packet once to each leaf ABR or PE of the outgoing 1410 intra-area segment. The label stack of the packet sent to each such 1411 leaf MUST first include a downstream assigned label assigned by the 1412 leaf to the segment, followed by the label stack of the P2P or MP2P 1413 LSP to the leaf. 1415 13.2. Data Plane Procedures on Egress PEs 1417 An egress PE must first identify the inter-area P2MP segmented LSP 1418 based on the incoming label stack. After this identification the 1419 egress PE must forward the packet using the application that is bound 1420 to the inter-area P2MP segmented LSP. 1422 Note that the application specific forwarding for MVPN service may 1423 require the egress PE to determine whether the packets were received 1424 from the expected sender PE. When the application is MVPN then the 1425 FEC of an inter-area P2MP Segmented LSP is at the granularity of the 1426 sender PE. Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D 1427 routes both carry the Originating Router IP Address. Thus an egress 1428 PE could associate the data arriving on P-tunnels advertised by these 1429 routes with the Originating Router IP Address carried by these routes 1430 which is the same as the ingress PE. Since a unique label stack is 1431 associated with each such FEC, the egress PE can determine the sender 1432 PE from the label stack. 1434 Likewise for VPLS service for the purposes of MAC learning the egress 1435 PE must be able to determine the "VE-ID" from which the packets have 1436 been received. The FEC of the VPLS A-D routes carries the VE-ID. Thus 1437 an egress PE could associate the data arriving on P-tunnels 1438 advertised by these routes with the VE-ID carried by these routes. 1439 Since a unique label stack is associated with each such FEC, the 1440 egress PE can perform MAC learning for packets received from a given 1441 VE-ID. 1443 When the application is global table multicast it is sufficient for 1444 the label stack to include identification of the sender upstream 1445 node. When P2MP LSPs are used this requires that PHP MUST be turned 1446 off. When Ingress Replication is used the egress PE knows the 1447 incoming downstream assigned label to which it has bound a particular 1448 (S/*, G) and must accept packets with only that label for that (S/*, 1449 G). 1451 13.3. Data Plane Procedures on Ingress PEs 1453 An Ingress PE must perform application specific forwarding procedures 1454 to identify the outgoing intra-area segment of an incoming packet. 1456 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1457 and if there is a one-to-one mapping between the outgoing intra-area 1458 segment and the P2MP LSP, then the ingress PE MUST encapsulate the 1459 packet in the label stack of the outgoing P2MP LSP. If there is a 1460 many-to-one mapping between outgoing intra-area segments and the P2MP 1461 LSP then the PE MUST first push the upstream assigned label 1462 corresponding to the outgoing intra-area segment, if such a label has 1463 been assigned, and then push the label stack of the outgoing P2MP 1464 LSP. 1466 If the outgoing intra-area segment is instantiated using ingress 1467 replication then the PE must replicate the packet once to each leaf 1468 ABR or PE of the outgoing intra-area segment. The label stack of the 1469 packet sent to each such leaf MUST first include a downstream 1470 assigned label assigned by the leaf to the segment, followed by the 1471 label stack of the P2P or MP2P LSP to the leaf. 1473 13.4. Data Plane Procedures on Transit Routers 1475 When procedures in this document are followed to signal inter-area 1476 P2MP Segmented LSPs then transit routers in each area perform only 1477 MPLS switching. 1479 14. Support for Inter-Area Transport LSPs 1481 This section describes OPTIONAL procedures that allow to aggregate 1482 multiple (inter-area) P2MP service LSPs into a single inter-area P2MP 1483 transport LSP, and then apply the segmentation procedures, as 1484 specified in this document, to these inter-area P2MP transport LSPs 1485 (rather than applying these procedures directly to the inter-area 1486 P2MP service LSPs). 1488 14.1. Transport Tunnel Tunnel Type 1490 For the PMSI Tunnel Attribute we define a new Tunnel type, called 1491 "Transport Tunnel", whose Tunnel Identifier is a tuple . This Tunnel type is assigned a value of 8. 1493 The Source PE Address is the address of the PE that originates the 1494 (service) A-D route that carries this attribute, and the Local Number 1495 is a number that is unique to the Source PE. The length of the Local 1496 Number part is the same as the length of the Source PE Address. Thus 1497 if the Source PE Address is an IPv4 address, then the Local Number 1498 part is 4 octets, and if the Source PE Address is an IPv6 address, 1499 then the Local Number part is 16 octets. 1501 14.2. Discovering Leaves of the Inter-Area P2MP Service LSP 1503 When aggregating multiple P2MP LSPs using P2MP LSP hierarchy, 1504 determining the leaf nodes of the LSPs being aggregated is essential 1505 for being able to tradeoff the overhead due to the P2MP LSPs vs 1506 suboptimal use of bandwidth due to the partial congruency of the LSPs 1507 being aggregated. 1509 Therefore, if a PE that is a root of a given service P2MP LSP wants 1510 to aggregate this LSP with other (service) P2MP LSPs rooted at the 1511 same PE into an inter-area P2MP transport LSP, the PE should first 1512 determine all the leaf nodes of that service LSP, as well as those of 1513 the other service LSPs being aggregated). 1515 To accomplish this the PE sets the PMSI Tunnel attribute of the 1516 service A-D route (an I-PMSI or S-PMSI A-D route for MVPN or VPLS 1517 service) associated with that LSP as follows. The Tunnel Type is set 1518 to "No tunnel information present", Leaf Information Required flag is 1519 set to 1, the route MUST NOT carry the P2MP Segmented Next-Hop 1520 Extended Community. In contrast to the procedures for the MVPN and 1521 VPLS A-D routes described so far, the Route Reflectors that 1522 participate in the distribution of this route need not be ABRs. 1524 14.3. Discovering P2MP FEC of P2MP Transport LSP 1526 Once the ingress PE determines all the leaves of a given P2MP service 1527 LSP, the PE (using some local to the PE criteria) selects a 1528 particular inter-area transport P2MP LSP to be used for carrying the 1529 (inter-area) service P2MP LSP. 1531 Once the PE selects the transport P2MP LSP, the PE (re)originates the 1532 service A-D route. The PMSI Tunnel attribute of this route now 1533 carries the Tunnel Identifier of the selected transport LSP, with the 1534 Tunnel Type set to "Transport Tunnel". If the transport LSP carries 1535 multiple P2MP service LSPs, then the MPLS Label field in the 1536 attribute carries an upstream-assigned label assigned by the PE that 1537 is bound to the P2MP FEC of the inter-area P2MP service LSP. 1538 Otherwise, this field is set to Implicit NULL. 1540 Just as described earlier, this service A-D route MUST NOT carry the 1541 P2MP Segmented Next-Hop Extended Community. Just as described 1542 earlier, the Route Reflectors that participate in the distribution of 1543 this route need not be ABRs. 1545 14.4. Egress PE Procedures for P2MP Transport LSP 1547 When an egress PE receives and accepts an MVPN or VPLS service A-D 1548 route, if the Leaf Information Required flag in the PMSI Tunnel 1549 attribute of the received A-D route is set to 1, and the route does 1550 not carry the P2MP Segmented Next-Hop Extended Community, then the 1551 egress PE, following the "regular" MVPN or VPLS procedures associated 1552 with the received A-D route (as specified in [RFC6514] and 1553 [RFC7117]), originates a Leaf A-D route. 1555 In addition, if the Tunnel Type in the PMSI Tunnel attribute of the 1556 received service A-D route is set to "Transport Tunnel", the egress 1557 PE originates yet another Leaf A-D route. 1559 The format of the Route Key field of MCAST-VPN NLRI of this 1560 additional Leaf A-D route is the same as defined in section 6.2.2 1561 ("Leaf A-D Route for Global Table Multicast"). The Route Key field of 1562 MCAST-VPN NLRI of this route is constructed as follows: 1564 RD (8 octets) - set to 0 1566 Multicast Source Length, Multicast Source - constructed from 1567 the Source PE address part of the Tunnel Identifier carried 1568 in the PMSI Tunnel attribute of the received service S-PMSI 1569 A-D route. 1571 Multicast Group Length, Multicast Group - constructed from 1572 Local Number part of the Tunnel Identifier carried in the 1573 PMSI Tunnel attribute of the received service S-PMSI A-D 1574 route. 1576 Ingress PE IP Address is set to the Source PE address part 1577 of the Tunnel Identifier carried in the PMSI Tunnel attribute 1578 of the received service S-PMSI A-D route. 1580 The egress PE, when determining the upstream ABR, follows the 1581 procedures specified in section 6.1 ("Determining the Upstream 1582 ABR/PE/ASBR (Upstream Node)") for global table multicast. 1584 The egress PE constructs the rest of the Leaf A-D route following the 1585 procedures specified in section 6.2.3 ("Constructing the Rest of the 1586 Leaf A-D Route"). 1588 From that point on we follow the procedures used for the Leaf A-D 1589 routes for global table multicast, as outlined below. 1591 14.5. ABRs and Ingress PE procedures for P2MP Transport LSP 1593 In this section we specify ingress and egress ABRs, as well as 1594 ingress PE procedures for P2MP transport LSPs. 1596 When an egress ABR receives the Leaf A-D route, and P2MP LSP is used 1597 to instantiate the egress area segment of the inter-area transport 1598 LSP, the egress ABR will advertise into the egress area an S-PMSI A-D 1599 route. This route is constructed following the procedures in section 1600 "Global Table Multicast and S-PMSI A-D Routes". The egress PE(s) will 1601 import this route. 1603 The egress ABR will also propagate, with appropriate modifications, 1604 the received Leaf A-D route into the backbone area. This is 1605 irrespective of whether the egress area segment is instantiated using 1606 P2MP LSP or ingress replication. 1608 If P2MP LSP is used to instantiate the backbone area segment of the 1609 inter-area transport LSP, then an ingress ABR will advertise into the 1610 backbone area an S-PMSI A-D route. This route is constructed 1611 following the procedures in section 7.1.2.1 ("Global Table Multicast 1612 and S-PMSI A-D Routes"). The egress ABR(s) will import this route. 1614 The ingress ABR will also propagate, with appropriate modifications, 1615 the received Leaf A-D route into the ingress area towards the 1616 ingress/root PE. This is irrespective of whether the backbone area 1617 segment is instantiated using P2MP LSP or ingress replication. 1619 Finally, if P2MP LSP is used to instantiate the ingress area segment, 1620 the ingress PE will advertise into the ingress area an S-PMSI A-D 1621 route with the RD, multicast source, and multicast group fields being 1622 the same as those in the received Leaf A-D route. The PMSI Tunnel 1623 attribute of this route contains the identity of the intra-area P2MP 1624 LSP used to instantiate the ingress area segment, and an upstream- 1625 assigned MPLS label. The ingress ABR(s) and other PE(s) in the 1626 ingress area, if any, will import this route. The ingress PE will use 1627 the (intra-area) P2MP LSP advertised in this route for carrying 1628 traffic associated with the original service A-D route advertised by 1629 the PE. 1631 14.6. Discussion 1633 Use of inter-area transport P2MP LSPs, as described in this section, 1634 creates a level of indirection between (inter-area) P2MP service 1635 LSPs, and intra-area transport LSPs that carry the service LSPs. 1636 Rather than segmenting (inter-area) service P2MP LSPs, and then 1637 aggregating (intra-area) segments of these service LSPs into intra- 1638 area transport LSPs, this approach first aggregates multiple (inter- 1639 area) service P2MP LSPs into a single inter-area transport P2MP LSP, 1640 then segments such inter-area transport P2MP LSPs, and then 1641 aggregates (intra-area) segments of these inter-area transport LSPs 1642 into intra-area transport LSPs. 1644 On one hand this approach could result in reducing the state (and the 1645 overhead associated with maintaining the state) on ABRs. This is 1646 because instead of requiring ABRs to maintain state for individual 1647 P2MP service LSPs, ABRs would need to maintain state only for the 1648 inter-area P2MP transport LSPs. Note however, that this reduction is 1649 possible only if a single inter-area P2MP transport LSP aggregates 1650 more than one (inter-area) service LSP. In the absence of such 1651 aggregation, use of inter-area transport LSPs provides no benefits, 1652 yet results in extra overhead. And while such aggregation does allow 1653 to reduce state on ABRs, it comes at a price, as described below. 1655 As we mentioned before, aggregating multiple P2MP service LSPs into a 1656 single inter-area P2MP transport LSP requires the PE rooted at these 1657 LSPs to determine all the leaf nodes of the service LSPs to be 1658 aggregated. This means that the root PE has to track all the leaf PEs 1659 of these LSPs. In contrast, when one applies segmentation procedures 1660 directly to the P2MP service LSPs, the root PE has to track only the 1661 leaf PEs in its own IGP area, plus the ingress ABR(s). Likewise, an 1662 ingress ABR has to track only the egress ABRs. Finally, an egress ABR 1663 has to track only the leaf PEs in its own area. Therefore, while the 1664 total overhead of leaf tracking due to the P2MP service LSPs is about 1665 the same in both approaches, the distribution of this overhead is 1666 different. Specifically, when one uses inter-area P2MP transport 1667 LSPs, this overhead is concentrated on the ingress PE. When one 1668 applies segmentation procedures directly to the P2MP service LSPs, 1669 this overhead is distributed among ingress PE and ABRs. 1671 Moreover, when one uses inter-area P2MP transport LSPs, ABRs have to 1672 bear the overhead of leaf tracking for inter-area P2MP transport 1673 LSPs. In contrast, when one applies segmentation procedures directly 1674 to the P2MP service LSPs, there is no such overhead (as there are no 1675 inter-area P2MP transport LSPs). 1677 Use of inter-area P2MP transport LSPs may also result in more 1678 bandwidth inefficiency, as compared to applying segmentation 1679 procedures directly to the P2MP service LSPs. This is because with 1680 inter-area P2MP transport LSPs the ABRs aggregate segments of inter- 1681 area P2MP transport LSPs, rather than segments of (inter-area) P2MP 1682 service LSPs. To illustrate this consider the following example. 1684 Assume PE1 in Area 1 is an ingress PE, with two multicast streams, 1685 (C-S1, C-G1) and (C-S2, C-G2), originated by an MVPN site connected 1686 to PE1. Assume that PE2 in Area 2 has an MVPN site with receivers for 1687 (C-S1, C-G1), PE3 and PE4 in Area 3 have an MVPN site with receivers 1688 both for (C-S1, C-G1) and for (C-S2, C-G2). Finally, assume that PE5 1689 in Area 4 has an MVPN site with receivers for (C-S2, C-G2). 1691 When segmentation applies directly to the P2MP service LSPs then Area 1692 2 would have just one intra-area transport LSP which would carry the 1693 egress area segment of the P2MP service LSP for (C-S1, C-G1); Area 3 1694 would have just one intra-area transport LSP which would carry the 1695 egress area segments of both the P2MP service LSP for (C-S1, C-G1) 1696 and the P2MP service LSP for (C-S2, C-G2); Area 4 would have just one 1697 intra-area transport LSP which would carry the egress area segment of 1698 the P2MP service LSP for (C-S2, C-G2). Note that there is no 1699 bandwidth inefficiency in this case at all. 1701 When using inter-area P2MP transport LSPs, to achieve the same state 1702 overhead on the routers within each of the egress areas (except for 1703 egress ABRs), PE1 would need to aggregate the P2MP service LSP for 1704 (C-S1, C-G1) and the P2MP service LSP for (C-S2, C-G2) into the same 1705 inter-area P2MP transport LSP. While such aggregation would reduce 1706 state on ABRs, it would also result in bandwidth inefficiency, as (C- 1707 S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also 1708 to PE5, which has no receivers for this stream. Likewise, (C-S2, C- 1709 G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, 1710 which has no receivers for this stream. 1712 15. IANA Considerations 1714 This document defines a new BGP Extended Community called "Inter-area 1715 P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented 1716 Next-Hop Extended Community"). This may be either a Transitive 1717 IPv4-Address-Specific Extended Community or a Transitive 1718 IPv6-Address-Specific Extended Community. IANA has assigned the 1719 value 0x12 in the Transitive IPv4-Address-Specific Extended Community 1720 Sub-Types registry, and IANA has assigned the value 0x0012 in the 1721 Transitive IPv6-Address-Specific Extended Community Types registry. 1722 This document is the reference for both codepoints. IANA is 1723 requested to change in these registries the reference to the RFC 1724 number as soon as this document is published as an RFC. 1726 IANA is requested to assign a value from the PMSI Tunnel Types 1727 registry [pmsi-registry] for "Transport Tunnel" (see section 1728 "Transport Tunnel Type"). The value 0x08 is requested. 1730 16. Security Considerations 1732 Procedures described in this document are subject to similar security 1733 threats as any MPLS deployment. It is recommended that baseline 1734 security measures are considered as described in Security Framework 1735 for MPLS and GMPLS networks [RFC5920], in the mLDP specification 1736 [RFC6388] and in P2MP RSVP-TE specification [RFC3209]. 1738 17. Acknowledgements 1740 We would like to thank Loa Andersson and Qin Wu for their review and 1741 comments. 1743 18. References 1745 18.1. Normative References 1747 [RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC 1748 1997, August 1996 1750 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1751 Levels.", Bradner, RFC 2119, March 1997 1753 [RFC3209] "RSVP-TE: Extensions to RSVP for LSP Tunnels", D. Awduche, 1754 et al., RFC 3209, December 2001 1756 [RFC4360] S. Sangle et. al., "BGP Extended Communities Attribute", 1757 RFC 4360, February 2006 1759 [RFC4456] T. Bates et. al., "BGP Route Reflection: An Alternative to 1760 Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006 1762 [RFC4684] P. Marques et. al., "Constrained Route Distribution for 1763 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 1764 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 1765 November 2006 1767 [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 1768 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 1770 [RFC4761] Kompella, K., Rekhter, Y., "Virtual Private LAN Service 1771 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 1772 2007 1774 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1775 Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic 1776 Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths 1777 (LSPs)", RFC 4875, May 2007 1779 [RFC5036] "LDP Specification", Loa Andersson, et al., RFC 5036, 1780 October 2007 1782 [RFC5331] "MPLS Upstream Label Assignment and Context-Specific Label 1783 Space", Rahul Aggarwal, et al., RFC 5331, August 2008 1785 [RFC5332] "MPLS Multicast Encapsulations", T. Eckert, E. Rosen, R. 1786 Aggarwal, Y. Rekhter, RFC 5332, August 2008 1788 [RFC6368] "Internal BGP as PE-CE protocol", Pedro Marques, et al., 1789 RFC 6368, September 2011 1791 [RFC6513] "Multicast in MPLS/BGP IP VPNs", Eric Rosen, et al., RFC 1792 6513, February 2012 1794 [RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 1795 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, RFC 6514, 1796 February 2012 1798 [RFC6074] "Provisioning, Auto-Discovery, and Signaling in Layer 2 1799 Virtual Private Networks (L2VPNs)", E. Rosen, B. Davie, V. Radoaca, 1800 W. Luo, RFC 6074, January 2011 1802 [RFC6388] "Label Distribution Protocol Extensions for Point-to- 1803 Multipoint and Multipoint-to-Multipoint Label Switched Paths", 1804 Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, RFC 1805 6388, November 2011 1807 [RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric 1808 Rosen, et al., RFC 6625, May 2012 1810 [RFC7117] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, RFC 1811 7117, February 2014 1813 [pmsi-registry] L. Andersson, et al., "IANA registry for PMSI Tunnel 1814 Type code points", draft-ietf-l3vpn-pmsi-registry, work in progress 1816 18.2. Informative References 1818 [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., 1819 draft-ietf-mpls-seamless-mpls, work in progress 1821 [RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang, 1822 et al., RFC 5920, July 2010 1824 [RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et. 1825 al., RFC 7024, October 2013 1827 19. Author's Address 1829 Yakov Rekhter 1830 Juniper Networks 1831 1194 North Mathilda Ave. 1832 Sunnyvale, CA 94089 1833 Email: yakov@juniper.net 1835 Rahul Aggarwal 1836 Email: raggarwa_1@yahoo.com 1838 Thomas Morin 1839 France Telecom R & D 1840 2, avenue Pierre-Marzin 1841 22307 Lannion Cedex 1842 France 1843 Email: thomas.morin@orange-ftgroup.com 1845 Irene Grosclaude 1846 France Telecom R & D 1847 2, avenue Pierre-Marzin 1848 22307 Lannion Cedex 1849 France 1850 Email: irene.grosclaude@orange-ftgroup.com 1852 Nicolai Leymann 1853 Deutsche Telekom AG 1854 Winterfeldtstrasse 21 1855 Berlin 10781 1856 DE 1857 Email: n.leymann@telekom.de 1859 Samir Saad 1860 AT&T 1861 Email: samirsaad1@outlook.com 1863 Eric Rosen 1864 Juniper Networks 1865 Email: erosen@juniper.net