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