idnits 2.17.1 draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 28. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2464. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([MVPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 333 has weird spacing: '...uations only ...' == Line 1312 has weird spacing: '... In this do...' == Line 1828 has weird spacing: '...pecting to se...' == Line 1831 has weird spacing: '...tuation may o...' == Line 1833 has weird spacing: '...rt this situa...' == (14 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 16, 2008) is 5792 days in the past. Is this intentional? 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: 'RFC4659' is mentioned on line 186, but not defined == Missing Reference: 'MVPN-ARCH' is mentioned on line 624, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' ** Obsolete normative reference: RFC 2858 (ref. 'RFC4760') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Expiration Date: December 2008 5 Intended Status: Proposed Standard 6 E. Rosen 7 Cisco Systems, Inc. 9 T. Morin 10 France Telecom 12 Y. Rekhter 13 Juniper Networks 15 C. Kodeboniya 17 June 16, 2008 19 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs 21 draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt 23 Status of this Memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Abstract 47 This document describes the BGP encodings and procedures for 48 exchanging the information elements required by Multicast in MPLS/BGP 49 IP VPNs, as specified in [MVPN]. 51 Table of Contents 53 1 Specification of requirements ......................... 4 54 2 Introduction .......................................... 5 55 3 Terminology ........................................... 5 56 4 MCAST-VPN NLRI ........................................ 6 57 4.1 Intra-AS I-PMSI A-D route ............................. 7 58 4.2 Inter-AS I-PMSI A-D route ............................. 8 59 4.3 S-PMSI A-D route ...................................... 8 60 4.4 Leaf A-D route ........................................ 9 61 4.5 Source Active A-D route ............................... 10 62 4.6 C-multicast route ..................................... 11 63 5 PMSI Tunnel attribute ................................. 12 64 6 Source AS Extended Community .......................... 14 65 7 VRF Route Import Extended Community ................... 14 66 8 PE Distinguisher Labels Attribute ..................... 15 67 9 MVPN Auto-Discovery/Binding ........................... 16 68 9.1 MVPN Auto-Discovery/Binding - Intra-AS Operations ..... 16 69 9.1.1 Originating Intra-AS I-PMSI A-D routes ................ 16 70 9.1.2 Receiving Intra-AS I-PMSI A-D routes .................. 19 71 9.2 MVPN Auto-Discovery/Binding - Inter-AS Operations ..... 20 72 9.2.1 Originating Inter-AS I-PMSI A-D routes ................ 21 73 9.2.2 When not to originate Inter-AS I-PMSI A-D routes ...... 22 74 9.2.3 Propagating Inter-AS I-PMSI A-D routes ................ 23 75 9.2.3.1 Propagating Inter-AS I-PMSI A-D routes - Overview ..... 23 76 9.2.3.2 Inter-AS I-PMSI A-D route received via EBGP ........... 24 77 9.2.3.2.1 Originating Leaf A-D route into EBGP .................. 25 78 9.2.3.3 Leaf A-D route received via EBGP ...................... 26 79 9.2.3.4 Inter-AS I-PMSI A-D route received via IBGP ........... 27 80 9.2.3.4.1 Originating Leaf A-D route into IBGP .................. 28 81 9.2.3.5 Leaf A-D route received via IBGP ...................... 29 82 9.2.3.6 Optimizing Bandwidth by IP filtering on ASBRs ......... 30 83 10 Non-congruent Unicast and Multicast Connectivity ...... 30 84 11 Exchange of C-Multicast Routing Information among PEs . 32 85 11.1 Originating C-multicast routes by a PE ................ 32 86 11.1.1 Originating routes: PIM as the C-Multicast protocol ... 32 87 11.1.1.1 Originating Source Tree Join C-multicast route ........ 33 88 11.1.1.2 Originating Shared Tree Join C-multicast route ........ 33 89 11.1.2 Originating routes: mLDP as the C-Multicast protocol .. 34 90 11.1.3 Constructing the rest of the C-multicast route ........ 34 91 11.1.4 Unicast Route Changes ................................. 35 92 11.2 Propagating C-multicast routes by an ASBR ............. 36 93 11.3 Receiving C-multicast routes by a PE .................. 37 94 11.3.1 Receiving routes: PIM as the C-Multicast protocol ..... 37 95 11.3.1.1 Receiving Source Tree Join C-multicast route .......... 37 96 11.3.1.2 Receiving Shared Tree Join C-multicast route .......... 38 97 11.3.2 Receiving routes: mLDP as the C-Multicast protocol .... 38 98 11.4 C-multicast routes aggregation ........................ 39 99 12 Using S-PMSI A-D routes to Bind C-trees to P-tunnels .. 40 100 12.1 Originating S-PMSI A-D routes ......................... 40 101 12.2 Handling S-PMSI A-D routes by ASBRs ................... 42 102 12.2.1 Merging S-PMSI into an I-PMSI ......................... 42 103 12.3 Receiving S-PMSI A-D routes by PEs .................... 43 104 13 Switching from Shared C-tree to Source C-tree ......... 44 105 13.1 Source Within a Site - Source Active Advertisement .... 45 106 13.2 Receiving Source Active A-D route ..................... 46 107 13.2.1 Pruning Sources off the Shared Tree ................... 46 108 14 Supporting PIM-SM without Inter-Site Shared C-trees ... 47 109 14.1 Discovering Active Multicast Sources .................. 47 110 14.2 Receiver(s) Within a Site ............................. 48 111 14.3 Receiving C-multicast routes by a PE .................. 50 112 15 Carrier's Carrier ..................................... 50 113 16 Scalability Considerations ............................ 50 114 16.1 Dampening C-multicast routes .......................... 51 115 16.1.1 Dampening withdrawals of C-multicast routes ........... 52 116 16.1.2 Dampening Source/Shared Tree Join C-multicast routes .. 52 117 16.2 Dampening withdrawals of Leaf A-D routes .............. 53 118 17 IANA Consideration .................................... 53 119 18 Security Considerations ............................... 53 120 19 Acknowledgement ....................................... 53 121 20 References ............................................ 54 122 20.1 Normative References .................................. 54 123 20.2 Informative References ................................ 54 124 21 Author's Address ...................................... 55 125 22 Intellectual Property Statement ....................... 56 126 23 Copyright Notice ...................................... 56 128 1. Specification of requirements 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Introduction 136 This document describes the BGP encodings and procedures for 137 exchanging the information elements required by Multicast in MPLS/BGP 138 IP VPNs, as specified in [MVPN]. This document assumes a thorough 139 familiarity with procedures, concepts and terms described in [MVPN]. 141 This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI 142 is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel 143 binding, advertising to S-PMSI tunnel binding, VPN 144 customer multicast routing information exchange among PEs, choosing a 145 single forwarder PE, and for procedures in support of co-locating a 146 C-RP on a PE. 148 This document specifies two new BGP attributes, P-Multicast Service 149 Interface Tunnel (PMSI Tunnel) attribute, and PE Distinguisher Label 150 attribute. 152 This document also defines two new BGP Extended Communities, Source 153 AS Extended Community and VRF Route Import Extended Community. 155 3. Terminology 157 In the context of this document we will refer to the MVPN auto- 158 discovery/binding information carried in BGP as "auto-discovery 159 routes" ("A-D routes"). For a given MVPN there are the following 160 types of A-D routes: 162 + Intra-AS I-PMSI A-D route; 164 + Inter-AS I-PMSI A-D route; 166 + S-PMSI A-D route; 168 + Leaf A-D route; 170 + Source Active A-D route. 172 In the context of this document we will refer to the MVPN customers 173 multicast routing information carried in BGP as "C-multicast routes". 174 For a given MVPN there are the following types of C-multicast routes: 176 + Shared Tree Join route; 177 + Source Tree Join route; 179 For each MVPN present on a PE, the PE maintains a Tree Information 180 Base (MVPN-TIB). This is the same as TIB defined in [RFC4601], except 181 that instead of a single TIB a PE maintains multiple MVPN-TIBs, one 182 per each MVPN. 184 Throughout this draft we will use the term "VPN-IP route" to mean a 185 route which is either in the VPN-IPv4 address family [RFC4364] or in 186 the VPN-IPv6 address family [RFC4659]. 188 4. MCAST-VPN NLRI 190 This document defines a new BGP NLRI, called the MCAST-VPN NLRI. 192 Following is the format of the MCAST-VPN NLRI: 194 +-----------------------------------+ 195 | Route Type (1 octet) | 196 +-----------------------------------+ 197 | Length (1 octet) | 198 +-----------------------------------+ 199 | Route Type specific (variable) | 200 +-----------------------------------+ 202 The Route Type field defines encoding of the rest of MCAST-VPN NLRI 203 (Route Type specific MCAST-VPN NLRI). 205 The Length field indicates the length in octets of the Route Type 206 specific field of MCAST-VPN NLRI. 208 This document defines the following Route Types for A-D routes: 210 + 1 - Intra-AS I-PMSI A-D route; 211 + 2 - Inter-AS I-PMSI A-D route; 212 + 3 - S-PMSI A-D route; 213 + 4 - Leaf A-D route; 214 + 5 - Source Active A-D route. 216 This document defines the following Route Types for C-multicast 217 routes: 219 + 6 - Shared Tree Join route; 220 + 7 - Source Tree Join route; 222 The MCAST-VPN NLRI is carried in BGP [RFC4271] using BGP 223 Multiprotocol Extensions [RFC4760] with an AFI of 1 or 2 and an SAFI 224 of MCAST-VPN. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 225 attribute contains the MCAST-VPN NLRI (encoded as specified above). 226 The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 227 attribute that carries the MCAST-VPN NLRI determines whether the 228 Multicast Source and Multicast Group addresses carried in the S-PMSI 229 A-D routes, Source Active A-D routes, and C-multicast routes are IPv4 230 or IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates 231 IPv6 addresses). 233 In order for two BGP speakers to exchange labeled MCAST-VPN NLRI, 234 they must use BGP Capabilities Advertisement to ensure that they both 235 are capable of properly processing such NLRI. This is done as 236 specified in [RFC4760], by using capability code 1 (multiprotocol 237 BGP) with an AFI of 1 or 2 and an SAFI of MCAST-VPN. 239 The following describes the format of the Route Type specific MCAST- 240 VPN NLRI for various Route Types defined in this document. 242 4.1. Intra-AS I-PMSI A-D route 244 An Intra-AS I-PMSI A-D route type specific MCAST-VPN NLRI consists of 245 the following: 247 +-----------------------------------+ 248 | RD (8 octets) | 249 +-----------------------------------+ 250 | Originating Router's IP Addr | 251 +-----------------------------------+ 253 The RD is encoded as described in [RFC4364]. 255 Usage of Intra-AS I-PMSI A-D routes is described in Section "MVPN 256 Auto-Discovery/Binding - Intra-AS Operations". 258 4.2. Inter-AS I-PMSI A-D route 260 An Inter-AS I-PMSI A-D route type specific MCAST-VPN NLRI consists of 261 the following: 263 +-----------------------------------+ 264 | RD (8 octets) | 265 +-----------------------------------+ 266 | Source AS (4 octets) | 267 +-----------------------------------+ 269 The RD is encoded as described in [RFC4364]. 271 The Source AS contains an Autonomous System number. 273 Two octets AS numbers are encoded in the two low order octets of the 274 Source AS field, with the the two high order octets set to zero. 276 Usage of Inter-AS I-PMSI A-D routes is described in Section "MVPN 277 Auto-Discovery/Binding - Inter-AS Operations". 279 4.3. S-PMSI A-D route 281 An S-PMSI A-D route type specific MCAST-VPN NLRI consists of the 282 following: 284 +-----------------------------------+ 285 | RD (8 octets) | 286 +-----------------------------------+ 287 | Multicast Source Length (1 octet) | 288 +-----------------------------------+ 289 | Multicast Source (Variable) | 290 +-----------------------------------+ 291 | Multicast Group Length (1 octet) | 292 +-----------------------------------+ 293 | Multicast Group (Variable) | 294 +-----------------------------------+ 295 | Originating Router's IP Addr | 296 +-----------------------------------+ 298 The RD is encoded as described in [RFC4364]. 300 The Multicast Source field contains the C-S address. If the Multicast 301 Source field contains an IPv4 address, then the value of the 302 Multicast Source Length field is 32. If the Multicast Source field 303 contains an IPv6 address, then the value of the Multicast Source 304 Length field is 128. 306 The Multicast Group field contains the C-G address or C-Generic LSP 307 Identifier Value (use of C-Generic LSP Identifier Value is described 308 in Section "Receiving routes: mLDP as the C-Multicast protocol"). If 309 the Multicast Group field contains an IPv4 address or a C-Generic LSP 310 Identifier Value, then the value of the Multicast Group Length field 311 is 32. If the Multicast Group field contains an IPv6 address, then 312 the value of the Multicast Group Length field is 128. 314 Usage of other values of the Multicast Source Length and Multicast 315 Group Length fields is outside the scope of this document. 317 Usage of S-PMSI A-D routes is described in Section "Using S-PMSI A-D 318 routes to Bind C-trees to P-tunnels". 320 4.4. Leaf A-D route 322 A Leaf A-D route type specific MCAST-VPN NLRI consists of the 323 following: 325 +-----------------------------------+ 326 | Route Key (variable) | 327 +-----------------------------------+ 328 | Originating Router's IP Addr | 329 +-----------------------------------+ 331 Leaf A-D routes may be originated as a result of processing a 332 received Inter-AS I-PMSI A-D route or S-PMSI A-D route. A Leaf A-D 333 route is originated in these situations only if the received route 334 has a PMSI Tunnel attribute whose "Leaf Information Required" bit is 335 set to 1. 337 If a Leaf A-D route is originated as a result of processing one of 338 the received routes specified in the previous paragraph, the Route 339 Key of the Leaf A-D route is set to the NLRI of the received route. 341 Details of the use of the Leaf A-D route may be found in Sections 342 "Originating Leaf A-D route into EBGP", "Leaf A-D route received via 343 EBGP", "Originating Leaf A-D route into IBGP", "Leaf A-D route 344 received via IBGP", and "Receiving S-PMSI A-D routes by PEs". 346 4.5. Source Active A-D route 348 A Source Active A-D route type specific MCAST-VPN NLRI consists of 349 the following: 351 +-----------------------------------+ 352 | RD (8 octets) | 353 +-----------------------------------+ 354 | Multicast Source Length (1 octet) | 355 +-----------------------------------+ 356 | Multicast Source (Variable) | 357 +-----------------------------------+ 358 | Multicast Group Length (1 octet) | 359 +-----------------------------------+ 360 | Multicast Group (Variable) | 361 +-----------------------------------+ 363 The RD is encoded as described in [RFC4364]. 365 The Multicast Source field contains the C-S address. If the Multicast 366 Source field contains an IPv4 address, then the value of the 367 Multicast Source Length field is 32. If the Multicast Source field 368 contains an IPv6 address, then the value of the Multicast Source 369 Length field is 128. 371 Use of the Source Active A-D routes with the Multicast Source Length 372 field of 0 is outside the scope of this document. 374 The Group Address field contains the C-G address. If the Multicast 375 Group field contains an IPv4 address, then the value of the Multicast 376 Group Length field is 32. If the Multicast Group field contains an 377 IPv6 address, then the value of the Multicast Group Length field is 378 128. 380 Source Active A-D routes with a Multicast group belonging to the 381 Source Specific Multicast (SSM) range (as defined in [RFC4607], and 382 potentially extended locally on a router) MUST NOT be advertised by a 383 router and MUST be discarded if received. 385 Usage of Source Active A-D routes is described in Sections "Switching 386 from Shared C-tree to Source C-tree", and "Supporting PIM-SM without 387 Inter-Site Shared C-trees". 389 4.6. C-multicast route 391 A Shared Tree Join route and a Source Tree Join route type specific 392 MCAST-VPN NLRI consists of the following: 394 +-----------------------------------+ 395 | RD (8 octets) | 396 +-----------------------------------+ 397 | Source AS (4 octets) | 398 +-----------------------------------+ 399 | Multicast Source Length (1 octet) | 400 +-----------------------------------+ 401 | Multicast Source (Variable) | 402 +-----------------------------------+ 403 | Multicast Group Length (1 octet) | 404 +-----------------------------------+ 405 | Multicast Group (Variable) | 406 +-----------------------------------+ 408 The RD is encoded as described in [RFC4364]. 410 The Source AS contains an Autonomous System number. Two octets AS 411 numbers are encoded in the low order two octets of the Source AS 412 field. 414 For a Shared Tree Join route the Multicast Source field contains the 415 C-RP address; for a Source Tree Join route the Multicast Source field 416 contains the C-S address. If the Multicast Source field contains an 417 IPv4 address, then the value of the Multicast Source Length field is 418 32. If the Multicast Source field contains an IPv6 address, then the 419 value of the Multicast Source Length field is 128. 421 The Group Address field contains the C-G address or C-Generic LSP 422 Identifier Value. If the Multicast Group field contains an IPv4 423 address or C-Generic LSP Identifier Value, then the value of the 424 Multicast Group Length field is 32. If the Multicast Group field 425 contains an IPv6 address, then the value of the Multicast Group 426 Length field is 128. 428 Usage of C-multicast routes is described in Section "Exchange of C- 429 Multicast Routing Information among PEs". 431 5. PMSI Tunnel attribute 433 This document defines and uses a new BGP attribute, called P- 434 Multicast Service Interface Tunnel (PMSI Tunnel) attribute. This is 435 an optional transitive BGP attribute. The format of this attribute is 436 defined as follows: 438 +---------------------------------+ 439 | Flags (1 octet) | 440 +---------------------------------+ 441 | Tunnel Type (1 octets) | 442 +---------------------------------+ 443 | MPLS Label (3 octets) | 444 +---------------------------------+ 445 | Tunnel Identifier (variable) | 446 +---------------------------------+ 448 The Flags field has the following format: 450 0 1 2 3 4 5 6 7 451 +-+-+-+-+-+-+-+-+ 452 | reserved |L| 453 +-+-+-+-+-+-+-+-+ 455 This document defines the following flags: 457 + Leaf Information Required (L) 459 The Tunnel Type identifies the type of the tunneling technology used 460 to establish the PMSI tunnel. The type determines the syntax and 461 semantics of the Tunnel Identifier field. This document defines the 462 following Tunnel Types: 464 + 0 - No tunnel information present 465 + 1 - RSVP-TE P2MP LSP 466 + 2 - mLDP P2MP LSP 467 + 3 - PIM-SSM Tree 468 + 4 - PIM-SM Tree 469 + 5 - PIM-Bidir Tree 470 + 6 - Ingress Replication 471 + 7 - mLDP MP2MP LSP 473 If the MPLS Label field is non-zero, then it contains an MPLS label 474 encoded as 3 octets, where the high-order 20 bits contain the label 475 value. Absence of MPLS Label is indicated by setting the MPLS Label 476 field to zero. 478 When the type is set to "No tunnel information present", the PMSI 479 Tunnel attribute carries no tunnel information (no Tunnel 480 Identifier). This may be used to enable explicit tracking for a 481 particular customer multicast flow (by setting the Leaf Information 482 Required flag to 1), but without binding this flow to a particular 483 provider tunnel (by omitting any tunnel information). 485 When the type is set to RSVP-TE P2MP LSP, the Tunnel Identifier is 486 as carried in the 487 RSVP-TE P2MP LSP SESSION Object [RSVP-TE-P2MP]. 489 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 490 P2MP FEC Element [mLDP]. 492 When the type is set to PIM-SM Tree, the Tunnel Identifier is . The node that originated the attribute 494 MUST use the address carried in the Sender Address as the source IP 495 address for the IP/GRE encapsulation of the MVPN data. 497 When the type is set to PIM-SSM Tree, the Tunnel Identifier is . The node that originates the 499 attribute MUST use the address carried in the P-Root Node Address as 500 the source IP address for the IP/GRE encapsulation of the MVPN data. 501 The P-Multicast Group element of the Tunnel identifier of the Tunnel 502 attribute MUST NOT be expected to be the same group for all Intra-AS 503 A-D routes for the same MVPN. According to [RFC4607], the group 504 address can be locally allocated by the originating PE without any 505 consideration for the group address used by other PE on the same 506 MVPN. 508 When the type is set to PIM-Bidir Tree, the Tunnel Identifier is 509 . The node that originated the 510 attribute MUST use the address carried in the Sender Address as the 511 source IP address for the IP/GRE encapsulation of the MVPN data. 513 When the type is set to PIM-SM or PIM-Bidir tree, then the P- 514 Multicast group element of the Tunnel identifier of the Tunnel 515 attribute SHOULD be the same multicast group address for all Intra-AS 516 I-PMSI A-D routes for the same MVPN originated by PEs within a given 517 AS. How this multicast group address is chosen is outside the scope 518 of this specification. 520 When the type is set to Ingress Replication the Tunnel Identifier 521 carries the unicast tunnel endpoint IP address of the local PE that 522 is to be this PE's receiving endpoint address for the tunnel. 524 When the type is set to mLDP MP2MP LSP, the Tunnel Identifier is an 525 MP2MP FEC Element [mLDP]. 527 The use of mLDP MP2MP LSPs as Provider tunnels (P-tunnels) requires 528 procedures which are outside the scope of this document. 530 The PMSI Tunnel attribute is used in conjunction with Intra-AS I-PMSI 531 A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf 532 A-D routes. 534 6. Source AS Extended Community 536 This document defines a new BGP extended community called Source AS. 538 The Source AS is an AS specific extended community, of an extended 539 type, and is transitive across AS boundaries [RFC4360]. 541 The Global Administrator field of this community MUST be set to the 542 autonomous system number of the PE. The Local Administrator field of 543 this community MUST be set to 0. 545 If for a given MVPN BGP is used for exchanging C-multicast routes, or 546 if segmented inter-AS tunnels are used, then when a PE that has sites 547 of that MVPN connected to it originates a (unicast) route to VPN-IP 548 addresses, the PE MUST include in the BGP Update message that carries 549 this route the Source AS extended community. 551 The usage of a received Source AS extended community is described in 552 Section "Constructing the rest of the C-multicast route". 554 7. VRF Route Import Extended Community 556 This document defines a new BGP extended community called VRF Route 557 Import. 559 The VRF Route Import is an IP address specific extended community, of 560 an extended type, and is transitive across AS boundaries [RFC4360]. 562 To support MVPN, in addition to the import/export Route Target(s) 563 extended communities used by the unicast routing, each VRF on a PE 564 MUST have an import Route Target extended community. We refer to 565 this Route Target as the "C-multicast Import RT", as this Route 566 Target controls imports of C-multicast routes into a particular VRF. 568 A PE constructs C-multicast Import RT as follows: 570 + The Global Administrator field of the C-multicast Import RT MUST 571 be set to an IP address of the PE. This address SHOULD be common 572 for all the VRFs on the PE (e.,g., this address may be PE's 573 loopback address). 575 + The Local Administrator field of the C-multicast Import RT 576 associated with a given VRF contains a 2 octets long number that 577 uniquely identifies that VRF within the PE that contains the VRF 578 (procedures for assigning such numbers are purely local to the 579 PE, and outside the scope of this document). 581 The way C-multicast Import RT is constructed, it uniquely identifies 582 a VRF. 584 A PE that has site(s) of a given MVPN connected to it needs to 585 communicate the value of the C-multicast Import RT associated with 586 the VRF of that MVPN on the PE to all other PEs that have sites of 587 that MVPN. To accomplish this a PE that originates a (unicast) route 588 to VPN-IP addresses MUST include in the BGP Updates message that 589 carries this route the VRF Route Import extended community that has 590 the value of the C-multicast Import RT of the VRF associated with the 591 route, except if it is known a priori that none of these addresses 592 will act as multicast sources and/or RP, in which case the (unicast) 593 route need not carry the VRF Route Import extended community. 595 If a PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD 596 advertise all such C-multicast Import RTs using Route Target 597 Constrains (note that doing this requires just a single Route Target 598 Constraint advertisement by the PE). This allows each C-multicast 599 route to reach only the relevant PE. To constrain distribution of the 600 Route Target Constrain routes to the AS of the advertising PE these 601 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 603 Usage of VRF Route Import extended community is described in Section 604 "Constructing the rest of the C-multicast route". 606 8. PE Distinguisher Labels Attribute 608 This document defines a new BGP attribute, called PE Distinguisher 609 Labels attribute. This is an optional transitive BGP attribute. The 610 format of this attribute is defined as follows: 612 +---------------------------------+ 613 | PE Address | 614 +---------------------------------+ 615 | Label (3 octets) | 616 +---------------------------------+ 617 ....... 618 +---------------------------------+ 619 | PE Address | 620 +---------------------------------+ 621 | Label (3 octets) | 622 +---------------------------------+ 624 Usage of this attribute is described in [MVPN-ARCH]. 626 9. MVPN Auto-Discovery/Binding 628 This section specifies procedures for the auto-discovery of MVPN 629 memberships and the distribution of information used to instantiate 630 I-PMSIs. 632 There are two MVPN auto-discovery/binding mechanisms, dubbed "intra- 633 AS" and "inter-AS" respectively. 635 The intra-AS mechanisms provide auto-discovery/binding within a 636 single AS. 638 The intra-AS mechanisms also provide auto-discovery/binding across 639 multiple ASes when non-segmented inter-AS tunnels are being used. 641 The inter-AS mechanisms provide auto-discovery/binding across 642 multiple ASes when segmented inter-AS tunnels are being used. 644 Note that if a multi-AS system uses option (a) of section 10 of 645 [RFC4364], the notion of inter-AS tunnels does not apply, and so it 646 needs only the intra-AS mechanisms. 648 9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations 650 This section describes exchanges of Intra-AS I-PMSI A-D routes 651 originated/received by PEs within the same AS, or if non-segmented 652 inter-AS tunnels are used, then by all PEs. 654 9.1.1. Originating Intra-AS I-PMSI A-D routes 656 To participate in the MVPN auto-discovery/binding a PE router that 657 has a given VRF of a given MVPN MUST, except for the cases specified 658 further down in this section, originate an Intra-AS I-PMSI A-D route 659 and advertises this route in IBGP. The route is constructed as 660 follows. 662 The route carries a single MCAST-VPN NLRI with the RD set to the RD 663 of the VRF, and the Originating Router's IP Address field set to the 664 IP address that the PE places in the Global Administrator field of 665 the VRF Route Import extended community of the VPN-IP routes 666 advertised by the PE. Note that the tuple uniquely identifies a given multicast VRF. 669 The route carries the PMSI Tunnel attribute if and only if an I-PMSI 670 is used for the MVPN (the conditions under which an I-PMSI is used 671 can be found in [MVPN]). Depending on the technology used for the P- 672 tunnel for the MVPN on the PE, the PMSI Tunnel attribute of the 673 Intra-AS I-PMSI A-D route is constructed as follows. 675 + If the PE that originates the advertisement uses a P-Multicast 676 tree for the P-tunnel for the MVPN, the PMSI Tunnel attribute 677 MUST contain the identity of the tree (note that the PE could 678 create the identity of the tree prior to the actual instantiation 679 of the tree). 681 + A PE that uses a P-Multicast tree for the P-tunnel MAY aggregate 682 two or more MVPNs present on the PE onto the same tree. In this 683 case in addition to carrying the identity of the tree, the PMSI 684 Tunnel attribute MUST carry an MPLS upstream assigned label which 685 the PE has bound uniquely to the MVPN associated with this update 686 (as determined by its RTs). 688 If the PE has already advertised Intra-AS I-PMSI A-D routes for 689 two or more MVPNs that it now desires to aggregate, then the PE 690 MUST re-advertise those routes. The re-advertised routes MUST be 691 the same as the original ones, except for the PMSI Tunnel 692 attribute and the label carried in that attribute. 694 + If the PE that originates the advertisement uses ingress 695 replication for the P-tunnel for the MVPN, the route MUST include 696 the PMSI Tunnel attribute with the Tunnel Type set to Ingress 697 Replication and Tunnel Identifier set to a routable address of 698 the PE. The PMSI Tunnel attribute MUST carry a downstream 699 assigned MPLS label. This label is used to demultiplex the MVPN 700 traffic received over a unicast tunnel by the PE. 702 + The Leaf Information Required flag of the PMSI Tunnel attribute 703 MUST be set to zero, and MUST be ignored on receipt. 705 Discovery of PE capabilities in terms of what tunnels types they 706 support is outside the scope of this document. Within a given AS PEs 707 participating in an MVPN are expected to advertise tunnel bindings 708 whose tunnel types are supported by all other PEs that are 709 participating in this MVPN and are part of the same AS. In addition, 710 in the inter-AS scenario with non-segmented inter-AS tunnels, the 711 tunnel types have to be supported by all PEs that are participating 712 in this MVPN, irrespective of whether these PEs are in the same AS or 713 not. 715 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 716 be set to the same IP address as the one carried in the Originating 717 Router's IP Address field. 719 By default the distribution of the Intra-AS I-PMSI A-D routes is 720 controlled by the same Route Targets as the ones used for the 721 distribution of VPN-IP unicast routes. That is, by default the Intra- 722 AS I-PMSI A-D route MUST carry the export Route Target used by the 723 unicast routing. If any other PE has one of these Route Targets 724 configured as an import Route Target for a VRF present on the PE, it 725 treats the advertising PE as a member in the MVPN to which the VRF 726 belongs. The default could be modified via configuration by having a 727 set of Route Targets used for the Intra-AS I-PMSI A-D routes being 728 distinct from the ones used for the VPN-IP unicast routes (see also 729 Section "Non-congruent Unicast and Multicast Connectivity"). 731 To constrain distribution of the intra-AS membership/binding 732 information to the AS of the advertising PE the BGP Update message 733 originated by the advertising PE SHOULD carry the NO_EXPORT Community 734 ([RFC1997]). 736 Note that if non-segmented inter-AS P-tunnels are being used, then 737 the Intra-AS I-PMSI routes need to be distributed to other ASes and 738 MUST NOT carry the NO_EXPORT community. 740 When BGP is used to exchange C-multicast routes, originating an 741 Intra-AS I-PMSI A-D route for a given MVPN by a given PE is OPTIONAL 742 if (a) it is known a priori that none of the MVPN sites connected to 743 the PE have multicast sources, (b) the PE does not use ingress 744 replication for incoming multicast traffic of that MVPN, and (c) none 745 of the other PEs that have VRFs of that MVPN use RSVP-TE P2MP LSPs 746 for that MVPN. 748 When BGP is used to exchange C-multicast routes, originating an 749 Intra-AS I-PMSI A-D route for a given MVPN by a given PE is also 750 OPTIONAL if it is known a priori that none of the MVPN sites 751 connected to the PE have multicast receivers, and the PE uses ingress 752 replication for that MVPN. 754 9.1.2. Receiving Intra-AS I-PMSI A-D routes 756 When a PE receives a BGP Update message that carries an Intra-AS I- 757 PMSI A-D route such that (a) at least one of the Route Targets of the 758 route matches one of the import Route Targets configured for a 759 particular VRF on the local PE, (b) either the route was originated 760 by some other PE within the same AS as the local PE, or the MVPN 761 associated with the VRF uses non-segmented inter-AS tunnels, and (c) 762 the BGP route selection determines that this is the best route with 763 respect to the NLRI carried by the route, the PE performs the 764 following. 766 If the route carries the PMSI Tunnel attribute then: 768 + If the Tunnel Type in the PMSI Tunnel attribute is set to Ingress 769 Replication, then the MPLS label and the address carried in the 770 Tunnel Identifier field of the PMSI Tunnel attribute should be 771 used when the local PE sends multicast traffic to the PE that 772 originated the route. 774 + If the Tunnel Type in the PMSI Tunnel attribute is set to mLDP 775 P2MP LSP, or mLDP MP2MP LSP, or PIM-SSM tree, or PIM-SM tree, or 776 PIM-Bidir tree, the PE SHOULD join as soon as possible the P- 777 Multicast tree whose identity is carried in the Tunnel 778 Identifier. 780 + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE 781 P2MP LSP, then the PE that originated the route MUST establish an 782 RSVP-TE P2MP LSP with the local PE as a leaf. This LSP may have 783 been established before the local PE receives the route, or may 784 be established after the local PE receives the route. 786 + The receiving PE has to establish the appropriate state to 787 properly handle the traffic received on the P-Multicast tree. 789 + If the PMSI Tunnel attribute does not carry a label, then all 790 packets that are received on the P-Multicast tree, as identified 791 by the PMSI Tunnel attribute, are forwarded using the VRFs that 792 has at least one of its import Route Targets that matches one of 793 the Route Targets of the received Intra-AS I-PMSI A-D route. 795 + If the PMSI Tunnel attribute has the Tunnel Type set to mLDP P2MP 796 LSP, or PIM-SSM tree, or PIM-SM tree, or PIM-Bidir tree, or RSVP- 797 TE P2MP LSP, and the attribute also carries an MPLS label, then 798 this is an upstream assigned label, and all packets that are 799 received on the P-Multicast tree, as identified by the PMSI 800 Tunnel attribute, with that upstream assigned label are forwarded 801 using the VRFs that has at least one of its import Route Target 802 that matches one of the Route Targets of the received Intra-AS I- 803 PMSI A-D route. 805 Irrespective of whether the route carries the PMSI Tunnel attribute, 806 if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic 807 from the VRF to the sites attached to other PEs, then the local PE 808 uses the Originating Router's IP address information carried in the 809 route to add the PE that originated the route as a leaf node to the 810 LSP. 812 9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations 814 This section applies only to the case where segmented inter-AS 815 tunnels are used. 817 An Autonomous System Border Router (ASBR) may be configured to 818 support a particular MVPN as follows: 820 + An ASBR MUST be be configured with a set of (import) Route 821 Targets (RTs) that specifies the set of MVPNs supported by the 822 ASBR. These Route Targets control acceptance of Intra-AS/Inter-AS 823 I-PMSI A-D routes by the ASBR. As long as unicast and multicast 824 connectivity are congruent, this could be the same set of Route 825 Targets as the one used for supporting unicast (and therefore 826 would not require any additional configuration above and beyond 827 of what is required for unicast). Note that instead of being 828 configured, the ASBR MAY obtain this set of (import) Route 829 Targets (RTs) by using Route Target Constrain [RT-CONSTRAIN]. 831 + The ASBR MUST be (auto-)configured with an import Route Target 832 called "ASBR Import RT". ASBR Import RT controls acceptance of 833 Leaf A-D routes and C-multicast routes by the ASBR, and is used 834 to constrain distribution of both Leaf A-D routes and C-multicast 835 routes (see Section "Exchange of C-Multicast Routing Information 836 among PEs"). 838 ASBR Import RT is an IP address specific Route Target. The Global 839 Administrator field of the ASBR Import RT MUST be set to the IP 840 address carried in the Next Hop of all the Inter-AS I-PMSI A-D 841 routes and S-PMSI A-D routes advertised by this ASBR (if the ASBR 842 uses different Next Hops, then the ASBR MUST be (auto-)configured 843 with multiple ASBR Import RTs, one per each such Next Hop). The 844 Local Administrator field of the ASBR Import RT MUST be set to 0. 846 If the ASBR supports Route Target Constrain [RT-CONSTRAIN], the 847 ASBR SHOULD advertise its ASBR Import RT within its own AS using 848 Route Target Constrains. To constrain distribution of the Route 849 Target Constrain routes to the AS of the advertising ASBR these 850 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 852 + The ASBR MUST be configured with the tunnel types for the intra- 853 AS segments of the MVPNs supported by the ASBR, as well as 854 (depending on the tunnel type) the information needed to create 855 the PMSI attribute for these tunnel types. Note that instead of 856 being configured, the ASBR MAY derive the tunnel types from the 857 Intra-AS I-PMSI A-D routes received by the ASBR. 859 + If the ASBR originates an Inter-AS I-PMSI A-D route for a 860 particular MVPN present on some of the PEs within its own AS, the 861 ASBR MUST be (auto-)configured with an RD for that MVPN. It is 862 RECOMMENDED that one of the following two options be used: 864 (1) To allow more aggregation of Inter-AS I-PMSI A-D routes it is 865 recommended that all the ASBRs within an AS that are configured 866 to originate an Inter-AS I-PMSI A-D route for a particular MVPN 867 be configured with the same RD (although for a given MVPN each AS 868 may assign this RD on its own, without coordination with other 869 ASes). 871 (2) To allow more control over spreading MVPN traffic among 872 multiple ASBRs within a given AS it is recommended for each ASBR 873 to have a distinct RD per each MVPN, in which case such an RD 874 SHOULD be auto-configured. 876 If an ASBR is configured to support a particular MVPN, the ASBR MUST 877 participate in the intra-AS MVPN auto-discovery/binding procedures 878 for that MVPN within the ASBR's own AS, as specified in Section "MVPN 879 Auto-Discovery/Binding - Intra-AS Operations". 881 Moreover, in addition to the above the ASBR performs procedures 882 described in Sections "Originating Inter-AS I-PMSI A-D routes", "When 883 not to originate Inter-AS I-PMSI A-D routes", and "Propagating Inter- 884 AS I-PMSI A-D routes". 886 9.2.1. Originating Inter-AS I-PMSI A-D routes 888 For a given MVPN configured on an ASBR when the ASBR determines 889 (using the intra-AS auto-discovery procedures) that at least one of 890 the PEs of its own AS has (directly) connected site(s) of the MVPN, 891 the ASBR originates an Inter-AS I-PMSI A-D route and advertises it in 892 EBGP. The route is constructed as follows: 894 + The route carries a single MCAST-VPN NLRI with the RD set to the 895 RD configured for that MVPN on the ASBR, and the Source AS set to 896 the Autonomous System number of the ASBR. 898 + The route carries the PMSI Tunnel attribute if and only if an I- 899 PMSI is used for the MVPN. The Tunnel Type in the attribute is 900 set to Ingress Replication; the Leaf Information Required flag is 901 set to 1; the the attribute carries no MPLS labels. 903 + The Next Hop field of the MP_REACH_NLRI attribute is set to a 904 routable IP address of the ASBR. 906 + The default policy for aggregation of Intra-AS I-PMSI A-D routes 907 into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI 908 A-D route aggregates only the Intra-AS I-PMSI A-D routes that 909 carry exactly the same set of RTs (note that this set may have 910 just one RT). In this case an Inter-AS I-PMSI A-D route 911 originated by an ASBR carries exactly the same RT(s) as the RT(s) 912 carried by the Intra-AS I-PMSI A-D routes that the ASBR 913 aggregates into that Inter-AS I-PMSI A-D route. An implementation 914 MUST support the default policy for aggregation of Intra-AS I- 915 PMSI A-D routes into an Inter-AS I-PMSI A-D route. 917 + The default policy for aggregation could be modified via 918 configuration on the ASBR. An implementation MAY support such 919 functionality. Modified policy MUST include rules for 920 constructing RTs carried by the Inter-AS I-PMSI A-D routes 921 originated by the ASBR. 923 An Inter-AS I-PMSI A-D route for a given indicates 924 presence of the MVPN sites connected to one or more PEs of the AS. 926 An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra- 927 AS I-PMSI A-D routes originated within the ASBR's own AS. Thus while 928 the Intra-AS I-PMSI A-D routes originated within an AS are at the 929 granularity of within that AS, outside of that AS the 930 (aggregated) Inter-AS I-PMSI A-D routes could be at the granularity 931 of . 933 9.2.2. When not to originate Inter-AS I-PMSI A-D routes 935 If for a given MVPN and a given AS all of its sites connected to the 936 PEs within the AS known a priori to have no multicast sources, then 937 ASBRs of that AS MAY refrain from originating an Inter-AS I-PMSI A-D 938 route for that MVPN at all. 940 9.2.3. Propagating Inter-AS I-PMSI A-D routes 942 An Inter-AS I-PMSI A-D route for a given MVPN originated by an ASBR 943 within a given AS is propagated via BGP to other ASes. 945 9.2.3.1. Propagating Inter-AS I-PMSI A-D routes - Overview 947 Suppose that an ASBR A installs an Inter-AS I-PMSI A-D route for MVPN 948 V that originated at a particular AS, AS1. The BGP next hop of that 949 route becomes A's "upstream multicast hop" on a multicast 950 distribution tree for V that is rooted at AS1. When the Inter-AS I- 951 PMSI A-D routes have been distributed to all the necessary ASes, they 952 define a "reverse path" from any AS that supports MVPN V back to AS1. 953 For instance, if AS2 supports MVPN V, then there will be a reverse 954 path for MVPN V from AS2 to AS1. This path is a sequence of ASBRs, 955 the first of which is in AS2, and the last of which is in AS1. Each 956 ASBR in the sequence is the BGP next hop of the previous ASBR in the 957 sequence on the given Inter-AS I-PMSI A-D route. 959 This reverse path information can be used to construct a 960 unidirectional multicast distribution tree for MVPN V, containing all 961 the ASes that support V, and having AS1 at the root. We call such a 962 tree an "inter-AS tree". Multicast data originating in MVPN sites 963 connected to PEs within a given AS will travel downstream along the 964 tree which is rooted at that AS. 966 The path along an inter-AS tree is a sequence of ASBRs; it is still 967 necessary to specify how the multicast data gets from a given ASBR to 968 the set of ASBRs which are immediately downstream of the given ASBR 969 along the tree. This is done by creating "segments": ASBRs in 970 adjacent ASes will be connected by inter-AS segments, ASBRs in the 971 same AS will be connected by "intra-AS segments". 973 An ASBR initiates creation of an intra-AS segment when the ASBR 974 receives an Inter-AS I-PMSI A-D route from an EBGP neighbor. 975 Creation of the segment is completed as a result of distributing via 976 IBGP this route within the ASBR's own AS. 978 For a given inter-AS tunnel each of its intra-AS segments could be 979 constructed by its own independent mechanism. Moreover, by using 980 upstream assigned labels within a given AS multiple intra-AS segments 981 of different inter-AS tunnels of either the same or different MVPNs 982 may share the same P-Multicast tree. 984 If the P-Multicast tree that serves as a particular intra-AS segment 985 of an inter-AS tunnel is created by a multicast control protocol that 986 uses receiver-initiated joins (e.g, mLDP, any PIM variant), and this 987 P-Multicast tree does not aggregate multiple segments, then all the 988 information needed to create that segment is present in the PMSI 989 Tunnel attribute of the Inter-AS I-PMSI A-D routes. But if the P- 990 Multicast tree that serves as the segment is created by a protocol 991 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress 992 unicast replication), or if this P-Multicast tree aggregates multiple 993 segments (irrespective of the multicast control protocol used to 994 create the tree), then it is also necessary to use Leaf A-D routes. 995 The precise conditions under which Leaf A-D routes need to be used 996 are described in subsequent sections. 998 Since (aggregated) Inter-AS I-PMSI A-D routes could have granularity 999 of , an MVPN that is present in N ASes could have total of 1000 N inter-AS tunnels. Thus for a given MVPN the number of inter-AS 1001 tunnels constituting the I-PMSIs is independent of the number of PEs 1002 that have this MVPN. 1004 The precise rules for distributing and processing the Inter-AS I-PMSI 1005 A-D routes across ASes are given in the following sections. 1007 9.2.3.2. Inter-AS I-PMSI A-D route received via EBGP 1009 When an ASBR receives from one of its EBGP neighbors a BGP Update 1010 message that carries an Inter-AS I-PMSI A-D route, if (a) at least 1011 one of the Route Targets carried in the message matches one of the 1012 import Route Targets configured on the ASBR, and (b) the ASBR 1013 determines that the received route is the best route for its NLRI, 1014 the ASBR re-advertises this route to other PEs and ASBRs within its 1015 own AS (handling of this route by other PEs and ASBRs is described in 1016 Section "Inter-AS I-PMSI A-D route received via IBGP"). 1018 When re-advertising an Inter-AS I-PMSI A-D route the ASBR MUST set 1019 the Next Hop field of the MP_REACH_NLRI attribute to a routable IP 1020 address of the ASBR. 1022 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1023 attribute, then depending on the technology used to instantiate the 1024 intra-AS segment of the inter-AS tunnel the ASBR constructs the PMSI 1025 Tunnel attribute of the re-advertised Inter-AS I-PMSI A-D route as 1026 follows. 1028 + If the ASBR uses ingress replication for the intra-AS segment of 1029 the inter-AS tunnel, the re-advertised route MUST carry the PMSI 1030 Tunnel attribute with the Tunnel Type set to Ingress Replication, 1031 but no MPLS labels. 1033 + If the ASBR uses a P-Multicast tree for the intra-AS segment of 1034 the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the 1035 identity of the tree (note that the ASBR could create the 1036 identity of the tree prior to the actual instantiation of the 1037 tree). If in order to instantiate the tree the ASBR needs to 1038 know the leaves of the tree, then the ASBR obtains this 1039 information from the Leaf A-D routes received from other 1040 PEs/ASBRs in ASBR's own AS (as described in Section "Leaf A-D 1041 route received via IBGP") by setting the Leaf Information 1042 Required flag in the PMSI Tunnel attribute to 1. 1044 + An ASBR that uses a P-Multicast tree as the intra-AS segment of 1045 the inter-AS tunnel MAY aggregate two or more MVPNs present on 1046 the ASBR onto the same tree. In this case in addition to the 1047 identity of the tree, the PMSI Tunnel attribute MUST carry an 1048 MPLS upstream-assigned label which the PE has bound uniquely to 1049 the MVPN associated with this update (as determined by its RTs). 1051 If the ASBR has already advertised Inter-AS I-PMSI A-D routes for 1052 two or more MVPNs that it now desires to aggregate, then the ASBR 1053 MUST re-advertise those routes. The re-advertised routes MUST be 1054 the same as the original ones, except for the PMSI Tunnel 1055 attribute and the MVPN label. 1057 9.2.3.2.1. Originating Leaf A-D route into EBGP 1059 In addition the ASBR MUST send to the EBGP neighbor from whom it 1060 received the Inter-AS I-PMSI A-D route, a BGP Update message that 1061 carries a Leaf A-D route constructed as follows. 1063 + The route carries a single MCAST-VPN NLRI with the Route Key 1064 field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route 1065 received from that neighbor and the Originating Router's IP 1066 address set to the IP address of the ASBR (this MUST be a 1067 routable IP address). 1069 + The Leaf A-D route MUST include the PMSI Tunnel attribute with 1070 the Tunnel Type set to Ingress Replication, and the Tunnel 1071 Identifier set to a routable address of the advertising router. 1072 The PMSI Tunnel attribute MUST carry a downstream assigned MPLS 1073 label that is used by the advertising router to demultiplex the 1074 MVPN traffic received over a unicast tunnel from the EBGP 1075 neighbor. 1077 + The ASBR constructs an IP-based Route Target extended community 1078 by placing the IP address carried in the next hop of the received 1079 Inter-AS I-PMSI A-D route in the Global Administrator field of 1080 the community, with the Local Administrator field of this 1081 community set to 0, and sets the Extended Communities attribute 1082 of the Leaf A-D route to that community. Note that this Route 1083 Target is the same as the ASBR Import RT of the EBGP neighbor 1084 from which the ASBR received the Inter-AS I-PMSI A-D route. 1086 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1087 SHOULD be set to the same IP address as the one carried in the 1088 Originating Router's IP Address field of the route. 1090 + To constrain the distribution scope of this route the route MUST 1091 carry the NO_ADVERTISE BGP community ([RFC1997]). 1093 Handling of this Leaf A-D route by the EBGP neighbor is described in 1094 Section "Leaf A-D route received via EBGP". 1096 The ASBR MUST set up its forwarding state such that packets that 1097 arrive on the one-hop ASBR-ASBR LSP, as specified in the PMSI Tunnel 1098 Attribute of the Leaf A-D route, are transmitted on the intra-AS 1099 segment, as specified in the PMSI Tunnel Attribute of the inter-AS I- 1100 PMSI A-D route that the ASBR re-advertises in its own AS. However, 1101 the packets MAY be filtered before forwarding, as specified in 1102 Section "Optimizing Bandwidth by IP filtering on ASBRs". 1104 9.2.3.3. Leaf A-D route received via EBGP 1106 When an ASBR receives via EBGP a Leaf A-D route originated by its 1107 neighbor ASBR, if the Route Target carried in the Extended 1108 Communities attribute of the route matches one of the ASBR Import RT 1109 (auto)configured on the ASBR, the ASBR performs the following. 1111 The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has 1112 the same value as the Route Key field of the the Leaf A-D route. 1114 If the found Inter-AS I-PMSI A-D route was originated by ASBR itself, 1115 then the ASBR sets up its forwarding state such that packets received 1116 on the intra-AS tunnels originating in the ASBR's own AS are 1117 transmitted on the one hop ASBR-ASBR LSP specified by the MPLS label 1118 carried in the PMSI Tunnel attribute of the received Leaf A-D route. 1119 (However the packets MAY be filtered before transmission as specified 1120 in Section "Optimizing Bandwidth by IP filtering on ASBRs"). The 1121 intra-AS tunnels are specified in the PMSI Tunnel attribute of all 1122 the Intra-AS I-PMSI A-D routes received by the ASBR that the ASBR 1123 aggregated into the Inter-AS I-PMSI A-D route. For each of these 1124 intra-AS tunnels, if a non-zero MPLS label is carried in the PMSI 1125 Tunnel attribute (i.e aggregation is used) then only packets received 1126 on the inner LSP corresponding to that label MUST be forwarded, not 1127 the packets received on the outer LSP, as the outer LSP possibly 1128 carries the traffic of other VPNs. 1130 If the found Inter-AS I-PMSI A-D route was originated by some other 1131 ASBR, then the ASBR sets up its forwarding state such that packets 1132 received on the intra-AS tunnel segment, as specified in the PMSI 1133 Tunnel attribute of the found Inter-AS I-PMSI A-D route, are 1134 transmitted on the one hop ASBR-ASBR LSP, as specified by the MPLS 1135 label carried in the PMSI Tunnel attribute of the Leaf A-D route. 1137 9.2.3.4. Inter-AS I-PMSI A-D route received via IBGP 1139 In the context of this section we use the term "PE/ASBR router" to 1140 denote either a PE or an ASBR router. 1142 If a given Inter-AS I-PMSI A-D route is received via IBGP by a BGP 1143 Route Reflector, the BGP Route Reflector MUST NOT modify the Next Hop 1144 field of the MP_REACH_NLRI attribute when re-advertising the route 1145 into IBGP (this is because the information carried in the Next Hop is 1146 used for controling flow of C-multicast routes, as specified in 1147 Section "Propagating C-multicast routes by an ASBR"). 1149 If a given Inter-AS I-PMSI A-D route is advertised within an AS by 1150 multiple ASBRs of that AS, the BGP best route selection performed by 1151 other PE/ASBR routers within the AS does not require all these 1152 PE/ASBR routers to select the route advertised by the same ASBR - to 1153 the contrary different PE/ASBR routers may select routes advertised 1154 by different ASBRs. 1156 When a PE/ASBR router receives from one of its IBGP neighbors a BGP 1157 Update message that carries an Inter-AS I-PMSI A-D route, if (a) at 1158 least one of the Route Targets carried in the message matches one of 1159 the import Route Targets configured on the PE/ASBR, and (b) the 1160 PE/ASBR determines that the received route is the best route to the 1161 destination carried in the NLRI of the route, the PE/ASBR performs 1162 the following operations. 1164 If the router is a PE, then the router imports the route into the 1165 VRF(s) that have the matching import Route Targets. 1167 If the router is an ASBR then the ASBR propagates the route to its 1168 EBGP neighbors. When propagating the route to the EBGP neighbors the 1169 ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a 1170 routable IP address of the ASBR. If the received Inter-AS I-PMSI A-D 1171 route carries the PMSI Tunnel attribute, then the propagated route 1172 MUST carry the PMSI Tunnel attribute with the Tunnel Type set to 1173 Ingress Replication; the attribute carries no MPLS labels. 1175 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1176 attribute with the Tunnel Type set to mLDP P2MP LSP, or PIM-SSM tree, 1177 or PIM-SM tree, or PIM-Bidir tree, the PE/ASBR SHOULD join as soon as 1178 possible the P-Multicast tree whose identity is carried in the Tunnel 1179 Identifier. 1181 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1182 attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then 1183 the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP 1184 with the local PE/ASBR as a leaf. This LSP MAY have been established 1185 before the local PE/ASBR receives the route, or MAY be established 1186 after the local PE receives the route. 1188 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1189 attribute with the Tunnel Type set to mLDP P2MP LSP, or RSVP-TE P2MP 1190 LSP, or PIM-SSM, or PIM-SM tree, or PIM-Bidir tree, but the attribute 1191 does not carry a label, then the P-Multicast tree, as identified by 1192 the PMSI Tunnel Attribute, is an intra-AS LSP segment that is part of 1193 the inter-AS Tunnel for the MVPN advertised by the Inter-AS I-PMSI A- 1194 D route and rooted at the AS that originated the Inter-AS I-PMSI A-D 1195 route. If the PMSI Tunnel attribute carries a (upstream assigned) 1196 label, then a combination of this tree and the label identifies the 1197 intra-AS segment. If the receiving router is an ASBR, this intra-AS 1198 segment may further be stitched to the ASBR-ASBR inter-AS segment of 1199 the inter-AS tunnel. If the PE/ASBR has local receivers in the MVPN, 1200 packets received over the intra-AS segment must be forwarded to the 1201 local receivers using the local VRF. 1203 9.2.3.4.1. Originating Leaf A-D route into IBGP 1205 If the Leaf Information Required flag in the PMSI Tunnel attribute of 1206 the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR 1207 MUST originate a new Leaf A-D route as follows. 1209 + The route carries a single MCAST-VPN NLRI with the Route Key 1210 field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route 1211 received from that neighbor, and the Originating Router's IP 1212 address set to the IP address of the ASBR (this MUST be a 1213 routable IP address). 1215 + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1216 attribute with the Tunnel Type set to Ingress Replication, then 1217 the Leaf A-D route MUST carry the PMSI Tunnel attribute with the 1218 Tunnel Type set to Ingress Replication. The Tunnel Identifier 1219 MUST carry a routable address of the PE/ASBR. The PMSI Tunnel 1220 attribute MUST carry a downstream assigned MPLS label that is 1221 used to demultiplex the MVPN traffic received over a unicast 1222 tunnel by the PE/ASBR. 1224 + The PE/ASBR constructs an IP-based Route Target community by 1225 placing the IP address carried in the next hop of the received 1226 Inter-AS I-PMSI A-D route in the Global Administrator field of 1227 the community, with the Local Administrator field of this 1228 community set to 0, and sets the Extended Communities attribute 1229 of the Leaf A-D route to that community. 1231 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1232 SHOULD be set to the same IP address as the one carried in the 1233 Originating Router's IP Address field of the route. 1235 + To constrain the distribution scope of this route the route MUST 1236 carry the NO_EXPORT BGP community ([RFC1997]). 1238 + Once the Leaf A-D route is constructed, the PE/ASBR advertises 1239 this route into IBGP. 1241 9.2.3.5. Leaf A-D route received via IBGP 1243 When an ASBR receives via IBGP a Leaf A-D route, if the Route Target 1244 carried in the Extended Communities attribute of the route matches 1245 one of the ASBR Import RT (auto)configured on the ASBR, the ASBR 1246 performs the following. 1248 The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has 1249 the same value as the Route Key field of the the Leaf A-D route. 1251 The received route may carry either (a) no PMSI Tunnel attribute, or 1252 (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to 1253 Ingress Replication. 1255 If the received route does not carry the PMSI Tunnel attribute, the 1256 ASBR uses the information from the received route to determine the 1257 leaves of the P-Multicast tree rooted at the ASBR that would be used 1258 for the intra-AS segment associated with the found Inter-AS I-PMSI A- 1259 D route. The IP address of a leaf is the IP address carried in the 1260 Originating Router's IP address field of the received Leaf A-D route. 1262 If the received route carries the PMSI Tunnel attribute with the 1263 Tunnel Type set to Ingress Replication the ASBR uses the information 1264 carried by the route to construct the intra-AS segment with ingress 1265 replication. 1267 9.2.3.6. Optimizing Bandwidth by IP filtering on ASBRs 1269 An ASBR that has a given Inter-AS I-PMSI A-D route MAY discard some 1270 of the traffic carried in the tunnel specified in the PMSI Tunnel 1271 attribute of this route if the ASBR determines that there are no 1272 downstream receivers for that traffic. 1274 When BGP is being used to distribute C-multicast routes, an ASBR that 1275 has a given Inter-AS I-PMSI A-D route MAY discard traffic from a 1276 particular customer multicast source C-S and destined to a particular 1277 customer multicast group address C-G that is carried over the tunnel 1278 specified in the PMSI Tunnel attribute of the route, if none of the 1279 C-multicast routes on the ASBR with RD and Source AS being the same 1280 as the RD and Source AS of the Inter-AS I-PMSI A-D route matches the 1281 (C-S,C-G) tuple. A C-multicast route is said to match a (C-S,C-G) 1282 tuple, if it is a Source Tree Join route with Multicast Source set to 1283 C-S and Multicast Group set to C-G, or a Shared Tree Join route with 1284 Multicast Group set to C-G. 1286 The above procedures MAY also apply to an ASBR that originates a 1287 given Inter-AS I-PMSI A-D route. In this case the ASBR applies them 1288 to the traffic carried over the tunnels specified in the PMSI Tunnel 1289 attribute of the Intra-AS I-PMSI A-D routes that the ASBR aggregates 1290 into the Inter-AS I-PMSI A-D route, and whose tails are stiched to 1291 the one-hop ASBR-ASBR tunnel specified in the Inter-AS I-PMSI A-D 1292 route. 1294 10. Non-congruent Unicast and Multicast Connectivity 1296 It is possible to deploy MVPN such the multicast routing and the 1297 unicast routing are "non-congruent". For instance, the CEs may be 1298 distributing to the PEs a special set of unicast routes that are to 1299 be used exclusively for the purpose of upstream multicast hop 1300 selection, and not used for unicast routing at all. (For example, 1301 when BGP is the CE-PE unicast routing protocol, the CEs may be using 1302 SAFI 2 ("Network Layer Reachability Information used for multicast 1303 forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a 1304 special set of routes that are to be used for, and only for, upstream 1305 multicast hop selection.) In such a situation, we will speak of the 1306 MVPN as having two VRFs on a given PE, one containing the routes that 1307 are used for unicast, the other containing the unicast routes that 1308 are used for upstream multicast hop (UMH) selection. We will call 1309 the former the "unicast routing VRF", and the latter the "UMH VRF" 1310 (upstream multicast hop VRF). 1312 In this document, when we speak without qualification of the 1313 MVPN's VRF, then if the MVPN has both a unicast VRF and a UMH VRF, we 1314 are speaking of the UMH VRF. (Of course, if there is no separate UMH 1315 VRF, then we are speaking of the unicast VRF.) 1317 If there is a separate UMH VRF, it MAY have its own import and export 1318 Route Targets, different from the ones used by the unicast VRF. These 1319 Route Targets MUST be used to control distribution of auto-discovery 1320 routes. In addition, the export Route Targets of the UMH VRF are 1321 added to the Route Targets used by the unicast VRF when originating 1322 (unicast) VPN-IP routes. The import Route Targets associated with a 1323 given UMH VRF are used to determine which of the received (unicast) 1324 VPN-IP routes should be accepted into the UMH VRF. 1326 If a PE maintains an UMH VRF for that MVPN, then it is RECOMMENDED 1327 that the UMH VRF should use the same RD as the one used by the 1328 unicast VRF of that MVPN. 1330 If an MVPN site is multi-homed to several PEs, then to support non- 1331 congruent unicast and multicast connectivity, on each of these PEs 1332 the UMH VRF of the MVPN MUST use its own distinct RD (although on a 1333 given PE the RD used by the UMH VRF SHOULD be the same as the one 1334 used by the unicast VRF). 1336 If an MVPN has a UMH VRF distinct from its unicast VRF, then one 1337 option to support non-congruency is by exchanging the routes from/to 1338 that UMH VRF by using the same AFI/SAFI as used by the routes from 1339 the unicast VRF. 1341 Another option is to exchange the routes from/to the UMH VRF using 1342 the IPv4 or IPv6 AFI (as appropriate), but with the SAFI set to 1343 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA- 1344 SAFI]. The NLRI carried by these routes is defined as follows: 1346 +---------------------------+ 1347 | Length (1 octet) | 1348 +---------------------------+ 1349 | Prefix (variable) | 1350 +---------------------------+ 1352 The use and the meaning of these fields are as follows: 1354 a) Length: 1356 The Length field indicates the length in bits of the address 1357 prefix plus the label(s). 1359 b) Prefix: 1361 The Prefix field contains a Route Distinguisher as defined 1362 in [RFC4364] prepended to an IPv4 or IPv6 address prefix, 1363 followed by enough trailing bits to make the end of the 1364 field fall on an octet boundary. Note that the value of 1365 trailing bits is irrelevant. 1367 These routes MUST carry the VRF Route Import Extended Community. If 1368 for a given MVPN BGP is used for exchanging C-multicast routes, or if 1369 segmented inter-AS tunnels are used, then these routes also MUST 1370 carry the Source AS extended community. 1372 The detailed procedures for selecting forwarder PE in the presence of 1373 such routes are outside the scope of this document. However, this 1374 document requires these procedures to preserve the constrains imposed 1375 by the single forwarder PE selection procedures, as specified in 1376 [MVPN]. 1378 11. Exchange of C-Multicast Routing Information among PEs 1380 VPN C-Multicast Routing Information is exchanged among PEs by using 1381 C-multicast routes that are carried using MCAST-VPN NLRI. These 1382 routes are originated and propagated as follows. 1384 11.1. Originating C-multicast routes by a PE 1386 Part of the procedures for constructing MCAST-VPN NLRI depend on the 1387 multicast routing protocol between CE and PE (C-multicast protocol). 1389 11.1.1. Originating routes: PIM as the C-Multicast protocol 1391 The following specifies construction of MCAST-VPN NLRI of C-multicast 1392 routes for the case where the C-multicast protocol is PIM. These C- 1393 multicast routes are originated as a result of updates in , 1394 or state learnt by a PE via the C-multicast protocol. 1396 Note that creation and deletion of (C-S, C-G, RPTbit) states on a PE 1397 when the C-multicast protocol is PIM do not result in any BGP 1398 actions. 1400 11.1.1.1. Originating Source Tree Join C-multicast route 1402 Whenever (a) a C-PIM instance on a particular PE creates a new state, and (b) the selected upstream PE for C-S (see [MVPN]) 1404 is not the local PE, then the local PE MUST originate a a C-multicast 1405 route of a type Source Tree Join. The Multicast Source field in the 1406 MCAST-VPN NLRI of the route is set to C-S, the Multicast Group field 1407 is set of C-G. 1409 This C-multicast route is said to "correspond" to the C-PIM 1410 state. 1412 The semantics of the route is that the PE has one or more receivers 1413 for in the sites connected to the PE (the route has the 1414 Join semantics). 1416 Whenever a C-PIM instance on a particular PE deletes a 1417 state, the corresponding C-multicast route MUST be withdrawn. (The 1418 withdrawal of the route has the Prune semantics). The 1419 MCAST-VPN NLRI of the withdrawn route is carried in the 1420 MP_UNREACH_NLRI attribute. 1422 11.1.1.2. Originating Shared Tree Join C-multicast route 1424 Whenever (a) a C-PIM instance on a particular PE creates a new 1425 state, and (b) the selected upstream PE for the C-RP 1426 corresponding to the C-G (see [MVPN]) is not the local PE, then the 1427 local PE MUST originate a a C-multicast route of a type Shared Tree 1428 Join. The Multicast Source field in the MCAST-VPN NLRI of the route 1429 is set to the C-RP address. The Multicast Group field in the MCAST- 1430 VPN NLRI is set to the C-G address. 1432 This C-multicast route is said to "correspond" to the C-PIM 1433 state. 1435 The semantics of the route is that the PE has one or more receivers 1436 for in the sites connected to the PE (the route has the 1437 Join semantics). 1439 Whenever a C-PIM instance on a particular PE deletes a 1440 state, the corresponding C-multicast route MUST be withdrawn. (The 1441 withdrawal of the route has the Prune semantics). The 1442 MCAST-VPN NLRI of the withdrawn route is carried in the 1443 MP_UNREACH_NLRI attribute. 1445 11.1.2. Originating routes: mLDP as the C-Multicast protocol 1447 The following specifies construction of MCAST-VPN NLRI of C-multicast 1448 routes for the case where the C-multicast protocol is mLDP [mLDP]. 1450 Whenever a PE receives from one of its CEs a P2MP Label Map 1451 over interface I, where X is the Root Node Address, Y is the Opaque 1452 Value, and L is an MPLS label, the PE checks whether it already has 1453 state for in the VRF associated with the CE. If yes, then all 1454 the PE needs to do in this case is to update its forwarding state by 1455 adding to the forwarding state associated with . 1457 If the PE does not have state for in the VRF associated with 1458 the CE, then the PE constructs a Source Tree Join C-multicast route 1459 whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y 1460 as the Multicast Group field. 1462 Whenever a PE deletes a previously created state that had 1463 resulted in originating a C-multicast route, the PE withdraws the C- 1464 multicast route. The MCAST-VPN NLRI of the withdrawn route is carried 1465 in the MP_UNREACH_NLRI attribute. 1467 11.1.3. Constructing the rest of the C-multicast route 1469 The rest of the C-multicast route is constructed as follows (the same 1470 procedures apply to both PIM and mLDP as the C-Multicast protocol). 1472 The local PE executes the procedures of [MVPN] to find the selected 1473 Upstream Multicast Hop (UMH) route and the selected upstream PE for 1474 the address carries in the Multicast Source field of MCAST-VPN NLRI. 1475 From the selected UMH route the local PE extracts (a) the autonomous 1476 system number of the upstream PE (as carried in the Source AS 1477 extended community of the route), and (b) the C-multicast Import RT 1478 of the VRF on the upstream PE (the value of this C-multicast Import 1479 RT is the value of the VRF Route Import Extended Community carried by 1480 the route). The Source AS field in the C-multicast route is set to 1481 that autonomous system. The Route Target Extended Community of the C- 1482 multicast route is set to that C-multicast Import RT. 1484 If there is more than one (remote) PE that originates the (unicast) 1485 route to the address carried in the Multicast Source field of the 1486 MCAST-VPN NLRI, then the procedures for selecting the UMH route and 1487 the upstream PE to reach that address are as specified in [MVPN]. 1489 If the local and the upstream PEs are in the same AS, then the RD of 1490 the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route 1491 that contains the address carried in the Multicast Source field. 1493 The C-multicast route is then advertised into IBGP. 1495 If the local and the upstream PEs are in different ASes, then the 1496 local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source 1497 AS field carries the autonomous system number of the upstream PE. 1498 The RD of the found Inter-AS I-PMSI A-D route is used as the RD of 1499 the advertised C-multicast route. The local PE constructs an IP-based 1500 Route Target community by placing the next hop of the found Inter-AS 1501 I-PMSI A-D route in the Global Administrator field of this community, 1502 with the Local Administrator field of this community set to 0, and 1503 adds this community to the Extended Communities attribute of the C- 1504 multicast route. (Note that this Route Target is the same as the ASBR 1505 Import RT of the ASBR identified by the next hop of the found Inter- 1506 AS I-PMSI A-D route.) 1508 Inter-AS I-PMSI A-D routes are not used to support non-segmented 1509 inter-AS tunnels. To support non-segmented inter-AS tunnels, if the 1510 local and the upstream PEs are in different ASes, the local system 1511 finds in its VRF an Intra-AS I-PMSI A-D route from the upstream PE 1512 (the Originating Router's IP Address field of that route has the same 1513 value as the one carried in the VRF Route Import of the (unicast) 1514 route to the address carried in the Multicast Source field). The RD 1515 of the found Intra-AS I-PMSI A-D route is used as the RD of the 1516 advertised C-multicast route. The Source AS field in the C-multicast 1517 route is set to value of the Originating Router's IP Address field of 1518 the found Intra-AS I-PMSI A-D route. 1520 The Next Hop field of the MP_REACH_NLRI attribute MUST be set to a 1521 routable IP address of the local PE. 1523 If the next hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route 1524 is an EBGP neighbor of the local PE, then the PE advertises the C- 1525 multicast route to that neighbor. If the next hop of the found 1526 (Inter-AS or Intra-AS) I-PMSI A-D route is within the same AS as the 1527 local PE, then the PE advertises the C-multicast route into IBGP. 1529 11.1.4. Unicast Route Changes 1531 The particular UMH route that is selected by a given PE for a given 1532 C-S may be influenced by the network's unicast routing. In that 1533 case, a change in the unicast routing may invalidate prior choices of 1534 the UMH route for some C-S. If this happens, the local PE MUST 1535 execute the UMH route selection procedures for C-S again. If the 1536 result is that a different UMH route is selected, then for all C-G, 1537 any previously originated C-multicast routes for (C-S,C-G) MUST be 1538 re-originated. 1540 Similarly, if a unicast routing change results in a change of the UMH 1541 route for a C-RP, then for all C-G such that C-RP is the RP 1542 associated with C-G, any previously originated C-multicast routes for 1543 (C-*,C-G) MUST be re-originated. 1545 11.2. Propagating C-multicast routes by an ASBR 1547 When an ASBR receives a BGP Update message that carries a C-multicast 1548 route, if at least one of the Route Targets of the route matches one 1549 of the ASBR Import RTs (auto)configured on the ASBR, the ASBR finds 1550 an Inter-AS I-PMSI A-D route whose RD and Source AS matches the RD 1551 and Source AS carried in the C-multicast route. If no matching route 1552 is found, the ASBR takes no further actions. If a matching route is 1553 found, the ASBR proceeds as follows. 1555 To support non-segmented inter-AS tunnels, instead of matching the RD 1556 and Source AS carried in the C-multicast route against the RD and 1557 Source AS of an Inter-AS I-PMSI A-D route, the ASBR should match it 1558 against the RD and the Originating Router's IP Addr of the Intra-AS 1559 I-PMSI A-D routes. 1561 The ASBR first checks if it already has one or more C-multicast 1562 routes that have the same MCAST-VPN NLRI as the newly received route. 1563 If such route(s) already exists, the ASBR keeps the newly received 1564 route, but SHALL NOT re-advertise the newly received route. 1565 Otherwise, the ASBR re-advertises the route, as described further 1566 down. 1568 When an ASBR receives a BGP Update message that carries a withdraw of 1569 a previously advertised C-multicast route, the ASBR first checks if 1570 it already has at least one other C-multicast route that has the same 1571 MCAST-VPN NLRI. If such a route already exists, the ASBR processes 1572 the withdrawn route, but SHALL NOT re-advertise the withdraw. 1573 Otherwise, the ASBR re-advertises the withdrawal of the previously 1574 advertised C-multicast route, as described below. 1576 If the ASBR is the ASBR that originated the found Inter-AS I-PMSI A-D 1577 route, then before re-advertising the C-multicast route into IBGP the 1578 ASBR removes from the route the Route Target that matches one of the 1579 ASBR Import RTs (auto)configured on the ASBR. 1581 If the ASBR is not the ASBR that originated the found Inter-AS I-PMSI 1582 A-D route, then before re-advertising the C-multicast route, the ASBR 1583 modifies the Extended Communities attribute of the C-multicast route 1584 by replacing the Route Target of the route that matches one of the 1585 ASBR Import RTs (auto)configured on the ASBR with a new Route Target 1586 constructed as follows. The new Route Target is an IP-based Route 1587 Target that has the Global Administrator field set to the Next Hop of 1588 the found Inter-AS I-PMSI A-D route, and Local Administrator field of 1589 this community set to 0. Note that this newly constructed Route 1590 Target is the same as the ASBR Import RT of the ASBR identified by 1591 the next hop of the found Inter-AS I-PMSI A-D route. The rest of the 1592 Extended Communities attribute of the route SHOULD be passed 1593 unmodified. 1595 The Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an 1596 IP address of the ASBR. 1598 If the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or 1599 Intra-AS) I-PMSI A-D route is an EBGP neighbor of the ASBR, then the 1600 ASBR re-advertises the C-multicast route to that neighbor. If the 1601 Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra- 1602 AS) I-PMSI A-D route is an IBGP neighbor of the ASBR, the ASBR re- 1603 advertises the C-multicast route into IBGP. If it is the ASBR that 1604 originated the found Inter-AS I-PMSI A-D route in the first place, 1605 then the ASBR just re-advertises the C-multicast route into IBGP. 1607 11.3. Receiving C-multicast routes by a PE 1609 When a PE receives a C-multicast route the PE checks if any of the 1610 Route Target communities carried in the Extended Communities 1611 attribute of the route match any of the C-multicast Import RTs 1612 associated with the VRFs of any MVPN maintained by the PE. If no 1613 match is found the PE SHOULD discard the route. Otherwise, (if a 1614 match is found), the PE checks if the address carried in the 1615 Multicast Source field of the C-multicast route matches one of the 1616 (unicast) VPN-IP routes advertised by PE from the VRF. If no match is 1617 found the PE SHOULD discard the route. Otherwise, (if a match is 1618 found), the PE proceeds as follows, depending on the multicast 1619 routing protocol between CE and PE (C-multicast protocol). 1621 11.3.1. Receiving routes: PIM as the C-Multicast protocol 1623 The following described procedures when PIM is used as the multicast 1624 routing protocol between CE and PE (C-multicast protocol). 1626 11.3.1.1. Receiving Source Tree Join C-multicast route 1628 If the received route has the route type set to Source Tree Join, 1629 then the PE creates a new state in its MVPN-TIB from the 1630 Multicast Source and Multicast Group fields in the MCAST-VPN NLRI of 1631 the route, if such a state does not already exist. If there is no S- 1632 PMSI for then the PE adds an I-PMSI to the outgoing 1633 interface list of the state if it is not already there. If there is 1634 an S-PMSI for then the PE add S-PMSI to the outgoing 1635 interface list of the state if it is not already there. 1637 11.3.1.2. Receiving Shared Tree Join C-multicast route 1639 If the received route has the route type set to Shared Tree Join, 1640 then the PE creates a new state in its MVPN-TIB with the 1641 RP address for that state taken from the Multicast Source, and C-G 1642 for that state taken from the Multicast Group fields of the MCAST-VPN 1643 NLRI of the route, if such a state does not already exist. If there 1644 is no S-PMSI for (C-*, C-G), then the PE adds I-PMSI to the outgoing 1645 interface list of the state if it is not already there. If there is 1646 an S-PMSI for , then the PE adds S-PMSI to the outgoing 1647 interface list of the state if it is not already there. 1649 11.3.2. Receiving routes: mLDP as the C-Multicast protocol 1651 The following described procedures when mLDP is used as the multicast 1652 routing protocol between CE and PE (C-multicast protocol). 1654 When mLDP is used as a C-multicast protocol, the only valid type of a 1655 C-multicast route that a PE could receive is a Source Tree Join C- 1656 multicast route. 1658 When the PE receives a Source Tree Join C-multicast route, the PE 1659 applies, in the scope of this VRF, the P2MP mLDP procedures for a 1660 transit node using the value carried in the Multicast Source field of 1661 the route as the C-Root Node Identifier, and the value carried in the 1662 Multicast Group of the route as the C-Generic LSP Identifier Value. 1664 If there is no S-PMSI for then the PE creates and advertises an S-PMSI as 1666 described in Section "Using S-PMSI A-D routes to Bind C-trees to P- 1667 tunnels" using C-Root Node Identifier as the value for the Multicast 1668 Source field of the S-PMSI A-D route and C-Generic LSP Identifier 1669 Value as the value for the Multicast Group field of the route. 1671 To improve scalability when mLDP is used as the C-Multicast protocol 1672 for a given MVPN, within each AS that has sites of that MVPN 1673 connected to the PEs of that AS, all the S-PMSIs of that MVPN MAY be 1674 aggregated into a single P-Multicast tree (by using upstream assigned 1675 labels). 1677 11.4. C-multicast routes aggregation 1679 Note that C-multicast routes are "de facto" aggregated by BGP. This 1680 is because the MCAST-VPN NLRIs advertised by multiple PEs, for a C- 1681 multicast route for a particular C-S and C-G (or a particular C-* and 1682 C-G) of a given MVPN are identical. 1684 Hence a BGP Route Reflector or ASBR that receives multiple such 1685 routes with the same NLRI will re-advertise only one of these routes 1686 to other BGP speakers. 1688 This implies that C-multicast routes for a given (S,G) of a given 1689 MVPN originated by PEs that are clients of a given Route Reflector 1690 are aggregated by the Route Reflector. For instance, if multiple PEs 1691 that are clients of a Route Reflector, have receivers for a specific 1692 SSM channel of a MVPN, they will all advertise an identical NLRI for 1693 the "Source Tree Join" C-multicast route. However only one C- 1694 multicast route will be advertised by the Route Reflector for this 1695 specific SSM channel of that MVPN, to other PEs and Route Reflectors 1696 that are clients of the Route Reflector. 1698 This also implies that an ASBR aggregates all the received C- 1699 multicast routes for a given (S,G) (or a given (*,G)) of a given MVPN 1700 into a single C-multicast route. 1702 To further reduce the routing churn due to C-multicast routes changes 1703 a Route Reflector that re-advertises a C-multicast route SHOULD set 1704 the Next Hop field of the MP_REACH_NLRI attribute of the route to an 1705 IP address of the Route Reflector. Likewise, an ASBR that re- 1706 advertises a C-multicast route SHOULD set the Next Hop field of the 1707 MP_REACH_NLRI attribute of the route to an IP address of the ASBR. 1709 Further a BGP receiver, that receives multiple such routes with the 1710 same NLRI for the same C-multicast route, will potentially create 1711 forwarding state based on a single C-multicast route. As per the 1712 procedures described in Section "Receiving C-Multicast Routes by a 1713 PE", this forwarding state will be the same as the state that would 1714 have been created based an other route with same NLRI. 1716 12. Using S-PMSI A-D routes to Bind C-trees to P-tunnels 1718 This section describes BGP-based procedures for using S-PMSIs A-D 1719 routes to bind (C-S, C-G) trees to P-tunnels. 1721 12.1. Originating S-PMSI A-D routes 1723 The following describes procedures for originating S-PMSI A-D routes 1724 by a PE. 1726 The PE constructs the MCAST-VPN NLRI of an S-PMSI A-D route for a 1727 given as follows. 1729 + The RD in this NLRI is set to the RD of the MVPN's VRF associated 1730 with . 1732 + The Multicast Source field MUST contain the source address 1733 associated with the C-multicast stream, and the Multicast Source 1734 Length field is set appropriately to reflect this. 1736 + The Multicast Group field MUST contain the group address 1737 associated with the C-multicast stream, and the Multicast Group 1738 Length field is set appropriately to reflect this. 1740 + The Originating Router's IP Address field MUST be set to the IP 1741 address that the (local) PE places in the Global Administrator 1742 field of the VRF Route Import extended community of the VPN-IP 1743 routes advertised by the PE. Note that the tuple uniquely identifies a given multicast 1745 VRF. 1747 The PE constructs the rest of the S-PMSI A-D route as follows. 1749 Depending on the type of a P-Multicast tree used for the P-tunnel, 1750 the PMSI tunnel attribute of the S-PMSI A-D route is constructed as 1751 follows: 1753 + The PMSI tunnel attribute MUST contain the identity of the P- 1754 Multicast tree (note that the PE could create the identity of the 1755 tree prior to the actual instantiation of the tree). 1757 + If in order to establish the P-Multicast tree the PE needs to 1758 know the leaves of the tree within its own AS, then the PE 1759 obtains this information from the Leaf A-D routes received from 1760 other PEs/ASBRs within its own AS (as other PEs/ASBRs originate 1761 Leaf A-D routes in response to receiving the S-PMSI A-D route) by 1762 setting the Leaf Information Required flag in the PMSI Tunnel 1763 attribute to 1. 1765 + If a PE originates S-PMSI A-D routes with the Leaf Information 1766 Required flag in the PMSI Tunnel attribute set to 1, then the PE 1767 MUST be (auto)configured with an import Route Target, which 1768 controls acceptance of Leaf A-D routes by the PE. 1770 This Route Target is IP address specific. The Global 1771 Administrator field of this Route Target MUST be set to the IP 1772 address carried in the Next Hop of all the S-PMSI A-D routes 1773 advertised by this PE (if the PE uses different Next Hops, then 1774 the PE MUST be (auto)configured with multiple import RTs, one per 1775 each such Next Hop). The Local Administrator field of this Route 1776 Target MUST be set to 0. 1778 If the PE supports Route Target Constrain [RT-CONSTRAIN], the PE 1779 SHOULD advertise this import Route Target within its own AS using 1780 Route Target Constrains. To constrain distribution of the Route 1781 Target Constrain routes to the AS of the advertising PE these 1782 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 1784 + A PE MAY aggregate two or more S-PMSIs originated by the PE onto 1785 the same P-Multicast tree. If the PE already advertises S-PMSI A- 1786 D routes for these S-PMSIs, then aggregation requires the PE to 1787 re-advertise these routes. The re-advertised routes MUST be the 1788 same as the original ones, except for the PMSI tunnel attribute. 1789 If the PE has not previously advertised S-PMSI A-D routes for 1790 these S-PMSIs, then the aggregation requires the PE to advertise 1791 (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel 1792 attribute in the newly advertised/re-advertised routes MUST carry 1793 the identity of the P-Multicast tree that aggregates the S-PMSIs. 1794 If at least some of the S-PMSIs aggregated onto the same P- 1795 Multicast tree belong to different MVPNs, then all these routes 1796 MUST carry an MPLS upstream assigned label [MPLS-UPSTREAM]. If 1797 all these aggregated S-PMSIs belong to the same MVPN, then the 1798 routes MAY carry an MPLS upstream assigned label [MPLS-UPSTREAM]. 1799 The labels MUST be distinct on a per MVPN basis, and MAY be 1800 distinct on a per route basis. 1802 The Next Hop field of the MP_REACH_NLRI attribute of the route SHOULD 1803 be set to the same IP address as the one carried in the Originating 1804 Router's IP Address field. 1806 By default the set of Route Targets carried by the route MUST be a 1807 set intersection between the set of Route Targets carried in the 1808 intra-AS I-PMSI A-D route originated from the VRF, and the set of 1809 Route Targets carried by the (unicast) VPN-IP route to C-S originated 1810 originated from the VRF. The default could be modified via 1811 configuration. 1813 12.2. Handling S-PMSI A-D routes by ASBRs 1815 Procedures for handling an S-PMSI A-D route by ASBRs (both within and 1816 outside of the AS of the PE that originates the route) are the same 1817 as specified in Section "Propagating Inter-AS Auto-Discovery 1818 Information", except that instead of Inter-AS I-PMSI A-D routes the 1819 procedures apply to S-PMSI A-D routes. 1821 12.2.1. Merging S-PMSI into an I-PMSI 1823 Consider the situation where: 1825 + An ASBR is receiving (or expecting to receive) inter-AS (C-S, C- 1826 G) data from upstream via an S-PMSI. 1828 + The ASBR is sending (or expecting to send) the inter-AS (C-S, 1829 C-G) data downstream via an I-PMSI. 1831 This situation may obtain if the upstream providers have a policy of 1832 using S-PMSIs but the downstream providers have a policy of using I- 1833 PMSIs. To support this situation, an ASBR MAY, under certain 1834 conditions, merge one or more upstream S-PMSIs into a downstream I- 1835 PMSI. 1837 An S-PMSI (corresponding to a particular S-PMSI A-D route) MAY be 1838 merged by a particular ASBR into an I-PMSI (corresponding to a 1839 particular Inter-AS I-PMSI A-D route) if and only if the following 1840 conditions all hold: 1842 + BGP is used to exchange C-multicast routes. 1844 + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route originate 1845 in the same AS. The Inter-AS I-PMSI A-D route carries the 1846 originating AS in the Source AS field of the NLRI of the route, 1847 and also in the AS_PATH attribute of the route. The S-PMSI A-D 1848 route carries the originating AS in the AS_PATH attribute of the 1849 route. 1851 + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route have 1852 exactly the same set of RTs. 1854 + For each (C-S,C-G) mentioned in the S-PMSI route, if the ASBR has 1855 installed a Source Tree Join (C-S, C-G) C-multicast route, then 1856 the S-PMSI route was originated by the upstream PE of the C- 1857 multicast route. The address of the upstream PE is carried in the 1858 RT of the C-multicast route. The address of the PE that 1859 originated the S-PMSI route is carried in the Originating 1860 Router's IP Addr field of the MCAST-VPN NLRI of the route. 1862 + The ASBR supports the optional capability to discard (C-S, C-G) 1863 traffic received on an I-PMSI. 1865 An ASBR performs merging by stitching the tail end of the P-tunnel, 1866 as specified in the the PMSI Tunnel Attribute of the S-PMSI A-D route 1867 received by the ASBR, to the to the head of the P-tunnel, as 1868 specified in the PMSI Tunnel Attribute of the Inter-AS I-PMSI A-D 1869 route re-advertised by the ASBR. 1871 IP processing during merge: If an ASBR merges an (C-S, C-G) S-PMSI A- 1872 D route into an Inter-AS I-PMSI A-D route, the ASBR MUST discard all 1873 (C-S, C-G) traffic it receives on the tunnel advertised in the I-PMSI 1874 A-D route. 1876 An ASBR that merges an S-PMSI A-D route into an Inter-AS I-PMSI A-D 1877 route MUST NOT re-advertise the S-PMSI A-D route. 1879 12.3. Receiving S-PMSI A-D routes by PEs 1881 Consider a PE that receives an S-PMSI A-D route. If one or more of 1882 the VRFs on the PE have their import Route Targets that contain one 1883 or more of the Route Targets carried by the received S-PMSI A-D 1884 route, then for each such VRF (and associated with it MVPN-TIB) the 1885 PE performs the following. 1887 Procedures for receiving an S-PMSI A-D route by a PE (both within and 1888 outside of the AS of the PE that originates the route) are the same 1889 as specified in Section "Inter-AS I-PMSI A-D route received via IBGP" 1890 except that (a) instead of Inter-AS I-PMSI A-D routes the procedures 1891 apply to S-PMSI A-D routes, and (b) a PE performs procedures 1892 specified in that section only if in addition to the criteria 1893 specified in that section all of the following is true: 1895 + The PE has in its MVPN-TIB the state for either (C-*, C-G) or (C- 1896 S, C-G), where C-S is the Multicast Source and C-G is the 1897 Multicast Group carried in the S-PMSI A-D route, and the oif 1898 (outgoing interfaces) for this state contains one or more 1899 interfaces to the locally attached CEs. 1901 + Either (a) the PE originates a Source Tree Join (C-S, C-G) C- 1902 multicast route, and the upstream PE of that route is the PE that 1903 originates the S-PMSI A-D route, or (b) the PE does not originate 1904 a Source Tree Join (C-S, C-G) C-multicast route, and the best (as 1905 determined by the BGP route selection procedures) Source Active 1906 A-D route for (C-S, C-G) selected by the PE is originated by the 1907 same PE as the one that originates the S-PMSI A-D route. 1909 Note that if the received S-PMSI A-D route has a PMSI Tunnel 1910 attribute with the Leaf Information bit set, then the above 1911 procedures may cause the origination of a Leaf A-D route whose Route 1912 Key is set to the NLRI of the S-PMSI A-D route. 1914 In addition to the procedures specified in Section "Inter-AS I-PMSI 1915 A-D route received via IBGP" the PE MUST set up its forwarding path 1916 to receive (C-S, C-G) traffic from the tunnel advertised by the S- 1917 PMSI A-D route (the PE MUST switch to the S-PMSI). 1919 13. Switching from Shared C-tree to Source C-tree 1921 The procedures defined in this section only apply when the C- 1922 multicast routing protocol is PIM [RFC4601], moreover only apply for 1923 the multicast ASM mode, and MUST NOT be applied to Multicast Group 1924 addresses belonging to the SSM range. The procedures also MUST NOT be 1925 applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015]. 1927 The procedures of this section are applicable only to MVPNs that use 1928 both shared (i.e., rooted at a C-RP) and source (i.e., rooted at a C- 1929 S) inter-site C-trees. 1931 These procedures are not applicable to MVPNs that do not use shared 1932 inter-site C-trees and rely solely on source inter-site C-trees. See 1933 section ""Supporting PIM-SM without Inter-Site C-Shared Trees" for 1934 the procedures applicable to that scenario. 1936 Whether a given MPVN uses both inter-site shared and source C-trees 1937 or not must be known a priori (e.g., via provisioning). 1939 In the scenario where an MVPN customer switches from an C-RP based 1940 tree (RPT) to the shortest path tree (SPT), in order to avoid packet 1941 duplication choosing of a single consistent upstream PE, as described 1942 in [MVPN], may not suffice. To illustrate this consider a set of PEs 1943 {PE2, PE4, PE6} that are on the C-RP tree for and have 1944 chosen a consistent upstream PE, as described in [MVPN], for state. Further this upstream PE, say PE1, is using an MI-PMSI for 1946 . If a site attached to one of these PEs, say PE2, switches 1947 to the C-S tree for , PE2 generates a Source Tree Join C- 1948 multicast route towards the upstream PE that is on the path to C-S, 1949 say PE3. PE3 also uses the MI-PMSI for , as PE1 uses for 1950 . This results in {PE2, PE4, PE6} receiving duplicate 1951 traffic for - both on the C-RP tree (from PE1) and C-S 1952 tree (from PE3). If it is desirable to suppress receiving duplicate 1953 traffic then it is necessary to choose a single forwarder PE for . The following describes how this is achieved. 1956 13.1. Source Within a Site - Source Active Advertisement 1958 Whenever a PE creates an state as a result of receiving a 1959 Source Tree Join C-multicast route for from some other PE, 1960 the PE that creates the state MUST originate a Source Active A-D 1961 route. The route carries a single MCAST-VPN NLRI constructed as 1962 follows: 1964 + The RD in this NLRI is set to the RD of the VRF of the MVPN on 1965 the PE. 1967 + The Multicast Source field MUST be set to C-S. The Multicast 1968 Source Length field is set appropriately to reflect this. 1970 + The Multicast Group field MUST be set to C-G. The Multicast Group 1971 Length field is set appropriately to reflect this. 1973 The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the 1974 IP address that the PE places in the Global Administrator field of 1975 the VRF Route Import extended community of the VPN-IP routes 1976 advertised by the PE from the MVPN's VRF. 1978 The route SHOULD carry the same set of Route Targets as the Intra-AS 1979 I-PMSI A-D route of the MVPN originated by the PE. 1981 Using the normal BGP procedures the Source Active A-D route is 1982 propagated to all the PEs of the MVPN. 1984 Whenever the PE deletes the state that was previously 1985 created as a result of receiving a Source Tree Join C-multicast route 1986 for from some other PE, the PE that deletes the state MUST 1987 also withdraw the Source Active A-D route, if such a route was 1988 advertised when the state was created. 1990 13.2. Receiving Source Active A-D route 1992 When a PE receives a new Source Active A-D route, the PE finds a VRF 1993 whose import Route Targets match one or more of the Route Targets 1994 carried by the route. If the match is found, then the PE updates the 1995 VRF with the received route. 1997 We say that a given (C-S, C-G) Source Active A-D route stored in a 1998 given VRF matches a given entry present in the MVPN-TIB 1999 associated with the VRF if C-G carried by the route is the same as C- 2000 G of the entry. 2002 When (as a result of receiving PIM messages from one of its CEs) a PE 2003 creates in one of its MVPN-TIBs a (new) entry with a non- 2004 empty outgoing interface list that contains one or more PE-CE 2005 interfaces, the PE MUST check if it has any matching Source Active A- 2006 D routes. If there is one or more such matching route, such that the 2007 PE does not have (C-S, C-G) state in its MVPN-TIB for (C-S, C-G) 2008 carried in the route, then the PE selects one of them (using the BGP 2009 route selection procedures), and sets up its forwarding path to 2010 receive (C-S, C-G) traffic from the tunnel the originator of the 2011 selected Source Active A-D route uses for sending (C-S, C-G). 2013 When as a result of receiving a new Source Active A-D route a PE 2014 updates its VRF with the route, the PE MUST check if the newly 2015 received route matches any entries. If (a) there is a 2016 matching entry, (b) the PE does not have (C-S, C-G) state in its 2017 MVPN-TIB for (C-S, C-G) carried in the route, and (c) the received 2018 route is selected as the best(using the BGP route selection 2019 procedures), then the PE sets up its forwarding path to receive (C-S, 2020 C-G) traffic from the tunnel the originator of the selected Source 2021 Active A-D route uses for sending (C-S, C-G). 2023 13.2.1. Pruning Sources off the Shared Tree 2025 If the incoming interface list (iif) for the found 2026 entry in the MVPN-TIB on the PE contains one of the PE-CE 2027 interfaces (interfaces from the PE to its directly connected CEs), 2028 then the PE MUST check to see if there is already a entry in the MVPN-TIB. If there is not, the PE SHOULD 2030 start a timer. The value of the timer MUST be configurable. Once 2031 the timer expires (or immediately if the timer is not used), the PE 2032 creates a entry. C-S of this entry is set to 2033 the address carried in the Multicast Source field of the 2034 received Source Active A-D route, and C-G of this entry is set to 2035 the address carried in the Multicast Group field of the 2036 route. Creating this entry results in pruning traffic off 2037 the shared (RPT) tree. 2039 As a result of creating the entry in the MVPN- 2040 TIB, the PE will use PIM to prune C-S off the tree. The 2041 purpose of this timer is to ensure that C-S is not pruned off the 2042 shared tree until all PEs have had time to receive the Source Active 2043 A-D route for . 2045 The timer is canceled if the PE no longer has at least one Source 2046 Active A-D route for . 2048 The PE maintains the entry for as long as it has 2049 at least one Source Active A-D route for . 2051 14. Supporting PIM-SM without Inter-Site Shared C-trees 2053 The procedures defined in this section only apply when the C- 2054 multicast routing protocol is PIM [RFC4601], moreover only apply for 2055 the multicast ASM mode, and MUST NOT be applied to Multicast Group 2056 addresses belonging to the SSM range. The procedures also MUST NOT be 2057 applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015]. 2059 The procedures of this section are applicable only to MVPNs that do 2060 not use inter-site shared (i.e., rooted at a C-RP) C-trees. 2062 These procedures are not applicable to MVPNs that use both shared and 2063 shortest path inter-site C-trees. See section "Switching from Shared 2064 C-trees to Source C-trees" for the procedures applicable to that 2065 scenario. 2067 Whether a given MPVN uses inter-site shared C-trees or not must be 2068 known a priori (e.g., via provisioning). 2070 14.1. Discovering Active Multicast Sources 2072 A PE can obtain information about active multicast sources within a 2073 given MVPN in a variety of ways. One way is for the PE to act as a 2074 fully functional customer RP (C-RP) for that MVPN. Another way is to 2075 use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information 2076 about active multicast sources from one or more of the MVPN C-RPs to 2077 the PE. Yet another way is to use MSDP [MSDP] to convey information 2078 about active multicast sources from the MVPN C-RPs to the PE. 2080 When a PE using any of the above methods first learns of a new 2081 (multicast) source within that MVPN, the PE constructs a Source 2082 Active A-D route, and sends this route to all other PEs that have one 2083 or more sites of that MVPN connected to them. The route carries a 2084 single MCAST-VPN NLRI constructed as follows: 2086 + The RD in this NLRI is set to the RD of the VRF of the MVPN on 2087 the PE. 2089 + The Multicast Source field MUST be set to the source IP address 2090 of the multicast data packet carried in the PIM-Register message. 2091 The Multicast Source Length field is set appropriately to reflect 2092 this. 2094 + The Multicast Group field MUST be set to the group address of the 2095 multicast data packet carried in the PIM-Register message. The 2096 Multicast Group Length field is set appropriately to reflect 2097 this. 2099 The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the 2100 IP address that the PE places in the Global Administrator field of 2101 the VRF Route Import extended community of the VPN-IP routes 2102 advertised by the PE. 2104 The route SHOULD carry the same set of Route Targets as the Intra-AS 2105 I-PMSI A-D route of the MVPN originated by the PE. 2107 Using the normal BGP procedures the Source Active A-D route is 2108 propagated to all the PEs of the MVPN. 2110 When a PE that previously advertised a Source Active A-D route for a 2111 given (multicast) source learns that the source is no longer active 2112 (the PE learns this by using the same mechanism by which the PE 2113 learned that the source was active), the PE SHOULD withdraw the 2114 previously advertised Source Active route. 2116 14.2. Receiver(s) Within a Site 2118 A PE follows the procedures specified in Section "Originating C- 2119 multicast routes by a PE", except that the procedures specified in 2120 Section "Originating Shared Tree Join C-multicast route" are replaced 2121 with the procedures specified in this Section below. 2123 When a PE receives a new Source Active A-D route, the PE finds a VRF 2124 whose import Route Targets match one or more of the Route Targets 2125 carried by the route. If the match is found, then the PE updates the 2126 VRF with the received route. 2128 We say that a given (C-S, C-G) Source Active A-D route stored in a 2129 given VRF matches a given entry present in the MVPN-TIB 2130 associated with the VRF if C-G carried by the route is the same as C- 2131 G of the entry. 2133 When (as a result of receiving PIM messages from one of its CEs) a PE 2134 creates in one of its MVPN-TIBs a (new) entry with a non- 2135 empty outgoing interface list that contains one or more PE-CE 2136 interfaces, the PE MUST check if it has any matching Source Active A- 2137 D routes. If there is one or more such matching routes, and the best 2138 path to C-S carried in the matching route(s) is reachable through 2139 some other PE, then for each such route the PE MUST originate a 2140 Source Tree Join C-multicast route. If there is one or more such 2141 matching routes, and the best path to C-S carried in the matching 2142 route(s) is reachable through a CE connected to the PE, then for each 2143 such route the PE MUST originate a PIM Join (C-S, C-G) towards the 2144 CE. 2146 When as a result of receiving a new Source Active A-D route a PE 2147 updates its VRF with the route, the PE MUST check if the newly 2148 received route matches any entries. If there is a matching 2149 entry, and the best path to C-S carried in the (A-D) route is 2150 reachable through some other PE, the PE MUST originate a Source Tree 2151 Join C-multicast route for the (C-S, C-G) carried by the route. If 2152 there is a matching entry, and the best path to C-S carried in the 2153 (A-D) route is reachable through a CE connected to the PE, the PE 2154 MUST originate a PIM Join (C-S, C-G) towards the CE. 2156 Construction and distribution of the Source Tree Join C-multicast 2157 route follows the procedures specified in Section "Originating Source 2158 Tree Join C-multicast route", except that the Multicast Source 2159 Length, Multicast Source, Multicast Group Length, and Multicast Group 2160 fields in the MCAST-VPN NLRI of the Source Tree Join C-multicast 2161 route are copied from the corresponding field in the Source Active A- 2162 D route. 2164 A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C- 2165 G) if, as a result of having received PIM messages from one of its 2166 CEs, the PE creates a Prune upstream state in one 2167 of its MVPN-TIBs, but has no Joined state in that MVPN- 2168 TIB, and had previously advertised the said route. (This is even if 2169 the VRF associated with the MVPN-TIB still has a (C-S, C-G) Source 2170 Active A-D route). 2172 A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C- 2173 G) if the Source Active A-D route that triggered the advertisement of 2174 the C-multicast route is withdrawn. 2176 Even though PIM is used as a C-multicast protocol, procedures 2177 described in Section "Originating Shared Tree Join C-multicast route" 2178 do not apply here, as only the Source Tree Join C-multicast routes 2179 are exchanged among PEs. 2181 14.3. Receiving C-multicast routes by a PE 2183 In this model the only valid type of a C-multicast route that a PE 2184 could receive is a Source Tree Join C-multicast route. Processing of 2185 such a route follows the procedures specified in Section "Receiving 2186 Source Tree Join C-multicast route". 2188 15. Carrier's Carrier 2190 A way to support the Carrier's Carrier model is provided by using 2191 mLDP as the CE-PE multicast routing and label distribution protocol, 2192 as specified in this document. 2194 To improve scalability it is RECOMMENDED that for the Carrier's 2195 Carrier scenario within an AS all the S-PMSIs of a given MVPN be 2196 aggregated into a single P-Multicast tree (by using upstream assigned 2197 labels). 2199 16. Scalability Considerations 2201 A PE should use Route Target Constrain [RT-CONSTRAIN] to advertise 2202 the Route Targets that the PE uses for the VRF Route Imports extended 2203 community (note that doing this requires just a single Route Target 2204 Constraint advertisement by the PE). This allows each C-multicast 2205 route to reach only the relevant PE, rather than all the PEs 2206 participating the an MVPN. 2208 To keep the intra-AS membership/binding information within the AS of 2209 the advertising router the BGP Update message originated by the 2210 advertising router SHOULD carry the NO_EXPORT Community ([RFC1997]). 2212 An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra- 2213 AS I-PMSI A-D routes originated within the ASBR's own AS. Thus while 2214 the Intra-AS I-PMSI A-D routes originated within an AS are at the 2215 granularity of within that AS, outside of that AS the 2216 (aggregated) Inter-AS I-PMSI A-D routes are at the granularity of 2217 . An Inter-AS I-PMSI A-D route for a given 2218 indicates the presence of or or more sites of the MVPN connected to 2219 the PEs of the AS. 2221 For a given inter-AS tunnel each of its intra-AS segments could be 2222 constructed by its own mechanism. Moreover, by using upstream 2223 assigned labels within a given AS multiple intra-AS segments of 2224 different inter-AS tunnels of either the same or different MVPNs may 2225 share the same P-Multicast tree. 2227 Since (aggregated) Inter-AS I-PMSI A-D routes may have granularity of 2228 , an MVPN that is present in N ASes would have total of N 2229 inter-AS tunnels. Thus for a given MVPN the number of inter-AS 2230 tunnels is independent of the number of PEs that have this MVPN. 2232 Within each Autonomous System BGP Route reflectors can be partitioned 2233 among MVPNs present in that Autonomous System so that each partition 2234 carries routes for only a subset of the MVPNs supported by the 2235 Service Provider. Thus no single Route Reflector is required to 2236 maintain routes for all MVPNs. Moreover, Route Reflectors used for 2237 MVPN do not have to be used for VPN-IP routes (although they may be 2238 used for VPN-IP routes as well). 2240 As described in Section "C-multicast routes aggregation", C-multicast 2241 routes for a given (S,G) of a given MVPN originated by PEs that are 2242 clients of a given Route Reflector are aggregated by the Route 2243 Reflector. Therefore, even if within a Route Reflector cluster there 2244 are multiple C-multicast routes for a given (S,G) of a given MVPN, 2245 outside of the cluster all these routes are aggregated into a single 2246 C-multicast route. Additional aggregation of C-multicast routes 2247 occurs at ASBRs, where an ASBR aggregates all the received C- 2248 multicast routes for a given (S,G) of a given MVPN into a single C- 2249 multicast route. Moreover, both Route Reflectors and ASBRs maintain 2250 C-multicast routes only in the control plane, but not in the data 2251 plane. 2253 16.1. Dampening C-multicast routes 2255 The rate of C-multicast routing changes advertised by a PE is not 2256 necessarily directly proportional to the rate of multicast routing 2257 changes within the MVPN sites connected to the PE, as after the first 2258 Join originated within a site, all the subsequent Joins for 2259 same originated within the sites of the same MVPN connected 2260 to the PE do not cause origination of new C-multicast routes by the 2261 PE. 2263 Depending on how multicast VPN is engineered, dynamic addition and 2264 removal of P2MP RSVP-TE leaves through advertisement/withdrawal of 2265 Leaf A-D routes, will happen. Dampening techniques can be used to 2266 limit corresponding processing. 2268 To lessen the control plane overhead associated with processing of C- 2269 multicast routes, this document proposes OPTIONAL route dampening 2270 procedures similar to what is described in RFC2439. The following 2271 OPTIONAL procedures can be enabled on a PE, ASBR, or BGP Route 2272 Reflector advertising or receiving C-multicast routes. 2274 16.1.1. Dampening withdrawals of C-multicast routes 2276 A PE/ASBR/Route Reflector can OPTIONALLY delay the advertisement of 2277 withdrawals of C-multicast routes. An implementation SHOULD provide 2278 the ability to control the delay via a configurable timer, possibly 2279 with some backoff algorithm to adapt the delay to multicast routing 2280 activity. 2282 Dampening of withdrawals of C-multicast routes does not impede the 2283 multicast join latency observed by MVPN customers, and also does not 2284 impede the multicast leave latency observed by a CE, as multicast 2285 forwarding from the VRF will stop as soon as C-multicast state is 2286 removed in the VRF. 2288 The potential drawbacks of dampening of withdrawals of C-multicast 2289 routes are: 2291 + Until the withdrawls are actually sent, multicast traffic for the 2292 C-multicast routes in question will be continued to be 2293 transmitted to the PE, which will just have to discard it. Note 2294 that the PE may receive useless (multicast) traffic anyway, 2295 irrespective of dampening of withdrawals of C-multicast routes 2296 due to the use of I-PMSIs. 2298 + Any state in the upstream PEs that would be removed as a result 2299 of processing the withdrawls will remain until the withdrawls are 2300 sent. 2302 Discussion on whether the potential drawbacks mentioned above are of 2303 any practical significance is outside the scope of this document. 2305 16.1.2. Dampening Source/Shared Tree Join C-multicast routes 2307 A PE/ASBR/Route Reflector can OPTIONALLY delay the advertisement of 2308 Source/Shared Tree Join C-multicast routes. An implementation SHOULD 2309 provide the ability to control the delay via a configurable timer, 2310 possibly with some backoff algorithm to adapt the delay to multicast 2311 routing activity. 2313 Dampening Source/Shared Tree Join C-multicast routes will not impede 2314 multicast join latency observed by a given MVPN, except if the PE 2315 advertising the Source/Shared Tree Join C-multicast route for a 2316 particular C-S/C-RP is the first to do so for all the sites of the 2317 MVPN that share the same upstream PE with respect to the C-S/C-RP. 2319 16.2. Dampening withdrawals of Leaf A-D routes 2321 Similarly to the procedures proposed above for withdrawal of C- 2322 multicast routes, dampening can be applied to the withdrawal of Leaf 2323 A-D routes. 2325 17. IANA Consideration 2327 This document defines a new BGP Extended Community called Source AS. 2328 This community is 2-octet AS specific, of an extended type, and is 2329 transitive. 2331 This document defines a new BGP Extended Community called VRF Route 2332 Import. This community is IP address specific, of an extended type, 2333 and is transitive. 2335 This document defines a new NLRI, called MCAST-VPN, to be carried in 2336 BGP using multiprotocol extensions. It requires assignment of a new 2337 SAFI. 2339 This document defines a new BGP optional transitive attribute, called 2340 PMSI Tunnel. 2342 18. Security Considerations 2344 The mechanisms described in this document could re-use the existing 2345 BGP security mechanisms. 2347 19. Acknowledgement 2349 Some of the text in Section "Supporting PIM-SM without Inter-Site 2350 Shared C-trees" has been taken almost verbatim from RFC3618. 2352 20. References 2354 20.1. Normative References 2356 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace 2358 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP 2359 VPNs", draft-ietf-l3vpn-2547bis-mcast 2361 [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", 2362 RFC1997, August 1996. 2364 [RFC2119] "Key words for use in RFCs to Indicate Requirement 2365 Levels.", Bradner, RFC2119, March 1997. 2367 [RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 2368 4 (BGP-4)", RFC 4271, January 2006 2370 [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 2371 "Multiprotocol Extensions for BGP-4", RFC 2858, January 2007. 2373 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 2374 Communities Attribute", RFC 4360, February 2006. 2376 [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks 2377 (VPNs)", RFC4364, February 2006 2379 [RFC4601] B. Fenner et. al., "Protocol Independent Multicast - Sparse 2380 Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2381 2006 2383 20.2. Informative References 2385 [MPLS-UPSTREAM] R. Aggrwal, Y. Rekhter, E. Rosen, " MPLS Upstream 2386 Label Assignment and Context Specific Label Space", draft-ietf-mpls- 2387 upstream-label 2389 [RT-CONSTRAIN] P. Marques et. al., "Constrained Route Distribution 2390 for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 2391 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 2392 November 2006 2394 [mLDP] I. Minei et. al., "Label Distribution Protocol Extensions for 2395 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 2396 Paths", draft-ietf-mpls-ldp-p2mp 2398 [RFC4607] H. Holbrook, B. Cain "Source-Specific Multicast for IP", 2399 RFC 4607, August 2006 2401 [RFC5015] M. Handley et. al., "Bidirectional Protocol Independent 2402 Multicast (BIDIR-PIM)", RFC5015, October 2007 2404 [RSVP-TE-P2MP] R. Aggarwal et. al., "Extensions to RSVP-TE for Point- 2405 to-Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp 2407 [PIM-ANYCAST-RP] D. Farinacci, Y. Cai, "Anycast-RP using PIM" RFC 2408 4610, August 2006 2410 [MSDP] B. Fenner, D. Meyer, "Multicast Source Discovery Protocol 2411 (MSDP)", RFC3618, October 2003 2413 21. Author's Address 2415 Rahul Aggarwal 2416 Juniper Networks 2417 1194 North Mathilda Ave. 2418 Sunnyvale, CA 94089 2419 Email: rahul@juniper.net 2421 Eric C. Rosen 2422 Cisco Systems, Inc. 2423 1414 Massachusetts Avenue 2424 Boxborough, MA, 01719 2425 E-mail: erosen@cisco.com 2427 Thomas Morin 2428 France Telecom R & D 2429 2, avenue Pierre-Marzin 2430 22307 Lannion Cedex 2431 France 2432 Email: thomas.morin@francetelecom.com 2434 Yakov Rekhter 2435 Juniper Networks 2436 1194 North Mathilda Ave. 2437 Sunnyvale, CA 94089 2438 Email: yakov@juniper.net 2440 Chaitanya Kodeboniya 2442 22. Intellectual Property Statement 2444 The IETF takes no position regarding the validity or scope of any 2445 Intellectual Property Rights or other rights that might be claimed to 2446 pertain to the implementation or use of the technology described in 2447 this document or the extent to which any license under such rights 2448 might or might not be available; nor does it represent that it has 2449 made any independent effort to identify any such rights. Information 2450 on the procedures with respect to rights in RFC documents can be 2451 found in BCP 78 and BCP 79. 2453 Copies of IPR disclosures made to the IETF Secretariat and any 2454 assurances of licenses to be made available, or the result of an 2455 attempt made to obtain a general license or permission for the use of 2456 such proprietary rights by implementers or users of this 2457 specification can be obtained from the IETF on-line IPR repository at 2458 http://www.ietf.org/ipr. 2460 The IETF invites any interested party to bring to its attention any 2461 copyrights, patents or patent applications, or other proprietary 2462 rights that may cover technology that may be required to implement 2463 this standard. Please address the information to the IETF at ietf- 2464 ipr@ietf.org. 2466 23. Copyright Notice 2468 Copyright (C) The IETF Trust (2008). 2470 This document is subject to the rights, licenses and restrictions 2471 contained in BCP 78, and except as set forth therein, the authors 2472 retain all their rights. 2474 This document and the information contained herein are provided on an 2475 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2476 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2477 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2478 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2479 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2480 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.