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