idnits 2.17.1 draft-raggarwa-mpls-seamless-mcast-03.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 402 has weird spacing: '...MUST be adver...' == Line 414 has weird spacing: '...MUST be adver...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4792 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP-MVPN' is mentioned on line 446, but not defined == Missing Reference: 'VPLS-P2MP' is mentioned on line 446, but not defined == Missing Reference: 'RFC5331' is mentioned on line 199, but not defined == Missing Reference: 'RFC4360' is mentioned on line 227, but not defined == Missing Reference: 'BGP-VPLS' is mentioned on line 306, but not defined == Missing Reference: 'VPLS-AD' is mentioned on line 306, but not defined == Missing Reference: 'RFC1997' is mentioned on line 623, but not defined == Missing Reference: 'RFC 5332' is mentioned on line 808, but not defined == Missing Reference: 'MVPN-WILDCARD-SPMSI' is mentioned on line 1013, but not defined == Unused Reference: 'RFC5332' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'MVPN-BGP' is defined on line 1213, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 16 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 Expiration Date: September 2011 5 R. Aggarwal 6 Juniper Networks 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 March 14, 2011 22 Inter-Area P2MP Segmented LSPs 24 draft-raggarwa-mpls-seamless-mcast-03.txt 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that other 33 groups may also distribute working documents as Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright and License Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Abstract 75 This document describes procedures for building inter-area point-to- 76 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 77 into intra-area segments and using BGP as the inter-area routing and 78 label distribution protocol. Within each IGP area the intra-area 79 segments are either carried over intra-area P2MP LSPs, using P2MP LSP 80 hierarchy, or instantiated using ingress replication. The intra-area 81 P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress 82 replication is used in an IGP area then MP2P LDP LSPs or P2P RSVP-TE 83 LSPs may be used in the IGP area. The applications/services that use 84 such an inter-area service LSP may be BGP MVPN, VPLS multicast or 85 Internet multicast over MPLS. 87 Table of Contents 89 1 Specification of requirements ......................... 4 90 2 Introduction .......................................... 4 91 3 General Assumptions and Terminology ................... 5 92 4 Inter-area P2MP Segmented Next-Hop Extended Community . 6 93 5 Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 6 94 5.1 BGP MVPN .............................................. 6 95 5.2 BGP VPLS or LDP VPLS with BGP A-D ..................... 7 96 5.3 Internet Multicast .................................... 8 97 6 Egress PE Procedures .................................. 9 98 6.1 Determining the Upstream ABR/PE/ASBR .................. 9 99 6.2 Originating a Leaf Auto-Discovery Route ............... 10 100 6.2.1 Leaf A-D Route for MVPN and VPLS ...................... 10 101 6.2.2 Leaf A-D Route for Internet Multicast ................. 11 102 6.2.3 Constructing the Rest of the Leaf A-D Route ........... 12 103 6.3 PIM-SM in ASM mode for Internet Multicast ............. 12 104 6.3.1 Option 1 .............................................. 12 105 6.3.1.1 Originating Source Active auto-discovery routes ....... 13 106 6.3.1.2 Receiving BGP Source Active auto-discovery route by PE ....13 107 6.3.1.3 Handling (S, G, RPTbit) state ......................... 14 108 6.3.2 Option 2 .............................................. 14 109 6.3.2.1 Originating Source Active auto-discovery routes ....... 14 110 6.3.2.2 Receiving BGP Source Active auto-discovery route ...... 15 111 6.3.2.3 Pruning Sources off the Shared Tree ................... 15 112 6.3.2.4 More on handling (S, G, RPTbit) state ................. 15 113 7 Egress ABR Procedures ................................. 16 114 7.1 P2MP LSP as the Intra-Area LSP in the Egress Area ..... 18 115 7.1.1 RD of the received Leaf-AD route is not zero or all ones ..18 116 7.1.2 RD of the received Leaf A-D route is zero or all ones . 19 117 7.1.2.1 Internet Multicast and S-PMSI A-D Routes .............. 19 118 7.1.2.2 Internet Multicast and Wildcard S-PMSI A-D Routes ..... 19 119 7.1.3 Internet Multicast and the Expected Upstream Node ..... 19 120 7.1.4 P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 20 121 7.1.5 P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 20 122 7.2 Ingress Replication in the Egress Area ................ 20 123 8 Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 21 124 8.1 P2MP LSP as the Intra-Area LSP in the Backbone Area ... 21 125 8.2 Ingress Replication in the Backbone Area .............. 22 126 9 Ingress PE/ASBR Procedures ............................ 22 127 9.1 P2MP LSP as the intra-area LSP in the ingress area .... 23 128 9.2 Ingress Replication in the Ingress Area ............... 23 129 10 Common Tunnel Type in the Ingress and Egress Areas .... 24 130 11 Placement of Ingress and Egress PEs ................... 24 131 12 Data Plane ............................................ 25 132 12.1 Data Plane Procedures on an ABR ....................... 25 133 12.2 Data Plane Procedures on an Egress PE ................. 25 134 12.3 Data Plane Procedures on an Ingress PE ................ 26 135 12.4 Data Plane Procedures on Transit Routers .............. 27 136 13 IANA Considerations ................................... 27 137 14 Security Considerations ............................... 27 138 15 References ............................................ 27 139 15.1 Normative References .................................. 27 140 15.2 Informative References ................................ 28 141 16 Author's Address ...................................... 28 143 1. Specification of requirements 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. Introduction 151 This document describes procedures for building inter-area point-to- 152 multipoint (P2MP) segmented service LSPs by partitioning such LSPs 153 into intra-area segments and using BGP as the inter-area routing and 154 label distribution protocol. Within each IGP area the intra-area 155 segments are either carried over intra-area P2MP LSPs, potentially 156 using P2MP LSP hierarchy, or instantiated using ingress replication. 157 The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP 158 mLDP. If ingress replication is used in an IGP area then MP2P LDP or 159 P2P RSVP-TE LSPs may be used in the IGP area. The 160 applications/services that use such an inter-area service LSP may be 161 BGP MVPN, VPLS multicast or Internet multicast over MPLS. 163 The primary use case of such segmented P2MP service LSPs is when the 164 PEs are in different areas but in the same AS and thousands or more 165 of PEs require P2MP connectivity. For instance this may be the case 166 when MPLS is pushed further to the metro edge and the metros are in 167 different IGP areas. This may also be the case when a Service 168 Provider's network comprises multiple IGP areas in a single 169 Autonomous System, with a large number of PEs. Seamless MPLS is the 170 industry term to address this case [SEAMLESS-MPLS]. Thus one of the 171 applicabilities of this document is that it describes the multicast 172 procedures for seamless MPLS. 174 It is to be noted that [BGP-MVPN], [VPLS-P2MP] already specify 175 procedures for building segmented inter-AS P2MP service LSPs. This 176 document complements those procedures as it extends the segmented 177 P2MP LSP model such that it is applicable to inter-area P2MP service 178 LSPs as well. Infact an inter-AS deployment could use inter-AS 179 segmented P2MP LSPs as specified in [BGP-MVPN, VPLS-P2MP] where each 180 intra-AS segment is constructed using inter-area segmented P2MP LSPs 181 as specified in this document. 183 3. General Assumptions and Terminology 185 This document assumes BGP is used as an inter-area routing and label 186 distribution protocol for the unicast IPv4 /32 or IPv6 /128 routes 187 for the PEs. This document also assumes ABRs act as Route Reflectors 188 (RR) for these routes. 190 Within an AS a P2MP service LSP is partitioned into 3 segments: 191 ingress area segment, backbone area segment, and egress area segment. 192 Within each area a segment is carried over an intra-area P2MP LSP or 193 instantiated using ingress replication. 195 When intra-area P2MP LSPs are used to instantiate the intra-area 196 segments there could be either 1:1 or n:1 mapping between intra-area 197 segments of the inter-area P2MP service LSP and a given intra-area 198 P2MP LSP. The latter is realized using P2MP LSP hierarchy with 199 upstream-assigned labels [RFC5331]. For simplicity we assume that 200 P2MP LSP hierarchy is used even with 1:1 mapping, in which case the 201 upstream-assigned label could be an implicit NULL. 203 When intra-area segments of the inter-area P2MP service LSP are 204 instantiated using ingress replication, then multiple such segments 205 may be carried in the same P2P RSVP-TE or MP2P LDP LSP. This can be 206 achieved using downstream-assigned labels alone. 208 The ingress area segment of a P2MP service LSP is rooted at a PE (or 209 at an ASBR in the case where the P2MP service LSP spans multiple 210 ASes). The leaves of this segment are other PEs/ASBRs and ABRs in 211 the same area as the root PE. The backbone area segment is rooted at 212 an ABR that is connected to the ingress area (ingress ABR), and has 213 as its leaves ABRs that are connected to the egress area(s) or PEs in 214 the backbone area. The egress area segment is rooted at an ABR in 215 the egress area (egress ABR), and has as its leaves PEs and ASBR in 216 that egress area (the latter covers the case where the P2MP service 217 LSP spans multiple ASes). Note that for a given P2MP service LSP 218 there may be more than one backbone segment, each rooted at its own 219 ingress ABR, and more than one egress area segment, each rooted at 220 its own egress ABR. 222 4. Inter-area P2MP Segmented Next-Hop Extended Community 224 This document defines a new BGP Extended Community "Inter-area P2MP 225 Next-Hop" extended community. This is an IP address specific Extended 226 Community, of an extended type and is transitive across AS boundaries 227 [RFC4360]. 229 A PE or an ABR or an ASBR constructs the Inter-area P2MP Segmented 230 Next-Hop Extended Community as follows: 232 - The Global Administrator field MUST be set to an IP address of 233 the PE or ASBR or ABR that originates or advertises the route, 234 which carries the P2MP Next-Hop Extended Community. For example 235 this address may be the loopback address or the PE, ASBR or ABR 236 that advertises the route. 238 - The Local Administrator field MUST be set to 0. 240 The detailed usage of this extended community is described in the 241 following sections. 243 5. Discovering the P2MP FEC of the Inter-Area P2MP Service LSP 245 The P2MP FEC identifies the inter-area P2MP service LSP. The egress 246 PEs need to learn this P2MP FEC in order to initiate the creation of 247 the egress area segment of the P2MP inter-area service LSP. 249 The P2MP FEC of the inter-area P2MP LSP is learned by the egress PEs 250 either by configuration, or based on the application-specific 251 procedures (e.g., MVPN-specific procedures, VPLS-specific 252 procedures). 254 5.1. BGP MVPN 256 Egress PEs discover the P2MP FEC of the service LSPs used by BGP MVPN 257 using the I-PMSI or S-PMSI A-D routes that are originated by the 258 ingress PEs or ASBRs following the procedures of [BGP-MVPN], along 259 with modifications as described in this document. The NLRI of such 260 routes encodes the P2MP FEC. The procedures in this document require 261 that at least one ABR in a given IGP area act as Route Reflector for 262 MVPN auto-discovery (A-D) routes. 264 The "Leaf Information Required" flag MUST be set in the P-Tunnel 265 attribute carried in such routes, when originated by the ingress PEs 266 or ASBRs. Before any Leaf auto discovery route is advertised by a PE 267 or ABR in the same area, as described in the following sections, an 268 I-/S-PMSI auto-discovery route is advertised either with an explicit 269 Tunnel Type and Tunnel Identifier in the PMSI Tunnel Attribute, if 270 the Tunnel Identifier has already been assigned, or with a special 271 Tunnel Type of "No tunnel information present" otherwise. When the 272 I/S-PMSI routes are re-advertised by an ABR, "Leaf Information 273 Required" flag MUST be set in the P-Tunnel attribute present in the 274 routes. 276 Note that the procedures in the above paragraph apply when intra-area 277 segments are realized by either intra-area P2MP LSPs or by ingress 278 replication. 280 When BGP MVPN I-PMSI or S-PMSI A-D routes are advertised or 281 propagated to signal Inter-area P2MP service LSPs, they MUST carry 282 the Inter-area P2MP Segmented Next-Hop Extended Community. This 283 Extended Community MUST be included in the I/S-PMSI A-D route by the 284 PE or ASBR that originates such a route and the Global Administrator 285 field MUST be set to the advertising PE or ASBR's IP address. This 286 Extended Community MUST also be included by ABRs as they re-advertise 287 such routes. An ABR MUST set the Global Administrator field of the 288 P2MP Segmented Next-Hop Extended Community to its own IP address. 289 This allows ABRs and PEs/ASBRs to follow the procedures in this 290 document when these procedures differ from those in [BGP-MVPN]. 292 To avoid requiring ABRs to participate in the propagation of C- 293 multicast routes, this document requires ABRs NOT to modify BGP Next 294 Hop when re-advertising Inter-AS I-PMSI A-D routes. For consitancy 295 this document requires ABRs to NOT modify BGP Next-Hop when re- 296 advertising both Intra-AS and Inter-AS I/S-PMSI A-D routes. The 297 egress PEs may advertise the C-multicast routes to RRs that are 298 different than the ABRs. However ABRs still can be configured to be 299 the Route Reflectors for C-multicast routes, in which case they will 300 participate in the propagation of C-multicast routes. 302 5.2. BGP VPLS or LDP VPLS with BGP A-D 304 Egress PEs discover the P2MP FEC of the service LSPs used by VPLS, 305 using the VPLS A-D routes that are originated by the ingress PEs 306 [BGP-VPLS, VPLS-AD] or S-PMSI A-D routes that are originated by the 307 ingress PE [VPLS-P2MP]. The NLRI of such routes encodes the P2MP FEC. 308 The "Leaf Information Required" flag MUST be set in the P-Tunnel 309 attribute carried in such routes. Before any Leaf auto discovery 310 route is advertised by a PE or ABR in its own area, as described in 311 the following sections, an VPLS/S-PMSI autodiscovery route is 312 advertised either with an explicit Tunnel Type and Tunnel Identifier 313 in the PMSI Tunnel Attribute, if the Tunnel Identifier has already 314 been assigned, or with a special Tunnel Type of "No tunnel 315 information present" otherwise. 317 When VPLS A-D or S-PMSI A-D routes are advertised or propagated to 318 signal Inter-area P2MP service LSPs, they MUST carry the Inter-area 319 P2MP Segmented Next-Hop Extended Community. This Extended Community 320 MUST be included in the A-D route by the PE or ASBR that originates 321 such a route and the Global Administrator field MUST be set to the 322 advertising PE or ASBR's IP address. This Extended Community MUST 323 also be included by ABRs as they re-advertise such routes. An ABR 324 MUST set the Global Administrator field of the P2MP Segmented Next- 325 Hop Extended Community to its own IP address. This allows ABRs and 326 PEs/ASBRs to follow the procedures in this document when these 327 procedures differ from those in [VPLS-P2MP]. 329 Note that the procedures in the above paragraph apply when intra-area 330 segments are realized by either intra-area P2MP LSPs or by ingress 331 replication. 333 The procedures in this document require that at least one ABR in a 334 given area act as Route Reflector for MVPN auto-discovery (A-D) 335 routes. These ABRs/RRs MUST NOT modify BGP Next Hop when re- 336 advertising these A-D routes. 338 5.3. Internet Multicast 340 This section describes how the egress PEs discover the P2MP FEC when 341 the application is internet multicast. 343 In the case where Internet multicast uses PIM-SM in ASM mode the 344 following assumes that an inter-area P2MP service LSP could be used 345 to either carry traffic on a shared (*,G), or a source (S,G) tree. 347 An egress PE learns the (S/*, G) of a multicast stream as a result of 348 receiving IGMP or PIM messages on one of its IP multicast interfaces. 349 This (S/*, G) forms the P2MP FEC of the inter-area P2MP service LSP. 350 For each (S/*,G) for which an inter-area P2MP service LSP is 351 instantiated, there may exist a distinct inter-area P2MP service LSP 352 or multiple inter-area P2MP service LSPs may be aggregated using a 353 wildcard (*, *) S-PMSI. 355 Note that this document does not require the use of (*, G) Inter-area 356 P2MP service LSPs when Internet multicast uses PIM-SM in ASM mode. 357 Infact PIM-SM in ASM mode may be supported entirely by using (S, G) 358 trees alone. 360 6. Egress PE Procedures 362 This section describes egress PE procedures for constructing 363 segmented inter-area P2MP LSP. The procedures in this section apply 364 irrespective of whether the egress PE is in a leaf IGP area, or the 365 backbone area or even in the same IGP area as the ingress PE/ASBR. 367 In order to support Internet Multicast an egress PE MUST auto- 368 configure an import Route Target with the global administrator field 369 set to the AS of the PE and the local administrator field set to 0. 371 Once an egress PE discovers the P2MP FEC of an inter-area segmented 372 P2MP service LSP, it MUST propagate this P2MP FEC in BGP in order to 373 construct the segmented inter-area P2MP service LSP. This propagation 374 uses BGP Leaf auto-discovery routes. 376 6.1. Determining the Upstream ABR/PE/ASBR 378 The egress PE discovers the P2MP FEC of an inter-area P2MP Segmented 379 Service LSP as described in section 5. When an egress PE discovers 380 this P2MP FEC it MUST first determine the upstream node to reach such 381 a FEC. If the egress PE is in the egress area and the ingress PE is 382 not in the that egress area, then this upstream node would be the 383 egress ABR. If the egress PE is in the backbone area and the ingress 384 PE is not in the backbone area, then this upstream node would be the 385 ingress ABR. If the egress PE is in the same area as the ingress PE 386 then this upstream node would be the ingress PE. 388 If the application is MVPN or VPLS then the upstream node's IP 389 address is the IP address determined from the Global Administrator 390 field of the Inter-area P2MP Segmented Next-hop Extended Community. 391 As described in section 5 this Extended Community MUST be carried in 392 the MVPN or VPLS A-D route from which the P2MP FEC of the inter-area 393 P2MP Segmented Service LSP is determined. 395 If the application is Internet Multicast then the unicast routes to 396 multicast sources/RPs SHOULD carry the VRF Route Import Extended 397 Community [BGP-MVPN] where the IP address in the Global Administrator 398 field is set to the IP address of the PE or ASBR advertising the 399 unicast route. The Local Administrator field of this community MUST 400 be set to 0. If it is not desirable to advertise the VRF Route Import 401 Extended Community in unicast routes, then unicast routes to 402 multicast sources/RPs MUST be advertised using the multicast SAFI 403 i.e. SAFI 2 and the VRF Route Import Extended Community MUST be 404 carried in such routes. 406 Further if the application is internet multicast then the BGP unicast 407 routes that advertise the route to the IP address of PEs or ASBRs or 408 ABRs SHOULD carry the Inter-area P2MP Segmented Next-Hop Extended 409 Community where the IP address in the Global Administrator field is 410 set to the IP address of the PE or ASBR or ABR advertising the 411 unicast route. The Local Administrator field of this community MUST 412 be set to 0. If it is not desirable to advertise the P2MP Segmented 413 Import Extended Community in BGP unicast routes, then unicast routes 414 to ABRs, ASBRs or PEs MUST be advertised using the multicast SAFI 415 i.e. SAFI 2 and the Inter-area P2MP Segmented Next-hop Extended 416 Community MUST be carried in such routes. The procedures for handling 417 the next-hop of SAFI 2 routes are the same as those of handling 418 regular Unicast routes and follow [SEAMLESS-MPLS]. 420 In order to determine the upstream node address the egress PE first 421 determines the ingress PE. The egress PE determines the best route to 422 reach S/RP. The ingress PE address is the IP address determined from 423 the Global Administrator field of the VRF Route Import Extended 424 Community, that is present in this route. The egress PE now finds the 425 best unicast route to reach the ingress PE. The upstream node address 426 is the IP address determined from the Global Administrator field of 427 the Inter-area P2MP Segmented Next-Hop Extended Community, that is 428 present in this route. 430 6.2. Originating a Leaf Auto-Discovery Route 432 If the P2MP FEC was derived from a MVPN or VPLS A-D route then the 433 egress PE MUST originate a Leaf auto-discovery (A-D) route if the 434 MVPN or VPLS A-D route carries a P-Tunnel Attribute with the "Leaf 435 Information Required" flag set. 437 If the P2MP FEC was derived from an Internet Multicast S/*, G and the 438 upstream node's address is not the same as the egress PE, then the 439 egress PE MUST originate a Leaf auto-discovery (A-D) route. 441 6.2.1. Leaf A-D Route for MVPN and VPLS 443 If the P2MP FEC was derived from MVPN or VPLS A-D routes then the 444 Route Key field of the Leaf A-D route contains the NLRI of the A-D 445 route from which the P2MP FEC was derived. This follows procedures 446 for constructing Leaf A-D routes described in [BGP-MVPN, VPLS-P2MP]. 448 6.2.2. Leaf A-D Route for Internet Multicast 450 If the application is internet multicast then the MCAST-VPN NLRI of 451 the Leaf A-D route is constructed as follows: 453 The Route Key field of MCAST-VPN NLRI has the following format: 455 +-----------------------------------+ 456 | RD (8 octets) | 457 +-----------------------------------+ 458 | Multicast Source Length (1 octet) | 459 +-----------------------------------+ 460 | Multicast Source (Variable) | 461 +-----------------------------------+ 462 | Multicast Group Length (1 octet) | 463 +-----------------------------------+ 464 | Multicast Group (Variable) | 465 +-----------------------------------+ 466 | Ingress PE's IP address | 467 +-----------------------------------+ 469 RD is set to 0 for (S,G) state and all 1s for (*,G) state, Multicast 470 Source is set to S for (S,G) state or RP for (*,G) state, Multicast 471 Group is set to G, Multicast Source Length and Multicast Group Length 472 is set to either 4 or 16 (depending on whether S/RP and G are IPv4 or 473 IPv6 addresses). 475 The Ingress PE's IP address is determined as described in the section 476 "Determining the Upstream ABR/PE/ASBR". 478 The Originating Router's IP address field of MCAST-VPN NLRI is set to 479 the address of the local PE (PE that originates the route). 481 Thus the entire MCAST-VPN NLRI of the route has the following format: 483 +-----------------------------------+ 484 | RD (8 octets) | 485 +-----------------------------------+ 486 | Multicast Source Length (1 octet) | 487 +-----------------------------------+ 488 | Multicast Source (Variable) | 489 +-----------------------------------+ 490 | Multicast Group Length (1 octet) | 491 +-----------------------------------+ 492 | Multicast Group (Variable) | 493 +-----------------------------------+ 494 | Ingress PE's IP address | 495 +-----------------------------------+ 496 | Originating Router's IP address | 497 +-----------------------------------+ 499 When the PE deletes (S,G)/(*,G) state that was created as a result of 500 receiving PIM or IGMP messages on one of its IP multicast interfaces, 501 if the PE previousely originated a Leaf auto-discovery route for that 502 state, then the PE SHOULD withdraw that route. 504 6.2.3. Constructing the Rest of the Leaf A-D Route 506 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 507 be set to the same IP address as the one carried in the Originating 508 Router's IP Address field of the route. 510 When Ingress Replication is used to instantiate the egress area 511 segment then the Leaf A-D route MUST carry a downstream assigned 512 label in the P-Tunnel Attribute where the P-Tunnel type is set to 513 Ingress Replication. A PE MUST assign a distinct MPLS label for each 514 Leaf A-D route originated by the PE. 516 To constrain distribution of this route, the originating PE 517 constructs an IP-based Route Target community by placing the IP 518 address of the upstream node in the Global Administrator field of the 519 community, with the Local Administrator field of this community set 520 to 0. The originating PE then adds this Route Target Extended 521 Community to this Leaf auto-discovery route. The upstream node's 522 address is as determined in section 6.1. 524 The PE then advertises this route to the upstream node. 526 6.3. PIM-SM in ASM mode for Internet Multicast 528 This specification allows two options for supporting Internet 529 Multicast with PIM-SM in ASM mode. The first option does not transit 530 IP multicast shared trees over the MPLS network. The second option 531 does transit shared trees over the MPLS network and relies on shared 532 tree to source tree switchover. 534 6.3.1. Option 1 536 This option does not transit IP multicast shared trees over the MPLS 537 network. Therefore, when an (egress) PE creates (*, G) state (as a 538 result of receiving PIM messages on one of its IP multicast 539 interfaces), the PE does not propagate this state using Leaf A-D 540 routes. 542 6.3.1.1. Originating Source Active auto-discovery routes 544 Whenever as a result of receiving PIM Register or MSDP messages an RP 545 discovers a new multicast source the RP SHOULD originate a BGP Source 546 Active auto-discovery route. Similarly whenever as a result of 547 receiving MSDP messages a PE, that is not configured as a RP, 548 discovers a new multicast source the PE SHOULD originate a BGP Source 549 Active auto-discovery route. The BGP Source Active auto-discovery 550 route carries a single MCAST-VPN NLRI constructed as follows: 552 + The RD in this NLRI is set to 0. 554 + The Multicast Source field MUST be set to S. The Multicast 555 Source Length field is set appropriately to reflect this. 557 + The Multicast Group field MUST be set to G. The Multicast Group 558 Length field is set appropriately to reflect this. 560 To constrain distribution of the Source Active auto-discovery route 561 to the AS of the advertising RP this route SHOULD carry the NO_EXPORT 562 Community ([RFC1997]). 564 Using the normal BGP procedures the Source Active auto-discovery 565 route is propagated to all other PEs within the AS. 567 Whenever the RP discovers that the source is no longer active, the RP 568 MUST withdraw the Source Active auto-discovery route, if such a route 569 was previousely advertised by the RP. 571 6.3.1.2. Receiving BGP Source Active auto-discovery route by PE 573 When as a result of receiving PIM messages on one of its IP multicast 574 interfaces an (egress) PE creates in its Tree Information Base (TIB) 575 a new (*, G) entry with a non-empty outgoing interface list that 576 contains one or more IP multicast interfaces, the PE MUST check if it 577 has any Source Active auto-discovery routes for that G. If there is 578 such a route, S of that route is reachable via an MPLS interface, and 579 the PE does not have (S, G) state in its TIB for (S, G) carried in 580 the route, then the PE originates a Leaf A-D routes carrying that (S, 581 G), as specified in Section "Leaf A-D Route for Internet Multicast". 583 When an (egress) PE receives a new Source Active auto-discovery 584 route, the PE MUST check if its TIB contains an (*, G) entry with the 585 same G as carried in the Source Active auto-discovery route. If such 586 an entry is found, S is reachable via an MPLS interface, and the PE 587 does not have (S, G) state in its TIB for (S, G) carried in the 588 route, then the PE originates a Leaf A-D routes carrying that (S, G), 589 as specified in Section "Leaf A-D Route for Internet Multicast". 591 6.3.1.3. Handling (S, G, RPTbit) state 593 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 594 from receiving PIM messages on one of its IP multicast interfaces 595 does not result in any BGP actions by the PE. 597 6.3.2. Option 2 599 This option does transit IP multicast shared trees over the MPLS 600 network. Therefore, when an (egress) PE creates (*, G) state (as a 601 result of receiving PIM messages on one of its IP multicast 602 interfaces), the PE does propagate this state using Leaf A-D routes. 604 6.3.2.1. Originating Source Active auto-discovery routes 606 Whenever a PE creates an (S, G) state as a result of receiving Leaf 607 A-D routes associated with Internet multicast service, if S is 608 reachable via one of the IP multicast capable interfaces, and the PE 609 determines that G is in the PIM-SM in ASM mode range, the PE MUST 610 originate a BGP Source Active auto-discovery route. The route carries 611 a single MCAST-VPN NLRI constructed as follows: 613 + The RD in this NLRI is set to 0. 615 + The Multicast Source field MUST be set to S. The Multicast 616 Source Length field is set appropriately to reflect this. 618 + The Multicast Group field MUST be set to G. The Multicast Group 619 Length field is set appropriately to reflect this. 621 To constrain distribution of the Source Active auto-discovery route 622 to the AS of the advertising PE this route SHOULD carry the NO_EXPORT 623 Community ([RFC1997]). 625 Using the normal BGP procedures the Source Active auto-discovery 626 route is propagated to all other PEs within the AS. 628 Whenever the PE deletes the (S, G) state that was previously created 629 as a result of receiving a Leaf A-D route for (S, G), the PE that 630 deletes the state MUST also withdraw the Source Active auto-discovery 631 route, if such a route was advertised when the state was created. 633 6.3.2.2. Receiving BGP Source Active auto-discovery route 635 Procedures for receiving BGP Source Active auto-discovery routes are 636 the same as with Option 1. 638 6.3.2.3. Pruning Sources off the Shared Tree 640 If after receiving a new Source Active auto-discovery route for (S,G) 641 a PE determines that (a) it has the (*, G) entry in its TIB, (b) the 642 incoming interface list (iif) for that entry contains one of the IP 643 interfaces, (c) a MPLS LSP is in the outgoing interface list (oif) 644 for that entry, and (d) the PE does not originate a Leaf A-D route 645 for (S,G), then the PE MUST transition the (S,G,rpt) downstream state 646 to the Prune state. [Conceptually the PIM state machine on the PE 647 will act "as if" it had received Prune(S,G,Rpt) from some other PE, 648 without actually having received one.] Depending on the (S,G,rpt) 649 state on the iifs, this may result in the PE using PIM procedures to 650 prune S off the Shared (*,G) tree. 652 Transitioning the state machine to the Prune state SHOULD be done 653 after a delay that is controlled by a timer. The value of the timer 654 MUST be configurable. The purpose of this timer is to ensure that S 655 is not pruned off the shared tree until all PEs have had time to 656 receive the Source Active A-D route for (S,G). 658 The PE MUST keep the (S,G,rpt) downstream state machine in the Prune 659 state for as long as (a) the outgoing interface list (oif) for (*, G) 660 contains a MPLS LSP, and (b) the PE has at least one Source Active 661 auto-discovery route for (S,G), and (c) the PE does not originate the 662 Leaf A-D route for (S,G). Once either of these conditions become no 663 longer valid, the PE MUST transition the (S,G,rpt) downstream state 664 machine to the NoInfo state. 666 Note that except for the scenario described in the first paragraph of 667 this section, in all other scenarios relying solely on PIM procedures 668 on the PE is sufficient to ensure the correct behavior when pruning 669 sources off the shared tree. 671 6.3.2.4. More on handling (S, G, RPTbit) state 673 Creation and deletion of (S, G, RPTbit) state on a PE that resulted 674 from receiving PIM messages on one of its IP multicast interfaces 675 does not result in any BGP actions by the PE. 677 7. Egress ABR Procedures 679 This section describes Egress ABR Procedures for constructing 680 segmented inter-area P2MP LSP. 682 When an egress ABR receives a Leaf auto-discovery route and the Route 683 Target extended community carried by the route contains the IP 684 address of this ABR, then the following procedures will be executed. 686 If the RD of the received A-D route is not set to all 0s or all 1s, 687 then the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has 688 the same value as the Route Key field of the received Leaf A-D route. 689 If such a matching route is found then the Leaf A-D route MUST be 690 accepted else it MUST be discarded. If the Leaf A-D route is accepted 691 and if its the first Leaf A-D route update for the Route Key field in 692 the route or the withdrawl of the last Leaf A-D route for the Route 693 Key field then the following procedures will be executed. 695 If the RD of the received A-D route is set to all 0s or all 1s then 696 the received Leaf A-D route is for Internet Multicast. In that case 697 for the following procedure the Route Prefix is set to all fields of 698 the Route Key minus the Ingress PE address. If this is the first Leaf 699 A-D route update for this Route Prefix or the withdrawl of the last 700 Leaf A-D route for the Route Prefix then the following procedures 701 will be executed. 703 While generating a Leaf A-D route update, the egress ABR originates a 704 Leaf A-D route, whose MCAST-VPN NLRI is constructed as follows. 706 The Route Key field of MCAST-VPN NLRI is the same as the Route Key 707 field of MCAST-VPN NLRI of the received Leaf A-D route. The 708 Originating Router's IP address field of MCAST-VPN NLRI is set to the 709 address of the local ABR (the ABR that originates the route). In 711 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 712 be set to the same IP address as the one carried in the Originating 713 Router's IP Address field of the route. 715 To constrain distribution of this route the originating egress ABR 716 constructs an IP-based Route Target community by placing the IP 717 address of the upstream node in the Global Administrator field of the 718 community, with the Local Administrator field of this community set 719 to 0, and sets the Extended Communities attribute of this Leaf auto- 720 discovery route to that community. 722 The upstream node's IP address is the IP address determined from the 723 Global Administrator field of the Inter-area P2MP Segmented Next-hop 724 Extended Community, where this Extended Community is obtained as 725 follows. When the Leaf A-D route is for MVPN or VPLS then this 726 Extended Community is the one included in the I-S/PMSI A-D route that 727 matches the Leaf A-D route. When the Leaf A-D route is for Internet 728 Multicast then this Extended Community is obtained from the best 729 unicast route to the Ingress PE. The Ingress PE address is 730 determined from the received Leaf A-D route. The best unicast route 731 MUST first be determined from multicast SAFI i.e., SAFI 2 routes, if 732 present. 734 The ABR then advertises this Leaf A-D route to the upstream node 735 in the backbone area. 737 Mechanisms specific in RFC4684 for constrained BGP route distribution 738 can be used along with this specification to ensure that only the 739 needed PE/ABR will have to process a said Leaf auto-discovery route. 741 When Ingress Replication is used to instantiate the backbone area 742 segment then the Leaf A-D route originated by the egress ABR MUST 743 carry a downstream assigned label in the P-Tunnel Attribute where the 744 P-Tunnel type is set to Ingress Replication. An ABR MUST assign a 745 distinct MPLS label for each Leaf A-D route originated by the ABR. 747 In order to support Internet Multicast an egress ABR MUST auto- 748 configure an import Route Target with the global administrator field 749 set to the AS of the ABR and the local administrator field set to 0. 751 When the Leaf A-D route is for Internet Multicast and if the 752 following conditions hold true: 754 - Its not the first Leaf A-D route for the Route Prefix, 755 where the Route Prefix is determined as described above 757 - The set of ingress PEs associated with the Route Prefix 758 changes as a result of the new Leaf A-D route. 760 - The ABR determines based on local policy to propagate 761 the Leaf A-D route towards a different ingress PE than 762 the one to which the Leaf A-D route is being currently 763 propagated. 765 Then the egress ABR MUST originate the Leaf A-D route as described in 766 this section. 768 If the received Leaf A-D route is the last Leaf A-D route for the 769 Route Key for MVPN or VPLS or for the Route Prefix, as described 770 above, for Internet Multicast, then the ABR must withdraw the 771 previously advertised Leaf A-D route. 773 7.1. P2MP LSP as the Intra-Area LSP in the Egress Area 775 This section describes procedures for using intra-area P2MP LSPs in 776 the egress area. The procedures that are common to both P2MP RSVP-TE 777 and P2MP LDP are described first, followed by procedures that are 778 specific to the signaling protocol. 780 When P2MP LSPs are used as the intra-area LSPs, note that an existing 781 intra-area P2MP LSP may be used solely for a particular inter-area 782 P2MP service LSP, or for other inter-area P2MP service LSPs as well. 783 The choice between the two options is purely local to the egress ABR. 784 The first option provides one-to-one mapping between inter-area P2MP 785 service LSPs and intra-area P2MP LSPs; the second option provides 786 many-to-one mapping, thus allowing to aggregate forwarding state. 788 7.1.1. RD of the received Leaf-AD route is not zero or all ones 790 When the RD of the received Leaf A-D route is not set to zero or all 791 ones then the ABR MUST re-advertise in the egress area the MVPN/VPLS 792 A-D route, that matches the Leaf A-D route to signal the binding of 793 the intra-area P2MP LSP to the inter-area P2MP service LSP. This must 794 be done ONLY if a) such a binding hasn't already been advertised or 795 b) The binding has changed. The re-advertised route MUST carry the 796 Inter-area P2MP Segmented Next-Hop Extended Community. 798 The PMSI Tunnel attribute of the re-advertised route specifies either 799 an intra-area P2MP RSVP-TE LSP or an intra-area P2MP LDP LSP rooted 800 at the ABR and MUST also carry an upstream assigned MPLS label. The 801 upstream-assigned MPLS label MUST be set to implicit NULL if the 802 mapping between the inter-area P2MP service LSP and the intra-area 803 P2MP LSP is one-to-one. If the mapping is many-to-one the intra-area 804 segment of the inter-area P2MP service LSP (referred to as the 805 "inner" P2MP LSP) is constructed by nesting the inter-area P2MP 806 service LSP in an intra-area P2MP LSP (referred to as the "outer" 807 intra-area P2MP LSP), by using P2MP LSP hierarchy based on upstream- 808 assigned MPLS labels [RFC 5332]. 810 If segments of multiple MVPN or VPLS S-PMSI service LSPs are carried 811 over a given intra-area P2MP LSP, each of these segments MUST carry a 812 distinct upstream-assigned label, even if all these service LSPs are 813 for (C-S/*, C-G/*)s from the same MVPN/VPLS. Therefore, an ABR 814 maintains an LFIB state for each of the (C-S/*, C-G/*)s carried over 815 S-PMSIs traversting this ABR (that applies to both the ingress and 816 the egress ABRs). 818 7.1.2. RD of the received Leaf A-D route is zero or all ones 820 When the RD of the received Leaf A-D route is set to zero or all ones 821 then this is the case of inter-area P2MP service LSP being associated 822 with the Internet multicast service. The procedures for this are 823 described below. 825 7.1.2.1. Internet Multicast and S-PMSI A-D Routes 827 This section applies only if it is desirable to send a particular 828 Internet Multicast flow to only those egress PEs that have receivers 829 in a particular (S, G) or a particular (*, G) multicast flow. 831 The egress ABR MUST originate a S-PMSI A-D route. The PMSI Tunnel 832 attribute of the route MUST contain the identity of the intra-area 833 P2MP LSP and an upstream assigned MPLS label. The RD, Multicast 834 Source Length, Multicast Source, Multicast Group Length (1 octet), 835 and Multicast Group fields of the NLRI of this route are the same as 836 of the Leaf A-D route. The egress ABR MUST advertise this route into 837 the backbone area. The Route Target of this route is an AS specific 838 route-target with the AS set to the AS of the advertising ABR while 839 the local administrator field is set to 0. 841 7.1.2.2. Internet Multicast and Wildcard S-PMSI A-D Routes 843 It may be desirable for an ingress PE to aggregate Internet Multicast 844 routes over a single Inter-area P2MP LSP. This can be achieved using 845 wildcard, i.e., (*,*) S-PMSI A-D routes. An ingress PE MAY advertise 846 a wildcard S-PMSI route as described in section "Ingress PE 847 Procedures". If the ingress PE does indeed originate such a route the 848 egress ABR would receive this route from the ingress ABR and MUST re- 849 advertise it with the PMSI Tunnel Attribute containing the identifier 850 of the intra-area P2MP LSP in the egress area and an upstream 851 assigned label assigned to the inter-area wildcard S-PMSI. 853 7.1.3. Internet Multicast and the Expected Upstream Node 855 If the mapping between the inter-area P2MP service LSP for Internet 856 multicast service and the intra-area P2MP LSP is many-to-one then an 857 egress PE must be able to determine whether a given multicast packet 858 for a particular (S, G) is received from the "expected" upstream 859 node. The expected node is the node towards which the Leaf A-D route 860 is sent by the egress PE. Packets received from another upstream 861 node for that (S, G) MUST be dropped. To allow the egress PE to 862 determine the sender upstream node, the intra-area P2MP LSP must be 863 signaled with no PHP, when the mapping between the inter-area P2MP 864 service LSP for Internet multicast service and the intra-area P2MP 865 LSP is many-to-one. 867 Further the egress ABR MUST first push onto the label stack the 868 upstream assigned label advertised in the S-PMSI route, if the label 869 is not an Implicit NULL. 871 7.1.4. P2MP LDP LSP as the Intra-Area P2MP LSP in the Egress Area 873 The procedures above are sufficient if P2MP LDP LSPs are used as the 874 Intra-area P2MP LSP in the Egress area. 876 7.1.5. P2MP RSVP-TE LSP as the Intra-Area P2MP LSP in the Egress Area 878 If P2MP RSVP-TE LSP is used as the the intra-area LSP in the egress 879 area, then the egress ABR can either (a) graft the leaf (whose IP 880 address is specified in the received Leaf auto-discovery route) into 881 an existing P2MP LSP rooted at the egress ABR, and use that LSP for 882 carrying traffic for the inter-area segmented P2MP service LSP, or 883 (b) originate a new P2MP LSP to be used for carrying (S,G). 885 When the RD of the received Leaf A-D route is zero or all ones, then 886 the procedures are as described in section 7.1.2 ("RD of the 887 received Leaf A-D route is zero or all ones"). 889 Note also that the SESSION object that the egress ABR would use for 890 the intra-area P2MP LSP need not encode the P2MP FEC from the 891 received Leaf auto-discovery route. 893 7.2. Ingress Replication in the Egress Area 895 When Ingress Replication is used to instantiate the egress area 896 segment then the Leaf A-D route advertised by the egress PE MUST 897 carry a downstream assigned label in the P-Tunnel Attribute where the 898 P-Tunnel type is set to Ingress Replication. We will call this the 899 egress PE downstream assigned label. 901 The egress ABR MUST forward packets received from the backbone area 902 intra-area segment, for a particular inter-area P2MP LSP, to all the 903 egress PEs from which the egress ABR has imported a Leaf A-D route 904 for the inter-area P2MP LSP. A packet to a particular egress PE is 905 encapsulated, by the egress ABR, using a MPLS label stack the bottom 906 label of which is the egress PE downstream assigned label. The top 907 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 908 PE. 910 Note that these procedures ensures that an egress PE always receives 911 packets only from the expected upstream PE. 913 8. Ingress ABR Procedures for constructing segmented inter-area P2MP LSP 915 When an ingress ABR receives a Leaf auto-discovery route and the 916 Route Target extended community carried by the route contains the IP 917 address of this ABR, then the following procedures will be executed. 919 These procedures are the same as in the section "Egress ABR 920 Procedures" with egress ABR replaced with ingress ABR, backbone area 921 replaced with ingress area and backbone area segment replaced with 922 ingress area segment. 924 In order to support Internet Multicast the ingress ABR MUST auto- 925 configure an import Route Target with the global administrator field 926 set to the AS of the ABR and the local administrator field set to 0. 928 8.1. P2MP LSP as the Intra-Area LSP in the Backbone Area 930 If the RD of the received Leaf A-D route is not zero, and P2MP LSP is 931 used as the the intra-area LSP in the backbone area, then the 932 procedures for binding the backbone area segment of the inter-area 933 P2MP LSP to the intra-area P2MP LSP in the backbone area, are the 934 same as in section "Egress ABR Procedures" and sub-section "P2MP LSP 935 as the Intra-Area LSP in the Egress Area". 937 When the RD of the received Leaf A-D route is zero, as is the case 938 where the inter-area service P2MP LSP is associated with the Internet 939 multicast service, then the procedures are the same as in section 940 "Egress ABR Procedures", and and sub-section "P2MP LSP as the Intra- 941 Area LSP in the Egress Area", with egress ABR replaced with the 942 ingress ABR. It is to be noted that if the backbone area uses 943 wildcard S-PMSI then the egress area also must use wildcard S-PMSI 944 for Internet Multicast or the ABRs must merge the wildcard S-PMSI 945 onto the egress area (S, G) or (*, G) S-PMSI. The procedures for such 946 merge require IP processing on the ABRs. 948 8.2. Ingress Replication in the Backbone Area 950 When Ingress Replication is used to instantiate the backbone area 951 segment then the Leaf A-D route advertised by the egress ABR MUST 952 carry a downstream assigned label in the P-Tunnel Attribute where the 953 P-Tunnel type is set to Ingress Replication. We will call this the 954 egress ABR downstream assigned label. The egress ABR MUST assign a 955 distinct MPLS label for each Leaf A-D route originated by the ABR. 957 The ingress ABR MUST forward packets received from the ingress area 958 intra-area segment, for a particular inter-area P2MP LSP, to all the 959 egress ABRs from which the ingress ABR has imported a Leaf A-D route 960 for the inter-area P2MP LSP. A packet to a particular egress ABR is 961 encapsulated, by the inress ABR, using a MPLS label stack the bottom 962 label of which is the egress ABR downstream assigned label. The top 963 label is the P2P RSVP-TE or the MP2P LDP label to reach the egress 964 ABR. 966 9. Ingress PE/ASBR Procedures 968 This section describes Ingress PE/ASBR procedures for constructing 969 segmented inter-area P2MP LSP. 971 When an ingress PE/ASBR receives a Leaf auto-discovery route and the 972 Route Target extended community carried by the route contains the IP 973 address of this PE/ASBR, then the following procedures will be 974 executed. 976 If the RD of the received A-D route is not set to all 0s or all 1s, 977 then the egress ABR MUST find a S-PMSI or I-PMSI route whose NLRI has 978 the same value as the Route Key field of the received Leaf A-D route. 979 If such a matching route is found then the Leaf A-D route MUST be 980 accepted else it MUST be discarded. If the Leaf A-D route is accepted 981 then it MUST be processed as per MVPN or VPLS procedures. 983 If the RD of the received A-D route is set to all 0s or all 1s then 984 the received Leaf A-D route is for Internet Multicast. In that case 985 for the following procedure the Route Prefix is set to all fields of 986 the Route Key minus the Ingress PE address. If this is the first Leaf 987 A-D route update for this Route Prefix or the withdrawl of the last 988 Leaf A-D route for the Route Prefix then the following procedures 989 will be executed. The information carried in the MCAST-VPN NLRI of 990 the route MUST be decoded. The PIM implementation should set its 991 upstream (S/RP,G) state machine in Joined state for the (S/RP, G) 992 received via a Leaf auto-discovery route update. Likewise, the PIM 993 implementation should set its upstream (S/RP, G) state machine in 994 Pruned state for the (S/RP, G) received via a Leaf auto-discovery 995 route withdrawl. 997 9.1. P2MP LSP as the intra-area LSP in the ingress area 999 If the RD of the received Leaf A-D route is not zero, and P2MP LSP is 1000 used as the the intra-area LSP in the ingress area, then the 1001 procedures for binding the ingress area segment of the inter-area 1002 P2MP LSP to the intra-area P2MP LSP in the ingress area, are the same 1003 as in section "Egress ABR Procedures" and sub-section "P2MP LSP as 1004 the Intra-Area LSP in the Egress Area". 1006 When the RD of the received Leaf A-D route is zero, as is the case 1007 where the inter-area service P2MP LSP is associated with the Internet 1008 multicast service, then the ingress PE may originate a S-PMSI route 1009 with the RD, multicast source, multicast group fields being the same 1010 as those in the received Leaf A-D route. 1012 Further an ingress PE may originate a wildcard S-PMSI route as per 1013 the procedures in [MVPN-WILDCARD-SPMSI] with the RD set to 0. This 1014 route may be originated by the ingress PE based on configuration or 1015 based on the import of a Leaf A-D route with RD set to 0. If an 1016 ingress PE originates such a route, then the ingress PE may decide 1017 not to originate (S, G) or (*, G) S-PMSI routes. 1019 It is to be noted that if ingress area uses wildcard S-PMSI then the 1020 backbone area also must use wildcard S-PMSI for Internet Multicast or 1021 the ABRs must merge the wildcard S-PMSI onto the backbone area (S, G) 1022 or (*, G) S-PMSI. The procedures for such merge require IP processing 1023 on the ABRs. 1025 9.2. Ingress Replication in the Ingress Area 1027 When Ingress Replication is used to instantiate the ingress area 1028 segment then the Leaf A-D route advertised by the ingress ABR MUST 1029 carry a downstream assigned label in the P-Tunnel Attribute where the 1030 P-Tunnel type is set to Ingress Replication. We will call this the 1031 ingress ABR downstream assigned label. The ingress ABR MUST assign a 1032 distinct MPLS label for each Leaf A-D route originated by the ABR. 1034 The ingress PE/ASBR MUST forward packets received from the CE, for a 1035 particular inter-area P2MP LSP, to all the ingress ABRs from which 1036 the ingress PE/ASBR has imported a Leaf A-D route for the inter-area 1037 P2MP LSP. A packet to a particular ingress ABR is encapsulated, by 1038 the inress PE/ASBR, using a MPLS label stack the bottom label of 1039 which is the ingress ABR downstream assigned label. The top label is 1040 the P2P RSVP-TE or the MP2P LDP label to reach the ingress ABR. 1042 10. Common Tunnel Type in the Ingress and Egress Areas 1044 For a given inter-area service P2MP LSP, the PE/ASBR that is the root 1045 of that LSP controls the tunnel type of the intra-area P-tunnel that 1046 carries the ingress area segment of that LSP. However, the tunnel 1047 type of the intra-area P-tunnel that carries the backbone area 1048 segment of that LSP may be different from the tunnel type of the 1049 intra-area P-tunnels that carry the ingress area segment and the 1050 egress area segment of that LSP. In that situation if for a given 1051 inter-area P2MP LSP it is desirable/necessary to use the same tunnel 1052 type for the intra-area P-tunnels that carry the ingress area segment 1053 and the egress area segment of that LSP, then the following 1054 procedures on the ingress ABR and egress ABR provide this 1055 functionality. 1057 When an ingress ABR re-advertises into the backbone area a BGP MVPN 1058 I-PMSI, or S-PMSI A-D route, or VPLS A-D route, the ingress ABR 1059 places the PMSI Tunnel attribute of this route into the ATTR_SET BGP 1060 Attribute [L3VPN-IBGP], adds this attribute to the re-advertised 1061 route, and then replaces the original PMSI Tunnel attribute with a 1062 new one (note, that the Tunnel type of the new attribute may be 1063 different from the Tunnel type of the original attribute). 1065 When an egress ABR re-advertises into the egress area a BGP MVPN I- 1066 PMSI or S-PMSI A-D route, or VPLS A-D route, if the route carries the 1067 ATTR_SET BGP attribute [L3VPN-IBGP], then the ABR sets the Tunnel 1068 type of the PMSI Tunnel attribute in the re-advertised route to the 1069 Tunnel type of the PMSI Tunnel attribute carried in the ATTR_SET BGP 1070 attribute, and removes the ATTR_SET from the route. 1072 11. Placement of Ingress and Egress PEs 1074 As described in earlier sections, procedures in this document allow 1075 the placement of ingress and egress PEs in the backbone area. They 1076 also allow the placement of egress PEs in the ingress area or the 1077 placement of ingress PEs in the egress area. 1079 For instance ABRs in the backbone area may act as ingress and egress 1080 PEs for Internet Multicast, as per the ingress and egress PE 1081 definition in this document. This may be the case if the service is 1082 Internet Multicast and relies on Internet Multicast in the ingress 1083 and egress areas and its desirable to carry Internet Multicast over 1084 MPLS in the backbone area. This may also be the case if the service 1085 is Multicast VPN and the P-tunnel technology in the ingress and 1086 egress areas uses PIM based IP/GRE P-tunnels. As far as the ABRs are 1087 concerned PIM signaling for such P-Tunnels is handled as per the 1088 ingress/egress PE Internet Multicast procedures in this document. To 1089 facilitate this the ABRs may advertise their loopback addresses in 1090 BGP using multicast-SAFI i.e., SAFI 2, if non-congruence between 1091 unicast and multicast is desired. 1093 12. Data Plane 1095 This section describes the data plane procedures on the ABRs, ingress 1096 PEs, egress PEs and transit routers. 1098 12.1. Data Plane Procedures on an ABR 1100 When procedures in this document are followed to signal inter-area 1101 P2MP Segmented LSPs then ABRs are required to perform only MPLS 1102 switching. When an ABR receives a MPLS packet from an "incoming" 1103 intra-area segment of the inter-area P2MP Segmented LSP, it forwards 1104 the packet, based on MPLS switching, onto another "outgoing" intra- 1105 area segment of the inter-area P2MP Segmented LSP. 1107 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1108 and if there is a one-to-one mapping between the outgoing intra-area 1109 segment and the P2MP LSP, then the ABR MUST pop the incoming 1110 segment's label stack and push the label stack of the outgoing P2MP 1111 LSP. If there is a many-to-one mapping between outgoing intra-area 1112 segments and the P2MP LSP then the ABR MUST pop the incoming 1113 segment's label stack and first push the upstream assigned label 1114 corresponding to the outgoing intra-area segment, if such a label has 1115 been assigned, and then push the label stack of the outgoing P2MP 1116 LSP. 1118 If the outgoing intra-area segment is instantiated using ingress 1119 replication then the ABR must pop the incoming segment's label stack 1120 and replicate the packet once to each leaf ABR or PE of the outgoing 1121 intra-area segment. The label stack of the packet sent to each such 1122 leaf MUST first include a downstream assigned label assigned by the 1123 leaf to the segment, followed by the label stack of the P2P or MP2P 1124 LSP to the leaf. 1126 12.2. Data Plane Procedures on an Egress PE 1128 An egress PE must first identify the inter-area P2MP segmented LSP 1129 based on the incoming label stack. After this identification the 1130 egress PE must forward the packet using the application that is bound 1131 to the inter-area P2MP segmented LSP. 1133 Note that the application specific forwarding for MVPN service may 1134 require the egress PE to determine whether the packets were received 1135 from the expected sender PE. When the application is MVPN then the 1136 FEC of an inter-area P2MP Segmented LSP is at the granularity of the 1137 sender PE. Note that MVPN intra-AS I-PMSI A-D routes and S-PMSI A-D 1138 routes both carry the Originating Router IP Address. Thus an egress 1139 PE could associate the data arriving on P-tunnels advertised by these 1140 routes with the Originating Router IP Address carried by these routes 1141 which is the same as the ingress PE. Since a unique label stack is 1142 associated with each such FEC, the egress PE can determine the sender 1143 PE from the label stack. 1145 Likewise for VPLS service for the purposes of MAC learning the egress 1146 PE must be able to determine the "VE-ID" from which the packets have 1147 been received. The FEC of the VPLS A-D routes carries the VE-ID. Thus 1148 an egress PE could associate the data arriving on P-tunnels 1149 advertised by these routes with the VE-ID carried by these routes. 1150 Since a unique label stack is associated with each such FEC, the 1151 egress PE can perform MAC learning for packets received from a given 1152 VE-ID. 1154 When the application is Internet Multicast it is sufficient for the 1155 label stack to include identification of the sender upstream node. 1156 When P2MP LSPs are used this requires that PHP MUST be turned off. 1157 When Ingress Replication is used the egress PE knows the incoming 1158 downstream assigned label to which it has bound a particlar (S/*, G) 1159 and must accept packets with only that label for that (S/*. G). 1161 12.3. Data Plane Procedures on an Ingress PE 1163 The Ingress PE must perform application specific forwarding 1164 procedures to identify the outgoing inta-area segment of an incoming 1165 packet. 1167 If the outgoing intra-area segment is instantiated using a P2MP LSP, 1168 and if there is a one-to-one mapping between the outgoing intra-area 1169 segment and the P2MP LSP, then the ingress PE MUST encapsulate the 1170 packet in the label stack of the outgoing P2MP LSP. If there is a 1171 many-to-one mapping between outgoing intra-area segments and the P2MP 1172 LSP then the PE MUST first push the upstream assigned label 1173 corresponding to the outgoing intra-area segment, if such a label has 1174 been assigned, 1175 and then push the label stack of the outgoing P2MP LSP. 1177 If the outgoing intra-area segment is instantiated using ingress 1178 replication then the PE must replicate the packet once to each leaf 1179 ABR or PE of the outgoing intra-area segment. The label stack of the 1180 packet sent to each such leaf MUST first include a downstream 1181 assigned label assigned by the leaf to the segment, followed by the 1182 label stack of the P2P or MP2P LSP to the leaf. 1184 12.4. Data Plane Procedures on Transit Routers 1186 When procedures in this document are followed to signal inter-area 1187 P2MP Segmented LSPs then tansit routers in each area perform only 1188 MPLS switching. 1190 13. IANA Considerations 1192 This document defines a new BGP Extended Community called "Inter-area 1193 P2MP Segmented Next-Hop". This community is IP Address Specific, of 1194 an extended type, and is transitive. A codepoint for this community 1195 should be assigned both from the IPv4 Address Specific Extended 1196 Community registry, and from the IPv6 Address Specific Extended 1197 Community registry. The same code point should be assigned from both 1198 registries. 1200 14. Security Considerations 1202 These will be spelled out in a future revision. 1204 15. References 1206 15.1. Normative References 1208 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 1210 [RFC2119] "Key words for use in RFCs to Indicate Requirement 1211 Levels.", Bradner, March 1997 1213 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 1214 VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, draft-ietf- 1215 l3vpn-2547bis-mcast-bgp 1217 [[VPLS-P2MP] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, 1218 draft-ietf-l2vpn-vpls-mcast 1220 [L3VPN-IBGP] "Internal BGP as PE-CE protocol", Pedro Marques, et al., 1221 draft-ietf-l3vpn-ibgp, work in progress 1223 15.2. Informative References 1225 [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., 1226 draft-leymann-mpls-seamless-mpls 1228 16. Author's Address 1230 Yakov Rekhter 1231 Juniper Networks 1232 1194 North Mathilda Ave. 1233 Sunnyvale, CA 94089 1234 Email: yakov@juniper.net 1236 Rahul Aggarwal 1237 Juniper Networks 1238 1194 North Mathilda Ave. 1239 Sunnyvale, CA 94089 1240 Phone: +1-408-936-2720 1241 Email: rahul@juniper.net 1243 Thomas Morin 1244 France Telecom R & D 1245 2, avenue Pierre-Marzin 1246 22307 Lannion Cedex 1247 France 1248 Email: thomas.morin@francetelecom.com 1250 Irene Grosclaude 1251 France Telecom R & D 1252 2, avenue Pierre-Marzin 1253 22307 Lannion Cedex 1254 France 1255 Email: irene.grosclaude@orange-ftgroup.com 1257 Nicolai Leymann 1258 Deutsche Telekom AG 1259 Winterfeldtstrasse 21 1260 Berlin 10781 1261 DE 1262 Email: n.leymann@telekom.de 1264 Samir Saad 1265 AT&T 1266 Email: ss2539@att.com