idnits 2.17.1 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1, 2009) is 5314 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 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: April 2010 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 October 1, 2009 17 BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs 19 draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright and License Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents in effect on the date of 48 publication of this document (http://trustee.ietf.org/license-info). 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Abstract 66 This document describes the BGP encodings and procedures for 67 exchanging the information elements required by Multicast in MPLS/BGP 68 IP VPNs, as specified in [MVPN]. 70 Table of Contents 72 1 Specification of requirements ......................... 4 73 2 Introduction .......................................... 5 74 3 Terminology ........................................... 5 75 4 MCAST-VPN NLRI ........................................ 6 76 4.1 Intra-AS I-PMSI A-D route ............................. 7 77 4.2 Inter-AS I-PMSI A-D route ............................. 8 78 4.3 S-PMSI A-D route ...................................... 8 79 4.4 Leaf A-D route ........................................ 9 80 4.5 Source Active A-D route ............................... 10 81 4.6 C-multicast route ..................................... 11 82 5 PMSI Tunnel attribute ................................. 12 83 6 Source AS Extended Community .......................... 14 84 7 VRF Route Import Extended Community ................... 15 85 8 PE Distinguisher Labels Attribute ..................... 16 86 9 MVPN Auto-Discovery/Binding ........................... 17 87 9.1 MVPN Auto-Discovery/Binding - Intra-AS Operations ..... 17 88 9.1.1 Originating Intra-AS I-PMSI A-D routes ................ 17 89 9.1.2 Receiving Intra-AS I-PMSI A-D routes .................. 20 90 9.2 MVPN Auto-Discovery/Binding - Inter-AS Operations ..... 21 91 9.2.1 Originating Inter-AS I-PMSI A-D routes ................ 23 92 9.2.2 When not to originate Inter-AS I-PMSI A-D routes ...... 24 93 9.2.3 Propagating Inter-AS I-PMSI A-D routes ................ 24 94 9.2.3.1 Propagating Inter-AS I-PMSI A-D routes - Overview ..... 24 95 9.2.3.2 Inter-AS I-PMSI A-D route received via EBGP ........... 25 96 9.2.3.2.1 Originating Leaf A-D route into EBGP .................. 26 97 9.2.3.3 Leaf A-D route received via EBGP ...................... 27 98 9.2.3.4 Inter-AS I-PMSI A-D route received via IBGP ........... 28 99 9.2.3.4.1 Originating Leaf A-D route into IBGP .................. 30 100 9.2.3.5 Leaf A-D route received via IBGP ...................... 30 101 9.2.3.6 Optimizing Bandwidth by IP filtering on ASBRs ......... 31 102 10 Non-congruent Unicast and Multicast Connectivity ...... 32 103 11 Exchange of C-Multicast Routing Information among PEs . 33 104 11.1 Originating C-multicast routes by a PE ................ 34 105 11.1.1 Originating routes: PIM as the C-Multicast protocol ... 34 106 11.1.1.1 Originating Source Tree Join C-multicast route ........ 34 107 11.1.1.2 Originating Shared Tree Join C-multicast route ........ 34 108 11.1.2 Originating routes: mLDP as the C-Multicast protocol .. 35 109 11.1.3 Constructing the rest of the C-multicast route ........ 35 110 11.1.4 Unicast Route Changes ................................. 37 111 11.2 Propagating C-multicast routes by an ASBR ............. 37 112 11.3 Receiving C-multicast routes by a PE .................. 38 113 11.3.1 Receiving routes: PIM as the C-Multicast protocol ..... 39 114 11.3.1.1 Receiving Source Tree Join C-multicast route .......... 39 115 11.3.1.2 Receiving Shared Tree Join C-multicast route .......... 40 116 11.3.2 Receiving routes: mLDP as the C-Multicast protocol .... 40 117 11.4 C-multicast routes aggregation ........................ 41 118 12 Using S-PMSI A-D routes to Bind C-trees to P-tunnels .. 42 119 12.1 Originating S-PMSI A-D routes ......................... 42 120 12.2 Handling S-PMSI A-D routes by ASBRs ................... 44 121 12.2.1 Merging S-PMSI into an I-PMSI ......................... 45 122 12.3 Receiving S-PMSI A-D routes by PEs .................... 46 123 13 Switching from Shared C-tree to Source C-tree ......... 47 124 13.1 Source Within a Site - Source Active Advertisement .... 48 125 13.2 Receiving Source Active A-D route ..................... 49 126 13.2.1 Pruning Sources off the Shared Tree ................... 50 127 14 Supporting PIM-SM without Inter-Site Shared C-trees ... 51 128 14.1 Discovering Active Multicast Sources .................. 51 129 14.2 Receiver(s) Within a Site ............................. 52 130 14.3 Receiving C-multicast routes by a PE .................. 54 131 15 Carrier's Carrier ..................................... 54 132 16 Scalability Considerations ............................ 54 133 16.1 Dampening C-multicast routes .......................... 55 134 16.1.1 Dampening withdrawals of C-multicast routes ........... 56 135 16.1.2 Dampening Source/Shared Tree Join C-multicast routes .. 57 136 16.2 Dampening withdrawals of Leaf A-D routes .............. 57 137 17 Security Considerations ............................... 57 138 18 IANA Considerations ................................... 58 139 19 Acknowledgement ....................................... 59 140 20 Authors' Addresses .................................... 59 141 21 References ............................................ 59 142 21.1 Normative References .................................. 59 143 21.2 Informative References ................................ 60 145 1. Specification of requirements 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 2. Introduction 153 This document describes the BGP encodings and procedures for 154 exchanging the information elements required by Multicast in MPLS/BGP 155 IP VPNs, as specified in [MVPN]. This document assumes a thorough 156 familiarity with procedures, concepts and terms described in [MVPN]. 158 This document defines a new NLRI, MCAST-VPN NLRI. The MCAST-VPN NLRI 159 is used for MVPN auto-discovery, advertising MVPN to I-PMSI tunnel 160 binding, advertising (C-S, C-G) to S-PMSI tunnel binding, VPN 161 customer multicast routing information exchange among PEs, choosing a 162 single forwarder PE, and for procedures in support of co-locating a 163 C-RP on a PE. 165 This document specifies two new BGP attributes, P-Multicast Service 166 Interface Tunnel (PMSI Tunnel) attribute, and PE Distinguisher Label 167 attribute. 169 This document also defines two new BGP Extended Communities, Source 170 AS Extended Community and VRF Route Import Extended Community. 172 3. Terminology 174 In the context of this document we will refer to the MVPN auto- 175 discovery/binding information carried in BGP as "auto-discovery 176 routes" ("A-D routes"). For a given MVPN there are the following 177 types of A-D routes: 179 + Intra-AS I-PMSI A-D route; 181 + Inter-AS I-PMSI A-D route; 183 + S-PMSI A-D route; 185 + Leaf A-D route; 187 + Source Active A-D route. 189 In the context of this document we will refer to the MVPN customers 190 multicast routing information carried in BGP as "C-multicast routes". 191 For a given MVPN there are the following types of C-multicast routes: 193 + Shared Tree Join route; 194 + Source Tree Join route; 196 For each MVPN present on a PE, the PE maintains a Tree Information 197 Base (MVPN-TIB). This is the same as TIB defined in [RFC4601], except 198 that instead of a single TIB a PE maintains multiple MVPN-TIBs, one 199 per each MVPN. 201 Throughout this draft we will use the term "VPN-IP route" to mean a 202 route which is either in the VPN-IPv4 address family [RFC4364] or in 203 the VPN-IPv6 address family [RFC4659]. 205 4. MCAST-VPN NLRI 207 This document defines a new BGP NLRI, called the MCAST-VPN NLRI. 209 Following is the format of the MCAST-VPN NLRI: 211 +-----------------------------------+ 212 | Route Type (1 octet) | 213 +-----------------------------------+ 214 | Length (1 octet) | 215 +-----------------------------------+ 216 | Route Type specific (variable) | 217 +-----------------------------------+ 219 The Route Type field defines encoding of the rest of MCAST-VPN NLRI 220 (Route Type specific MCAST-VPN NLRI). 222 The Length field indicates the length in octets of the Route Type 223 specific field of MCAST-VPN NLRI. 225 This document defines the following Route Types for A-D routes: 227 + 1 - Intra-AS I-PMSI A-D route; 228 + 2 - Inter-AS I-PMSI A-D route; 229 + 3 - S-PMSI A-D route; 230 + 4 - Leaf A-D route; 231 + 5 - Source Active A-D route. 233 This document defines the following Route Types for C-multicast 234 routes: 236 + 6 - Shared Tree Join route; 237 + 7 - Source Tree Join route; 239 The MCAST-VPN NLRI is carried in BGP [RFC4271] using BGP 240 Multiprotocol Extensions [RFC4760] with an AFI of 1 or 2 and an SAFI 241 of MCAST-VPN. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 242 attribute contains the MCAST-VPN NLRI (encoded as specified above). 243 The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 244 attribute that carries the MCAST-VPN NLRI determines whether the 245 Multicast Source and Multicast Group addresses carried in the S-PMSI 246 A-D routes, Source Active A-D routes, and C-multicast routes are IPv4 247 or IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates 248 IPv6 addresses). 250 In order for two BGP speakers to exchange labeled MCAST-VPN NLRI, 251 they must use BGP Capabilities Advertisement to ensure that they both 252 are capable of properly processing such NLRI. This is done as 253 specified in [RFC4760], by using capability code 1 (multiprotocol 254 BGP) with an AFI of 1 or 2 and an SAFI of MCAST-VPN. 256 The following describes the format of the Route Type specific MCAST- 257 VPN NLRI for various Route Types defined in this document. 259 4.1. Intra-AS I-PMSI A-D route 261 An Intra-AS I-PMSI A-D route type specific MCAST-VPN NLRI consists of 262 the following: 264 +-----------------------------------+ 265 | RD (8 octets) | 266 +-----------------------------------+ 267 | Originating Router's IP Addr | 268 +-----------------------------------+ 270 The RD is encoded as described in [RFC4364]. 272 Usage of Intra-AS I-PMSI A-D routes is described in Section "MVPN 273 Auto-Discovery/Binding - Intra-AS Operations". 275 4.2. Inter-AS I-PMSI A-D route 277 An Inter-AS I-PMSI A-D route type specific MCAST-VPN NLRI consists of 278 the following: 280 +-----------------------------------+ 281 | RD (8 octets) | 282 +-----------------------------------+ 283 | Source AS (4 octets) | 284 +-----------------------------------+ 286 The RD is encoded as described in [RFC4364]. 288 The Source AS contains an Autonomous System number. 290 Two octets AS numbers are encoded in the two low order octets of the 291 Source AS field, with the the two high order octets set to zero. 293 Usage of Inter-AS I-PMSI A-D routes is described in Section "MVPN 294 Auto-Discovery/Binding - Inter-AS Operations". 296 4.3. S-PMSI A-D route 298 An S-PMSI A-D route type specific MCAST-VPN NLRI consists of the 299 following: 301 +-----------------------------------+ 302 | RD (8 octets) | 303 +-----------------------------------+ 304 | Multicast Source Length (1 octet) | 305 +-----------------------------------+ 306 | Multicast Source (Variable) | 307 +-----------------------------------+ 308 | Multicast Group Length (1 octet) | 309 +-----------------------------------+ 310 | Multicast Group (Variable) | 311 +-----------------------------------+ 312 | Originating Router's IP Addr | 313 +-----------------------------------+ 315 The RD is encoded as described in [RFC4364]. 317 The Multicast Source field contains the C-S address. If the Multicast 318 Source field contains an IPv4 address, then the value of the 319 Multicast Source Length field is 32. If the Multicast Source field 320 contains an IPv6 address, then the value of the Multicast Source 321 Length field is 128. 323 The Multicast Group field contains the C-G address or C-LDP MP Opaque 324 Value Element (use of C-LDP MP Opaque Value Element is described in 325 Section "Receiving routes: mLDP as the C-Multicast protocol"). If the 326 Multicast Group field contains an IPv4 address, then the value of the 327 Multicast Group Length field is 32. If the Multicast Group field 328 contains an IPv6 address, then the value of the Multicast Group 329 Length field is 128. 331 Usage of other values of the Multicast Source Length and Multicast 332 Group Length fields is outside the scope of this document. 334 Usage of S-PMSI A-D routes is described in Section "Using S-PMSI A-D 335 routes to Bind C-trees to P-tunnels". 337 4.4. Leaf A-D route 339 A Leaf A-D route type specific MCAST-VPN NLRI consists of the 340 following: 342 +-----------------------------------+ 343 | Route Key (variable) | 344 +-----------------------------------+ 345 | Originating Router's IP Addr | 346 +-----------------------------------+ 348 Leaf A-D routes may be originated as a result of processing a 349 received Inter-AS I-PMSI A-D route or S-PMSI A-D route. A Leaf A-D 350 route is originated in these situations only if the received route 351 has a PMSI Tunnel attribute whose "Leaf Information Required" bit is 352 set to 1. 354 If a Leaf A-D route is originated as a result of processing one of 355 the received routes specified in the previous paragraph, the Route 356 Key of the Leaf A-D route is set to the NLRI of the received route. 358 Details of the use of the Leaf A-D route may be found in Sections 359 "Originating Leaf A-D route into EBGP", "Leaf A-D route received via 360 EBGP", "Originating Leaf A-D route into IBGP", "Leaf A-D route 361 received via IBGP", and "Receiving S-PMSI A-D routes by PEs". 363 4.5. Source Active A-D route 365 A Source Active A-D route type specific MCAST-VPN NLRI consists of 366 the following: 368 +-----------------------------------+ 369 | RD (8 octets) | 370 +-----------------------------------+ 371 | Multicast Source Length (1 octet) | 372 +-----------------------------------+ 373 | Multicast Source (Variable) | 374 +-----------------------------------+ 375 | Multicast Group Length (1 octet) | 376 +-----------------------------------+ 377 | Multicast Group (Variable) | 378 +-----------------------------------+ 380 The RD is encoded as described in [RFC4364]. 382 The Multicast Source field contains the C-S address. If the Multicast 383 Source field contains an IPv4 address, then the value of the 384 Multicast Source Length field is 32. If the Multicast Source field 385 contains an IPv6 address, then the value of the Multicast Source 386 Length field is 128. 388 Use of the Source Active A-D routes with the Multicast Source Length 389 field of 0 is outside the scope of this document. 391 The Group Address field contains the C-G address. If the Multicast 392 Group field contains an IPv4 address, then the value of the Multicast 393 Group Length field is 32. If the Multicast Group field contains an 394 IPv6 address, then the value of the Multicast Group Length field is 395 128. 397 Source Active A-D routes with a Multicast group belonging to the 398 Source Specific Multicast (SSM) range (as defined in [RFC4607], and 399 potentially extended locally on a router) MUST NOT be advertised by a 400 router and MUST be discarded if received. 402 Usage of Source Active A-D routes is described in Sections "Switching 403 from Shared C-tree to Source C-tree", and "Supporting PIM-SM without 404 Inter-Site Shared C-trees". 406 4.6. C-multicast route 408 A Shared Tree Join route and a Source Tree Join route type specific 409 MCAST-VPN NLRI consists of the following: 411 +-----------------------------------+ 412 | RD (8 octets) | 413 +-----------------------------------+ 414 | Source AS (4 octets) | 415 +-----------------------------------+ 416 | Multicast Source Length (1 octet) | 417 +-----------------------------------+ 418 | Multicast Source (Variable) | 419 +-----------------------------------+ 420 | Multicast Group Length (1 octet) | 421 +-----------------------------------+ 422 | Multicast Group (Variable) | 423 +-----------------------------------+ 425 The RD is encoded as described in [RFC4364]. 427 The Source AS contains an Autonomous System number. Two octets AS 428 numbers are encoded in the low order two octets of the Source AS 429 field. 431 For a Shared Tree Join route the Multicast Source field contains the 432 C-RP address; for a Source Tree Join route the Multicast Source field 433 contains the C-S address. If the Multicast Source field contains an 434 IPv4 address, then the value of the Multicast Source Length field is 435 32. If the Multicast Source field contains an IPv6 address, then the 436 value of the Multicast Source Length field is 128. 438 The Group Address field contains the C-G address or C-MP Opaque Value 439 Element. If the Multicast Group field contains an IPv4 address, then 440 the value of the Multicast Group Length field is 32. If the 441 Multicast Group field contains an IPv6 address, then the value of the 442 Multicast Group Length field is 128. 444 Usage of C-multicast routes is described in Section "Exchange of C- 445 Multicast Routing Information among PEs". 447 5. PMSI Tunnel attribute 449 This document defines and uses a new BGP attribute, called P- 450 Multicast Service Interface Tunnel (PMSI Tunnel) attribute. This is 451 an optional transitive BGP attribute. The format of this attribute is 452 defined as follows: 454 +---------------------------------+ 455 | Flags (1 octet) | 456 +---------------------------------+ 457 | Tunnel Type (1 octets) | 458 +---------------------------------+ 459 | MPLS Label (3 octets) | 460 +---------------------------------+ 461 | Tunnel Identifier (variable) | 462 +---------------------------------+ 464 The Flags field has the following format: 466 0 1 2 3 4 5 6 7 467 +-+-+-+-+-+-+-+-+ 468 | reserved |L| 469 +-+-+-+-+-+-+-+-+ 471 This document defines the following flags: 473 + Leaf Information Required (L) 475 The Tunnel Type identifies the type of the tunneling technology used 476 to establish the PMSI tunnel. The type determines the syntax and 477 semantics of the Tunnel Identifier field. This document defines the 478 following Tunnel Types: 480 + 0 - No tunnel information present 481 + 1 - RSVP-TE P2MP LSP 482 + 2 - mLDP P2MP LSP 483 + 3 - PIM-SSM Tree 484 + 4 - PIM-SM Tree 485 + 5 - PIM-Bidir Tree 486 + 6 - Ingress Replication 487 + 7 - mLDP MP2MP LSP 489 If the MPLS Label field is non-zero, then it contains an MPLS label 490 encoded as 3 octets, where the high-order 20 bits contain the label 491 value. Absence of MPLS Label is indicated by setting the MPLS Label 492 field to zero. 494 When the type is set to "No tunnel information present", the PMSI 495 Tunnel attribute carries no tunnel information (no Tunnel 496 Identifier). This type is to be used only in the following case: to 497 enable explicit tracking for a particular customer multicast flow (by 498 setting the Leaf Information Required flag to 1), but without binding 499 this flow to a particular provider tunnel (by omitting any tunnel 500 information). 502 When the type is set to RSVP-TE P2MP LSP, the Tunnel Identifier is 503 as carried in the 504 RSVP-TE P2MP LSP SESSION Object [RFC4875]. 506 When the type is set to mLDP P2MP LSP, the Tunnel Identifier is a 507 P2MP FEC Element [mLDP]. 509 When the type is set to PIM-SM Tree, the Tunnel Identifier is . The node that originated the attribute 511 MUST use the address carried in the Sender Address as the source IP 512 address for the IP/GRE encapsulation of the MVPN data. 514 When the type is set to PIM-SSM Tree, the Tunnel Identifier is . The node that originates the 516 attribute MUST use the address carried in the P-Root Node Address as 517 the source IP address for the IP/GRE encapsulation of the MVPN data. 518 The P-Multicast Group element of the Tunnel identifier of the Tunnel 519 attribute MUST NOT be expected to be the same group for all Intra-AS 520 A-D routes for the same MVPN. According to [RFC4607], the group 521 address can be locally allocated by the originating PE without any 522 consideration for the group address used by other PE on the same 523 MVPN. 525 When the type is set to PIM-Bidir Tree, the Tunnel Identifier is 526 . The node that originated the 527 attribute MUST use the address carried in the Sender Address as the 528 source IP address for the IP/GRE encapsulation of the MVPN data. 530 When the type is set to PIM-SM or PIM-Bidir tree, then the P- 531 Multicast group element of the Tunnel identifier of the Tunnel 532 attribute SHOULD be the same multicast group address for all Intra-AS 533 I-PMSI A-D routes for the same MVPN originated by PEs within a given 534 AS. How this multicast group address is chosen is outside the scope 535 of this specification. 537 When the type is set to Ingress Replication the Tunnel Identifier 538 carries the unicast tunnel endpoint IP address of the local PE that 539 is to be this PE's receiving endpoint address for the tunnel. 541 When the type is set to mLDP MP2MP LSP, the Tunnel Identifier is an 542 MP2MP FEC Element [mLDP]. 544 The use of mLDP MP2MP LSPs as Provider tunnels (P-tunnels) requires 545 procedures which are outside the scope of this document. 547 A router that supports the PMSI Tunnel attribute considers this 548 attribute to be malformed if it either (a) contains an undefined 549 Tunnel Type, or (b) the router can not parse the Tunnel Identifier 550 field of the attribute as a tunnel identifier of the tunnel types 551 specifed in the Tunnel Type field of the attribute. 553 When a router that receives a BGP Update that contains the PMSI 554 Tunnel attribute with its Partial bit set determines that the 555 attribute is malformed, the router SHOULD treat this Update as though 556 all the routes contained in this Update had been withdrawn. 558 An implementation MUST provide debugging facilities to permit issues 559 caused by malformed PMSI Tunnel attribute to be diagnosed. At a 560 minimum, such facilities MUST include logging an error when such an 561 attribute is detected. 563 The PMSI Tunnel attribute is used in conjunction with Intra-AS I-PMSI 564 A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf 565 A-D routes. 567 6. Source AS Extended Community 569 This document defines a new BGP extended community called Source AS. 571 The Source AS is an AS specific extended community, of an extended 572 type, and is transitive across AS boundaries [RFC4360]. 574 The Global Administrator field of this community MUST be set to the 575 autonomous system number of the PE. The Local Administrator field of 576 this community MUST be set to 0. 578 If for a given MVPN BGP is used for exchanging C-multicast routes, or 579 if segmented inter-AS tunnels are used, then when a PE that has sites 580 of that MVPN connected to it originates a (unicast) route to VPN-IP 581 addresses, the PE MUST include in the BGP Update message that carries 582 this route the Source AS extended community. 584 The usage of a received Source AS extended community is described in 585 Section "Constructing the rest of the C-multicast route". 587 7. VRF Route Import Extended Community 589 This document defines a new BGP extended community called VRF Route 590 Import. 592 The VRF Route Import is an IP address specific extended community, of 593 an extended type, and is transitive across AS boundaries [RFC4360]. 595 To support MVPN in addition to the import/export Route Target(s) 596 extended communities used by the unicast routing, each VRF on a PE 597 MUST have an import Route Target extended community, except if it is 598 known a priori that none of the (local) MVPN sites associated with 599 the VRF contain multicast source(s) and/or C-RP, in which case the 600 VRF need not have this import Route Target. 602 We refer to this Route Target as the "C-multicast Import RT", as this 603 Route Target controls imports of C-multicast routes into a particular 604 VRF. 606 A PE constructs C-multicast Import RT as follows: 608 + The Global Administrator field of the C-multicast Import RT MUST 609 be set to an IP address of the PE. This address SHOULD be common 610 for all the VRFs on the PE (e.,g., this address may be PE's 611 loopback address). 613 + The Local Administrator field of the C-multicast Import RT 614 associated with a given VRF contains a 2 octets long number that 615 uniquely identifies that VRF within the PE that contains the VRF 616 (procedures for assigning such numbers are purely local to the 617 PE, and outside the scope of this document). 619 The way C-multicast Import RT is constructed, it uniquely identifies 620 a VRF. 622 A PE that has site(s) of a given MVPN connected to it needs to 623 communicate the value of the C-multicast Import RT associated with 624 the VRF of that MVPN on the PE to all other PEs that have sites of 625 that MVPN. To accomplish this a PE that originates a (unicast) route 626 to VPN-IP addresses MUST include in the BGP Updates message that 627 carries this route the VRF Route Import extended community that has 628 the value of the C-multicast Import RT of the VRF associated with the 629 route, except if it is known a priori (e.g., via provisioning) that 630 none of these addresses could act as multicast sources and/or RP, in 631 which case the (unicast) route MUST NOT carry the VRF Route Import 632 extended community. 634 If a PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD 635 advertise all such C-multicast Import RTs using Route Target 636 Constrains (note that doing this requires just a single Route Target 637 Constraint advertisement by the PE). This allows each C-multicast 638 route to reach only the relevant PE. To constrain distribution of the 639 Route Target Constrain routes to the AS of the advertising PE these 640 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 642 Usage of VRF Route Import extended community is described in Section 643 "Constructing the rest of the C-multicast route". 645 8. PE Distinguisher Labels Attribute 647 This document defines a new BGP attribute, called PE Distinguisher 648 Labels attribute. This is an optional transitive BGP attribute. The 649 format of this attribute is defined as follows: 651 +---------------------------------+ 652 | PE Address | 653 +---------------------------------+ 654 | Label (3 octets) | 655 +---------------------------------+ 656 ....... 657 +---------------------------------+ 658 | PE Address | 659 +---------------------------------+ 660 | Label (3 octets) | 661 +---------------------------------+ 663 The Label field contains an MPLS label encoded as 3 octets, where the 664 high-order 20 bits contain the label value. 666 A router that supports the PE Distinguisher Labels attribute 667 considers this attribute to be malformed if the PE Address field does 668 not contain a unicast address. The attribute is also considered to be 669 malformed if the PE Address field is expected to be an IPv4 address, 670 and the length of the attribute minus 4 is not a multiple of 3, or 671 the PE Address field is expected to be an IPv6 address, and the 672 length of the attribute minus 16 is not a multiple of 3. (The length 673 of the Route Type field of MCAST-VPN NLRI of the route that carries 674 the PE Distinguisher Labels attribute provides the information on 675 whether the PE Address field contains an IPv4 or IPv6 address.) 677 When a router that receives a BGP Update that contains the PE 678 Distinguisher Labels attribute with its Partial bit set determines 679 that the attribute is malformed, the router SHOULD treat this Update 680 as though all the routes contained in this Update had been withdrawn. 682 An implementation MUST provide debugging facilities to permit issues 683 caused by malformed PE Distinguisher Label attribute to be diagnosed. 684 At a minimum, such facilities MUST include logging an error when such 685 an attribute is detected. 687 Usage of this attribute is described in [MVPN]. 689 9. MVPN Auto-Discovery/Binding 691 This section specifies procedures for the auto-discovery of MVPN 692 memberships and the distribution of information used to instantiate 693 I-PMSIs. 695 There are two MVPN auto-discovery/binding mechanisms, dubbed "intra- 696 AS" and "inter-AS" respectively. 698 The intra-AS mechanisms provide auto-discovery/binding within a 699 single AS. 701 The intra-AS mechanisms also provide auto-discovery/binding across 702 multiple ASes when non-segmented inter-AS tunnels are being used. 704 The inter-AS mechanisms provide auto-discovery/binding across 705 multiple ASes when segmented inter-AS tunnels are being used. 707 Note that if a multi-AS system uses option (a) of section 10 of 708 [RFC4364], the notion of inter-AS tunnels does not apply, and so it 709 needs only the intra-AS mechanisms. 711 9.1. MVPN Auto-Discovery/Binding - Intra-AS Operations 713 This section describes exchanges of Intra-AS I-PMSI A-D routes 714 originated/received by PEs within the same AS, or if non-segmented 715 inter-AS tunnels are used, then by all PEs. 717 9.1.1. Originating Intra-AS I-PMSI A-D routes 719 To participate in the MVPN auto-discovery/binding a PE router that 720 has a given VRF of a given MVPN MUST, except for the cases specified 721 further down in this section, originate an Intra-AS I-PMSI A-D route 722 and advertises this route in IBGP. The route is constructed as 723 follows. 725 The route carries a single MCAST-VPN NLRI with the RD set to the RD 726 of the VRF, and the Originating Router's IP Address field set to the 727 IP address that the PE places in the Global Administrator field of 728 the VRF Route Import extended community of the VPN-IP routes 729 advertised by the PE. Note that the tuple uniquely identifies a given multicast VRF. 732 The route carries the PMSI Tunnel attribute if and only if an I-PMSI 733 is used for the MVPN (the conditions under which an I-PMSI is used 734 can be found in [MVPN]). Depending on the technology used for the P- 735 tunnel for the MVPN on the PE, the PMSI Tunnel attribute of the 736 Intra-AS I-PMSI A-D route is constructed as follows. 738 + If the PE that originates the advertisement uses a P-Multicast 739 tree for the P-tunnel for the MVPN, the PMSI Tunnel attribute 740 MUST contain the identity of the tree (note that the PE could 741 create the identity of the tree prior to the actual instantiation 742 of the tree). 744 + A PE that uses a P-Multicast tree for the P-tunnel MAY aggregate 745 two or more MVPNs present on the PE onto the same tree. In this 746 case in addition to carrying the identity of the tree, the PMSI 747 Tunnel attribute MUST carry an MPLS upstream assigned label which 748 the PE has bound uniquely to the MVPN associated with this update 749 (as determined by its RTs). 751 If the PE has already advertised Intra-AS I-PMSI A-D routes for 752 two or more MVPNs that it now desires to aggregate, then the PE 753 MUST re-advertise those routes. The re-advertised routes MUST be 754 the same as the original ones, except for the PMSI Tunnel 755 attribute and the label carried in that attribute. 757 + If the PE that originates the advertisement uses ingress 758 replication for the P-tunnel for the MVPN, the route MUST include 759 the PMSI Tunnel attribute with the Tunnel Type set to Ingress 760 Replication and Tunnel Identifier set to a routable address of 761 the PE. The PMSI Tunnel attribute MUST carry a downstream 762 assigned MPLS label. This label is used to demultiplex the MVPN 763 traffic received over a unicast tunnel by the PE. 765 + The Leaf Information Required flag of the PMSI Tunnel attribute 766 MUST be set to zero, and MUST be ignored on receipt. 768 Discovery of PE capabilities in terms of what tunnels types they 769 support is outside the scope of this document. Within a given AS PEs 770 participating in an MVPN are expected to advertise tunnel bindings 771 whose tunnel types are supported by all other PEs that are 772 participating in this MVPN and are part of the same AS. In addition, 773 in the inter-AS scenario with non-segmented inter-AS tunnels, the 774 tunnel types have to be supported by all PEs that are participating 775 in this MVPN, irrespective of whether these PEs are in the same AS or 776 not. 778 The Next Hop field of the MP_REACH_NLRI attribute of the route MUST 779 be set to the same IP address as the one carried in the Originating 780 Router's IP Address field. 782 By default the distribution of the Intra-AS I-PMSI A-D routes is 783 controlled by the same Route Targets as the ones used for the 784 distribution of VPN-IP unicast routes. That is, by default the Intra- 785 AS I-PMSI A-D route MUST carry the export Route Target used by the 786 unicast routing. If any other PE has one of these Route Targets 787 configured as an import Route Target for a VRF present on the PE, it 788 treats the advertising PE as a member in the MVPN to which the VRF 789 belongs. The default could be modified via configuration by having a 790 set of Route Targets used for the Intra-AS I-PMSI A-D routes being 791 distinct from the ones used for the VPN-IP unicast routes (see also 792 Section "Non-congruent Unicast and Multicast Connectivity"). 794 To constrain distribution of the intra-AS membership/binding 795 information to the AS of the advertising PE the BGP Update message 796 originated by the advertising PE SHOULD carry the NO_EXPORT Community 797 ([RFC1997]). 799 Note that if non-segmented inter-AS P-tunnels are being used, then 800 the Intra-AS I-PMSI routes need to be distributed to other ASes and 801 MUST NOT carry the NO_EXPORT community. 803 When BGP is used to exchange C-multicast routes, if (a) it is known a 804 priori that as a matter of policy none of the MVPN sites connected to 805 a given PE are allowed to send multicast traffic to other sites of 806 that MVPN (in other words, all these sites are only in the Receiver 807 Sites set), (b) the PE does not use ingress replication for the 808 incoming traffic of that MVPN, and (c) none of the other PEs that 809 have VRFs of that MVPN use RSVP-TE P2MP LSP for that MVPN, then the 810 local PE SHOULD NOT originate an Intra-AS I-PMSI A-D route. 812 When BGP is used to exchange C-multicast routes, if it is known a 813 priori that as a matter of policy none of the MVPN sites connected to 814 a given PE can receive multicast traffic from other sites of that 815 MVPN (in other words, all these sites are only in the Sender Sites 816 set), and the PE uses ingress replication for that MVPN, then the PE 817 SHOULD NOT originate an Intra-AS I-PMSI A-D route for that MVPN. 819 9.1.2. Receiving Intra-AS I-PMSI A-D routes 821 When a PE receives a BGP Update message that carries an Intra-AS I- 822 PMSI A-D route such that (a) at least one of the Route Targets of the 823 route matches one of the import Route Targets configured for a 824 particular VRF on the local PE, (b) either the route was originated 825 by some other PE within the same AS as the local PE, or the MVPN 826 associated with the VRF uses non-segmented inter-AS tunnels, and (c) 827 the BGP route selection determines that this is the best route with 828 respect to the NLRI carried by the route, the PE performs the 829 following. 831 If the route does not carry the PMSI Tunnel Attribute and ingress 832 replication is not used, either a) the PE that originated the route 833 will be using only S-PMSIs to send traffic to remote PEs, or b) as a 834 matter of policy, the PE that originated the route, cannot send 835 multicast traffic from the MVPN sites connected to it to other sites 836 of that MVPN (in other words, the sites connected to the PE are only 837 in the Receiver Sites set). 839 When BGP is used to exchange C-multicast routes, to distinguish 840 between cases (a) and (b) we use the presence/absence of the VRF 841 Route Import extended community in the unicast VPN routes, as 842 follows. As specified in section "VRF Route Import Extended 843 Community", if it is know a priori that none of the addresses carried 844 in the NLRI of a given (unicast) VPN route could act as multicast 845 sources and/or C-RP, then such a route does not carry the VRF Route 846 Import extended community. Hence based on the UMH selection algorithm 847 specified in [MVPN], such a route will be ineligible for the UMH 848 selection. This implies that if a given VPN route is selected by the 849 UMH selection procedures, and the PE that originates this VPN route 850 also originates an Intra-AS I-PMSI A-D route, but this route does not 851 carry the PMSI Tunnel attribute, then this PE will be using only S- 852 PMSIs for sending (multicast) data. 854 If the route carries the PMSI Tunnel attribute then: 856 + If the Tunnel Type in the PMSI Tunnel attribute is set to Ingress 857 Replication, then the MPLS label and the address carried in the 858 Tunnel Identifier field of the PMSI Tunnel attribute should be 859 used when the local PE sends multicast traffic to the PE that 860 originated the route. 862 + If the Tunnel Type in the PMSI Tunnel attribute is set to mLDP 863 P2MP LSP, or mLDP MP2MP LSP, or PIM-SSM tree, or PIM-SM tree, or 864 PIM-Bidir tree, the PE SHOULD join as soon as possible the P- 865 Multicast tree whose identity is carried in the Tunnel 866 Identifier. 868 + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE 869 P2MP LSP, then the PE that originated the route MUST establish an 870 RSVP-TE P2MP LSP with the local PE as a leaf. This LSP may have 871 been established before the local PE receives the route, or may 872 be established after the local PE receives the route. 874 + The receiving PE has to establish the appropriate state to 875 properly handle the traffic received on the P-Multicast tree. 877 + If the PMSI Tunnel attribute does not carry a label, then all 878 packets that are received on the P-Multicast tree, as identified 879 by the PMSI Tunnel attribute, are forwarded using the VRFs that 880 has at least one of its import Route Targets that matches one of 881 the Route Targets of the received Intra-AS I-PMSI A-D route. 883 + If the PMSI Tunnel attribute has the Tunnel Type set to mLDP P2MP 884 LSP, or PIM-SSM tree, or PIM-SM tree, or PIM-Bidir tree, or RSVP- 885 TE P2MP LSP, and the attribute also carries an MPLS label, then 886 this is an upstream assigned label, and all packets that are 887 received on the P-Multicast tree, as identified by the PMSI 888 Tunnel attribute, with that upstream assigned label are forwarded 889 using the VRFs that has at least one of its import Route Target 890 that matches one of the Route Targets of the received Intra-AS I- 891 PMSI A-D route. 893 Irrespective of whether the route carries the PMSI Tunnel attribute, 894 if the local PE uses RSVP-TE P2MP LSP for sending (multicast) traffic 895 from the VRF to the sites attached to other PEs, then the local PE 896 uses the Originating Router's IP address information carried in the 897 route to add the PE that originated the route as a leaf node to the 898 LSP. 900 9.2. MVPN Auto-Discovery/Binding - Inter-AS Operations 902 This section applies only to the case where segmented inter-AS 903 tunnels are used. 905 An Autonomous System Border Router (ASBR) may be configured to 906 support a particular MVPN as follows: 908 + An ASBR MUST be be configured with a set of (import) Route 909 Targets (RTs) that specifies the set of MVPNs supported by the 910 ASBR. These Route Targets control acceptance of Intra-AS/Inter-AS 911 I-PMSI A-D routes by the ASBR. As long as unicast and multicast 912 connectivity are congruent, this could be the same set of Route 913 Targets as the one used for supporting unicast (and therefore 914 would not require any additional configuration above and beyond 915 of what is required for unicast). Note that instead of being 916 configured, the ASBR MAY obtain this set of (import) Route 917 Targets (RTs) by using Route Target Constrain [RT-CONSTRAIN]. 919 + The ASBR MUST be (auto-)configured with an import Route Target 920 called "ASBR Import RT". ASBR Import RT controls acceptance of 921 Leaf A-D routes and C-multicast routes by the ASBR, and is used 922 to constrain distribution of both Leaf A-D routes and C-multicast 923 routes (see Section "Exchange of C-Multicast Routing Information 924 among PEs"). 926 ASBR Import RT is an IP address specific Route Target. The Global 927 Administrator field of the ASBR Import RT MUST be set to the IP 928 address carried in the Next Hop of all the Inter-AS I-PMSI A-D 929 routes and S-PMSI A-D routes advertised by this ASBR (if the ASBR 930 uses different Next Hops, then the ASBR MUST be (auto-)configured 931 with multiple ASBR Import RTs, one per each such Next Hop). The 932 Local Administrator field of the ASBR Import RT MUST be set to 0. 934 If the ASBR supports Route Target Constrain [RT-CONSTRAIN], the 935 ASBR SHOULD advertise its ASBR Import RT within its own AS using 936 Route Target Constrains. To constrain distribution of the Route 937 Target Constrain routes to the AS of the advertising ASBR these 938 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 940 + The ASBR MUST be configured with the tunnel types for the intra- 941 AS segments of the MVPNs supported by the ASBR, as well as 942 (depending on the tunnel type) the information needed to create 943 the PMSI attribute for these tunnel types. Note that instead of 944 being configured, the ASBR MAY derive the tunnel types from the 945 Intra-AS I-PMSI A-D routes received by the ASBR. 947 + If the ASBR originates an Inter-AS I-PMSI A-D route for a 948 particular MVPN present on some of the PEs within its own AS, the 949 ASBR MUST be (auto-)configured with an RD for that MVPN. It is 950 RECOMMENDED that one of the following two options be used: 952 (1) To allow more aggregation of Inter-AS I-PMSI A-D routes it is 953 recommended that all the ASBRs within an AS that are configured 954 to originate an Inter-AS I-PMSI A-D route for a particular MVPN 955 be configured with the same RD (although for a given MVPN each AS 956 may assign this RD on its own, without coordination with other 957 ASes). 959 (2) To allow more control over spreading MVPN traffic among 960 multiple ASBRs within a given AS it is recommended for each ASBR 961 to have a distinct RD per each MVPN, in which case such an RD 962 SHOULD be auto-configured. 964 If an ASBR is configured to support a particular MVPN, the ASBR MUST 965 participate in the intra-AS MVPN auto-discovery/binding procedures 966 for that MVPN within the ASBR's own AS, as specified in Section "MVPN 967 Auto-Discovery/Binding - Intra-AS Operations". 969 Moreover, in addition to the above the ASBR performs procedures 970 described in Sections "Originating Inter-AS I-PMSI A-D routes", "When 971 not to originate Inter-AS I-PMSI A-D routes", and "Propagating Inter- 972 AS I-PMSI A-D routes". 974 9.2.1. Originating Inter-AS I-PMSI A-D routes 976 For a given MVPN configured on an ASBR when the ASBR determines 977 (using the intra-AS auto-discovery procedures) that at least one of 978 the PEs of its own AS has (directly) connected site(s) of the MVPN, 979 the ASBR originates an Inter-AS I-PMSI A-D route and advertises it in 980 EBGP. The route is constructed as follows: 982 + The route carries a single MCAST-VPN NLRI with the RD set to the 983 RD configured for that MVPN on the ASBR, and the Source AS set to 984 the Autonomous System number of the ASBR. 986 + The route carries the PMSI Tunnel attribute if and only if an I- 987 PMSI is used for the MVPN. The Tunnel Type in the attribute is 988 set to Ingress Replication; the Leaf Information Required flag is 989 set to 1; the the attribute carries no MPLS labels. 991 + The Next Hop field of the MP_REACH_NLRI attribute is set to a 992 routable IP address of the ASBR. 994 + The default policy for aggregation of Intra-AS I-PMSI A-D routes 995 into an Inter-AS I-PMSI A-D route is that a given Inter-AS I-PMSI 996 A-D route aggregates only the Intra-AS I-PMSI A-D routes that 997 carry exactly the same set of RTs (note that this set may have 998 just one RT). In this case an Inter-AS I-PMSI A-D route 999 originated by an ASBR carries exactly the same RT(s) as the RT(s) 1000 carried by the Intra-AS I-PMSI A-D routes that the ASBR 1001 aggregates into that Inter-AS I-PMSI A-D route. An implementation 1002 MUST support the default policy for aggregation of Intra-AS I- 1003 PMSI A-D routes into an Inter-AS I-PMSI A-D route. 1005 + The default policy for aggregation could be modified via 1006 configuration on the ASBR. An implementation MAY support such 1007 functionality. Modified policy MUST include rules for 1008 constructing RTs carried by the Inter-AS I-PMSI A-D routes 1009 originated by the ASBR. 1011 An Inter-AS I-PMSI A-D route for a given indicates 1012 presence of the MVPN sites connected to one or more PEs of the AS. 1014 An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra- 1015 AS I-PMSI A-D routes originated within the ASBR's own AS. Thus while 1016 the Intra-AS I-PMSI A-D routes originated within an AS are at the 1017 granularity of within that AS, outside of that AS the 1018 (aggregated) Inter-AS I-PMSI A-D routes could be at the granularity 1019 of . 1021 9.2.2. When not to originate Inter-AS I-PMSI A-D routes 1023 If for a given MVPN and a given AS all of its sites connected to the 1024 PEs within the AS known a priori to have no multicast sources, then 1025 ASBRs of that AS MAY refrain from originating an Inter-AS I-PMSI A-D 1026 route for that MVPN at all. 1028 9.2.3. Propagating Inter-AS I-PMSI A-D routes 1030 An Inter-AS I-PMSI A-D route for a given MVPN originated by an ASBR 1031 within a given AS is propagated via BGP to other ASes. 1033 9.2.3.1. Propagating Inter-AS I-PMSI A-D routes - Overview 1035 Suppose that an ASBR A installs an Inter-AS I-PMSI A-D route for MVPN 1036 V that originated at a particular AS, AS1. The BGP next hop of that 1037 route becomes A's "upstream multicast hop" on a multicast 1038 distribution tree for V that is rooted at AS1. When the Inter-AS I- 1039 PMSI A-D routes have been distributed to all the necessary ASes, they 1040 define a "reverse path" from any AS that supports MVPN V back to AS1. 1041 For instance, if AS2 supports MVPN V, then there will be a reverse 1042 path for MVPN V from AS2 to AS1. This path is a sequence of ASBRs, 1043 the first of which is in AS2, and the last of which is in AS1. Each 1044 ASBR in the sequence is the BGP next hop of the previous ASBR in the 1045 sequence on the given Inter-AS I-PMSI A-D route. 1047 This reverse path information can be used to construct a 1048 unidirectional multicast distribution tree for MVPN V, containing all 1049 the ASes that support V, and having AS1 at the root. We call such a 1050 tree an "inter-AS tree". Multicast data originating in MVPN sites 1051 connected to PEs within a given AS will travel downstream along the 1052 tree which is rooted at that AS. 1054 The path along an inter-AS tree is a sequence of ASBRs; it is still 1055 necessary to specify how the multicast data gets from a given ASBR to 1056 the set of ASBRs which are immediately downstream of the given ASBR 1057 along the tree. This is done by creating "segments": ASBRs in 1058 adjacent ASes will be connected by inter-AS segments, ASBRs in the 1059 same AS will be connected by "intra-AS segments". 1061 An ASBR initiates creation of an intra-AS segment when the ASBR 1062 receives an Inter-AS I-PMSI A-D route from an EBGP neighbor. 1063 Creation of the segment is completed as a result of distributing via 1064 IBGP this route within the ASBR's own AS. 1066 For a given inter-AS tunnel each of its intra-AS segments could be 1067 constructed by its own independent mechanism. Moreover, by using 1068 upstream assigned labels within a given AS multiple intra-AS segments 1069 of different inter-AS tunnels of either the same or different MVPNs 1070 may share the same P-Multicast tree. 1072 If the P-Multicast tree that serves as a particular intra-AS segment 1073 of an inter-AS tunnel is created by a multicast control protocol that 1074 uses receiver-initiated joins (e.g, mLDP, any PIM variant), and this 1075 P-Multicast tree does not aggregate multiple segments, then all the 1076 information needed to create that segment is present in the PMSI 1077 Tunnel attribute of the Inter-AS I-PMSI A-D routes. But if the P- 1078 Multicast tree that serves as the segment is created by a protocol 1079 that does not use receiver-initiated joins (e.g., RSVP-TE, ingress 1080 unicast replication), or if this P-Multicast tree aggregates multiple 1081 segments (irrespective of the multicast control protocol used to 1082 create the tree), then it is also necessary to use Leaf A-D routes. 1083 The precise conditions under which Leaf A-D routes need to be used 1084 are described in subsequent sections. 1086 Since (aggregated) Inter-AS I-PMSI A-D routes could have granularity 1087 of , an MVPN that is present in N ASes could have total of 1088 N inter-AS tunnels. Thus for a given MVPN the number of inter-AS 1089 tunnels constituting the I-PMSIs is independent of the number of PEs 1090 that have this MVPN. 1092 The precise rules for distributing and processing the Inter-AS I-PMSI 1093 A-D routes across ASes are given in the following sections. 1095 9.2.3.2. Inter-AS I-PMSI A-D route received via EBGP 1097 When an ASBR receives from one of its EBGP neighbors a BGP Update 1098 message that carries an Inter-AS I-PMSI A-D route, if (a) at least 1099 one of the Route Targets carried in the message matches one of the 1100 import Route Targets configured on the ASBR, and (b) the ASBR 1101 determines that the received route is the best route for its NLRI, 1102 the ASBR re-advertises this route to other PEs and ASBRs within its 1103 own AS (handling of this route by other PEs and ASBRs is described in 1104 Section "Inter-AS I-PMSI A-D route received via IBGP"). 1106 When re-advertising an Inter-AS I-PMSI A-D route the ASBR MUST set 1107 the Next Hop field of the MP_REACH_NLRI attribute to a routable IP 1108 address of the ASBR. 1110 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1111 attribute, then depending on the technology used to instantiate the 1112 intra-AS segment of the inter-AS tunnel the ASBR constructs the PMSI 1113 Tunnel attribute of the re-advertised Inter-AS I-PMSI A-D route as 1114 follows. 1116 + If the ASBR uses ingress replication for the intra-AS segment of 1117 the inter-AS tunnel, the re-advertised route MUST carry the PMSI 1118 Tunnel attribute with the Tunnel Type set to Ingress Replication, 1119 but no MPLS labels. 1121 + If the ASBR uses a P-Multicast tree for the intra-AS segment of 1122 the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the 1123 identity of the tree (note that the ASBR could create the 1124 identity of the tree prior to the actual instantiation of the 1125 tree). If in order to instantiate the tree the ASBR needs to know 1126 the leaves of the tree, then the ASBR obtains this information 1127 from the Leaf A-D routes received from other PEs/ASBRs in ASBR's 1128 own AS (as described in Section "Leaf A-D route received via 1129 IBGP") by setting the Leaf Information Required flag in the PMSI 1130 Tunnel attribute to 1. 1132 + An ASBR that uses a P-Multicast tree as the intra-AS segment of 1133 the inter-AS tunnel MAY aggregate two or more MVPNs present on 1134 the ASBR onto the same tree. In this case in addition to the 1135 identity of the tree, the PMSI Tunnel attribute MUST carry an 1136 MPLS upstream-assigned label which the PE has bound uniquely to 1137 the MVPN associated with this update (as determined by its RTs). 1139 If the ASBR has already advertised Inter-AS I-PMSI A-D routes for 1140 two or more MVPNs that it now desires to aggregate, then the ASBR 1141 MUST re-advertise those routes. The re-advertised routes MUST be 1142 the same as the original ones, except for the PMSI Tunnel 1143 attribute and the MVPN label. 1145 9.2.3.2.1. Originating Leaf A-D route into EBGP 1147 In addition the ASBR MUST send to the EBGP neighbor from whom it 1148 received the Inter-AS I-PMSI A-D route, a BGP Update message that 1149 carries a Leaf A-D route constructed as follows. 1151 + The route carries a single MCAST-VPN NLRI with the Route Key 1152 field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route 1153 received from that neighbor and the Originating Router's IP 1154 address set to the IP address of the ASBR (this MUST be a 1155 routable IP address). 1157 + The Leaf A-D route MUST include the PMSI Tunnel attribute with 1158 the Tunnel Type set to Ingress Replication, and the Tunnel 1159 Identifier set to a routable address of the advertising router. 1160 The PMSI Tunnel attribute MUST carry a downstream assigned MPLS 1161 label that is used by the advertising router to demultiplex the 1162 MVPN traffic received over a unicast tunnel from the EBGP 1163 neighbor. 1165 + The ASBR constructs an IP-based Route Target extended community 1166 by placing the IP address carried in the next hop of the received 1167 Inter-AS I-PMSI A-D route in the Global Administrator field of 1168 the community, with the Local Administrator field of this 1169 community set to 0, and sets the Extended Communities attribute 1170 of the Leaf A-D route to that community. Note that this Route 1171 Target is the same as the ASBR Import RT of the EBGP neighbor 1172 from which the ASBR received the Inter-AS I-PMSI A-D route. 1174 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1175 MUST be set to the same IP address as the one carried in the 1176 Originating Router's IP Address field of the route. 1178 + To constrain the distribution scope of this route the route MUST 1179 carry the NO_ADVERTISE BGP community ([RFC1997]). 1181 Handling of this Leaf A-D route by the EBGP neighbor is described in 1182 Section "Leaf A-D route received via EBGP". 1184 The ASBR MUST set up its forwarding state such that packets that 1185 arrive on the one-hop ASBR-ASBR LSP, as specified in the PMSI Tunnel 1186 Attribute of the Leaf A-D route, are transmitted on the intra-AS 1187 segment, as specified in the PMSI Tunnel Attribute of the inter-AS I- 1188 PMSI A-D route that the ASBR re-advertises in its own AS. However, 1189 the packets MAY be filtered before forwarding, as specified in 1190 Section "Optimizing Bandwidth by IP filtering on ASBRs". 1192 9.2.3.3. Leaf A-D route received via EBGP 1194 When an ASBR receives via EBGP a Leaf A-D route originated by its 1195 neighbor ASBR, if the Route Target carried in the Extended 1196 Communities attribute of the route matches one of the ASBR Import RT 1197 (auto)configured on the ASBR, the ASBR performs the following. 1199 The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has 1200 the same value as the Route Key field of the the Leaf A-D route. 1202 If the found Inter-AS I-PMSI A-D route was originated by ASBR itself, 1203 then the ASBR sets up its forwarding state such that packets received 1204 on the intra-AS tunnels originating in the ASBR's own AS are 1205 transmitted on the one hop ASBR-ASBR LSP specified by the MPLS label 1206 carried in the PMSI Tunnel attribute of the received Leaf A-D route. 1207 (However the packets MAY be filtered before transmission as specified 1208 in Section "Optimizing Bandwidth by IP filtering on ASBRs"). The 1209 intra-AS tunnels are specified in the PMSI Tunnel attribute of all 1210 the Intra-AS I-PMSI A-D routes received by the ASBR that the ASBR 1211 aggregated into the Inter-AS I-PMSI A-D route. For each of these 1212 intra-AS tunnels, if a non-zero MPLS label is carried in the PMSI 1213 Tunnel attribute (i.e aggregation is used) then only packets received 1214 on the inner LSP corresponding to that label MUST be forwarded, not 1215 the packets received on the outer LSP, as the outer LSP possibly 1216 carries the traffic of other VPNs. 1218 If the found Inter-AS I-PMSI A-D route was originated by some other 1219 ASBR, then the ASBR sets up its forwarding state such that packets 1220 received on the intra-AS tunnel segment, as specified in the PMSI 1221 Tunnel attribute of the found Inter-AS I-PMSI A-D route, are 1222 transmitted on the one hop ASBR-ASBR LSP, as specified by the MPLS 1223 label carried in the PMSI Tunnel attribute of the Leaf A-D route. 1225 9.2.3.4. Inter-AS I-PMSI A-D route received via IBGP 1227 In the context of this section we use the term "PE/ASBR router" to 1228 denote either a PE or an ASBR router. 1230 If a given Inter-AS I-PMSI A-D route is received via IBGP by a BGP 1231 Route Reflector, the BGP Route Reflector MUST NOT modify the Next Hop 1232 field of the MP_REACH_NLRI attribute when re-advertising the route 1233 into IBGP (this is because the information carried in the Next Hop is 1234 used for controling flow of C-multicast routes, as specified in 1235 Section "Propagating C-multicast routes by an ASBR"). 1237 If a given Inter-AS I-PMSI A-D route is advertised within an AS by 1238 multiple ASBRs of that AS, the BGP best route selection performed by 1239 other PE/ASBR routers within the AS does not require all these 1240 PE/ASBR routers to select the route advertised by the same ASBR - to 1241 the contrary different PE/ASBR routers may select routes advertised 1242 by different ASBRs. 1244 When a PE/ASBR router receives from one of its IBGP neighbors a BGP 1245 Update message that carries an Inter-AS I-PMSI A-D route, if (a) at 1246 least one of the Route Targets carried in the message matches one of 1247 the import Route Targets configured on the PE/ASBR, and (b) the 1248 PE/ASBR determines that the received route is the best route to the 1249 destination carried in the NLRI of the route, the PE/ASBR performs 1250 the following operations. 1252 If the router is a PE, then the router imports the route into the 1253 VRF(s) that have the matching import Route Targets. 1255 If the router is an ASBR then the ASBR propagates the route to its 1256 EBGP neighbors. When propagating the route to the EBGP neighbors the 1257 ASBR MUST set the Next Hop field of the MP_REACH_NLRI attribute to a 1258 routable IP address of the ASBR. If the received Inter-AS I-PMSI A-D 1259 route carries the PMSI Tunnel attribute, then the propagated route 1260 MUST carry the PMSI Tunnel attribute with the Tunnel Type set to 1261 Ingress Replication; the attribute carries no MPLS labels. 1263 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1264 attribute with the Tunnel Type set to mLDP P2MP LSP, or PIM-SSM tree, 1265 or PIM-SM tree, or PIM-Bidir tree, the PE/ASBR SHOULD join as soon as 1266 possible the P-Multicast tree whose identity is carried in the Tunnel 1267 Identifier. 1269 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1270 attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then 1271 the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP 1272 with the local PE/ASBR as a leaf. This LSP MAY have been established 1273 before the local PE/ASBR receives the route, or MAY be established 1274 after the local PE receives the route. 1276 If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1277 attribute with the Tunnel Type set to mLDP P2MP LSP, or RSVP-TE P2MP 1278 LSP, or PIM-SSM, or PIM-SM tree, or PIM-Bidir tree, but the attribute 1279 does not carry a label, then the P-Multicast tree, as identified by 1280 the PMSI Tunnel Attribute, is an intra-AS LSP segment that is part of 1281 the inter-AS Tunnel for the MVPN advertised by the Inter-AS I-PMSI A- 1282 D route and rooted at the AS that originated the Inter-AS I-PMSI A-D 1283 route. If the PMSI Tunnel attribute carries a (upstream assigned) 1284 label, then a combination of this tree and the label identifies the 1285 intra-AS segment. If the receiving router is an ASBR, this intra-AS 1286 segment may further be stitched to the ASBR-ASBR inter-AS segment of 1287 the inter-AS tunnel. If the PE/ASBR has local receivers in the MVPN, 1288 packets received over the intra-AS segment must be forwarded to the 1289 local receivers using the local VRF. 1291 9.2.3.4.1. Originating Leaf A-D route into IBGP 1293 If the Leaf Information Required flag in the PMSI Tunnel attribute of 1294 the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR 1295 MUST originate a new Leaf A-D route as follows. 1297 + The route carries a single MCAST-VPN NLRI with the Route Key 1298 field set to the MCAST-VPN NLRI of the Inter-AS I-PMSI A-D route 1299 received from that neighbor, and the Originating Router's IP 1300 address set to the IP address of the PE/ASBR (this MUST be a 1301 routable IP address). 1303 + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel 1304 attribute with the Tunnel Type set to Ingress Replication, then 1305 the Leaf A-D route MUST carry the PMSI Tunnel attribute with the 1306 Tunnel Type set to Ingress Replication. The Tunnel Identifier 1307 MUST carry a routable address of the PE/ASBR. The PMSI Tunnel 1308 attribute MUST carry a downstream assigned MPLS label that is 1309 used to demultiplex the MVPN traffic received over a unicast 1310 tunnel by the PE/ASBR. 1312 + The PE/ASBR constructs an IP-based Route Target community by 1313 placing the IP address carried in the next hop of the received 1314 Inter-AS I-PMSI A-D route in the Global Administrator field of 1315 the community, with the Local Administrator field of this 1316 community set to 0, and sets the Extended Communities attribute 1317 of the Leaf A-D route to that community. 1319 + The Next Hop field of the MP_REACH_NLRI attribute of the route 1320 MUST be set to the same IP address as the one carried in the 1321 Originating Router's IP Address field of the route. 1323 + To constrain the distribution scope of this route the route MUST 1324 carry the NO_EXPORT BGP community ([RFC1997]). 1326 + Once the Leaf A-D route is constructed, the PE/ASBR advertises 1327 this route into IBGP. 1329 9.2.3.5. Leaf A-D route received via IBGP 1331 When an ASBR receives via IBGP a Leaf A-D route, if the Route Target 1332 carried in the Extended Communities attribute of the route matches 1333 one of the ASBR Import RT (auto)configured on the ASBR, the ASBR 1334 performs the following. 1336 The ASBR finds an Inter-AS I-PMSI A-D route whose MCAST-VPN NLRI has 1337 the same value as the Route Key field of the the Leaf A-D route. 1339 The received route may carry either (a) no PMSI Tunnel attribute, or 1340 (b) the PMSI Tunnel attribute, but only with the Tunnel Type set to 1341 Ingress Replication. 1343 If the received route does not carry the PMSI Tunnel attribute, the 1344 ASBR uses the information from the received route to determine the 1345 leaves of the P-Multicast tree rooted at the ASBR that would be used 1346 for the intra-AS segment associated with the found Inter-AS I-PMSI A- 1347 D route. The IP address of a leaf is the IP address carried in the 1348 Originating Router's IP address field of the received Leaf A-D route. 1350 If the received route carries the PMSI Tunnel attribute with the 1351 Tunnel Type set to Ingress Replication the ASBR uses the information 1352 carried by the route to construct the intra-AS segment with ingress 1353 replication. 1355 9.2.3.6. Optimizing Bandwidth by IP filtering on ASBRs 1357 An ASBR that has a given Inter-AS I-PMSI A-D route MAY discard some 1358 of the traffic carried in the tunnel specified in the PMSI Tunnel 1359 attribute of this route if the ASBR determines that there are no 1360 downstream receivers for that traffic. 1362 When BGP is being used to distribute C-multicast routes, an ASBR that 1363 has a given Inter-AS I-PMSI A-D route MAY discard traffic from a 1364 particular customer multicast source C-S and destined to a particular 1365 customer multicast group address C-G that is carried over the tunnel 1366 specified in the PMSI Tunnel attribute of the route, if none of the 1367 C-multicast routes on the ASBR with RD and Source AS being the same 1368 as the RD and Source AS of the Inter-AS I-PMSI A-D route matches the 1369 (C-S,C-G) tuple. A C-multicast route is said to match a (C-S,C-G) 1370 tuple, if it is a Source Tree Join route with Multicast Source set to 1371 C-S and Multicast Group set to C-G, or a Shared Tree Join route with 1372 Multicast Group set to C-G. 1374 The above procedures MAY also apply to an ASBR that originates a 1375 given Inter-AS I-PMSI A-D route. In this case the ASBR applies them 1376 to the traffic carried over the tunnels specified in the PMSI Tunnel 1377 attribute of the Intra-AS I-PMSI A-D routes that the ASBR aggregates 1378 into the Inter-AS I-PMSI A-D route, and whose tails are stiched to 1379 the one-hop ASBR-ASBR tunnel specified in the Inter-AS I-PMSI A-D 1380 route. 1382 10. Non-congruent Unicast and Multicast Connectivity 1384 It is possible to deploy MVPN such that the multicast routing and the 1385 unicast routing are "non-congruent". For instance, the CEs may be 1386 distributing to the PEs a special set of unicast routes that are to 1387 be used exclusively for the purpose of upstream multicast hop 1388 selection, and not used for unicast routing at all. (For example, 1389 when BGP is the CE-PE unicast routing protocol, the CEs may be using 1390 SAFI 2 ("Network Layer Reachability Information used for multicast 1391 forwarding" [IANA-SAFI]), and either IPv4 or IPv6 AFI to distribute a 1392 special set of routes that are to be used for, and only for, upstream 1393 multicast hop selection.) In such a situation, we will speak of the 1394 MVPN as having two VRFs on a given PE, one containing the routes that 1395 are used for unicast, the other containing the unicast routes that 1396 are used for upstream multicast hop (UMH) selection. We will call the 1397 former the "unicast routing VRF", and the latter the "UMH VRF" 1398 (upstream multicast hop VRF). 1400 In this document, when we speak without qualification of the MVPN's 1401 VRF, then if the MVPN has both a unicast VRF and a UMH VRF, we are 1402 speaking of the UMH VRF. (Of course, if there is no separate UMH VRF, 1403 then we are speaking of the unicast VRF.) 1405 If there is a separate UMH VRF, it MAY have its own import and export 1406 Route Targets, different from the ones used by the unicast VRF. These 1407 Route Targets MUST be used to control distribution of auto-discovery 1408 routes. In addition, the export Route Targets of the UMH VRF are 1409 added to the Route Targets used by the unicast VRF when originating 1410 (unicast) VPN-IP routes. The import Route Targets associated with a 1411 given UMH VRF are used to determine which of the received (unicast) 1412 VPN-IP routes should be accepted into the UMH VRF. 1414 If a PE maintains an UMH VRF for that MVPN, then it is RECOMMENDED 1415 that the UMH VRF should use the same RD as the one used by the 1416 unicast VRF of that MVPN. 1418 If an MVPN site is multi-homed to several PEs, then to support non- 1419 congruent unicast and multicast connectivity, on each of these PEs 1420 the UMH VRF of the MVPN MUST use its own distinct RD (although on a 1421 given PE the RD used by the UMH VRF SHOULD be the same as the one 1422 used by the unicast VRF). 1424 If an MVPN has a UMH VRF distinct from its unicast VRF, then one 1425 option to support non-congruency is by exchanging the routes from/to 1426 that UMH VRF by using the same AFI/SAFI as used by the routes from 1427 the unicast VRF. 1429 Another option is to exchange the routes from/to the UMH VRF using 1430 the IPv4 or IPv6 AFI (as appropriate), but with the SAFI set to 1431 "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" [IANA- 1432 SAFI]. The NLRI carried by these routes is defined as follows: 1434 +---------------------------+ 1435 | Length (1 octet) | 1436 +---------------------------+ 1437 | Prefix (variable) | 1438 +---------------------------+ 1440 The use and the meaning of these fields are as follows: 1442 a) Length: 1444 The Length field indicates the length in bits of the address 1445 prefix plus the label(s). 1447 b) Prefix: 1449 The Prefix field contains a Route Distinguisher as defined 1450 in [RFC4364] prepended to an IPv4 or IPv6 address prefix, 1451 followed by enough trailing bits to make the end of the 1452 field fall on an octet boundary. Note that the value of 1453 trailing bits is irrelevant. 1455 These routes MUST carry the VRF Route Import Extended Community. If 1456 for a given MVPN BGP is used for exchanging C-multicast routes, or if 1457 segmented inter-AS tunnels are used, then these routes also MUST 1458 carry the Source AS extended community. 1460 The detailed procedures for selecting forwarder PE in the presence of 1461 such routes are outside the scope of this document. However, this 1462 document requires these procedures to preserve the constrains imposed 1463 by the single forwarder PE selection procedures, as specified in 1464 [MVPN]. 1466 11. Exchange of C-Multicast Routing Information among PEs 1468 VPN C-Multicast Routing Information is exchanged among PEs by using 1469 C-multicast routes that are carried using MCAST-VPN NLRI. These 1470 routes are originated and propagated as follows. 1472 11.1. Originating C-multicast routes by a PE 1474 Part of the procedures for constructing MCAST-VPN NLRI depend on the 1475 multicast routing protocol between CE and PE (C-multicast protocol). 1477 11.1.1. Originating routes: PIM as the C-Multicast protocol 1479 The following specifies construction of MCAST-VPN NLRI of C-multicast 1480 routes for the case where the C-multicast protocol is PIM. These C- 1481 multicast routes are originated as a result of updates in (C-S, C-G), 1482 or (C-*, C-G) state learnt by a PE via the C-multicast protocol. 1484 Note that creation and deletion of (C-S, C-G, RPTbit) states on a PE 1485 when the C-multicast protocol is PIM do not result in any BGP 1486 actions. 1488 11.1.1.1. Originating Source Tree Join C-multicast route 1490 Whenever (a) a C-PIM instance on a particular PE creates a new (C- 1491 S,C-G) state, and (b) the selected upstream PE for C-S (see [MVPN]) 1492 is not the local PE, then the local PE MUST originate a a C-multicast 1493 route of a type Source Tree Join. The Multicast Source field in the 1494 MCAST-VPN NLRI of the route is set to C-S, the Multicast Group field 1495 is set of C-G. 1497 This C-multicast route is said to "correspond" to the C-PIM (C-S,C-G) 1498 state. 1500 The semantics of the route is that the PE has one or more receivers 1501 for (C-S, C-G) in the sites connected to the PE (the route has the 1502 (C-S, C-G) Join semantics). 1504 Whenever a C-PIM instance on a particular PE deletes a (C-S,C-G) 1505 state, the corresponding C-multicast route MUST be withdrawn. (The 1506 withdrawal of the route has the (C-S, C-G) Prune semantics). The 1507 MCAST-VPN NLRI of the withdrawn route is carried in the 1508 MP_UNREACH_NLRI attribute. 1510 11.1.1.2. Originating Shared Tree Join C-multicast route 1512 Whenever (a) a C-PIM instance on a particular PE creates a new 1513 (C-*,C-G) state, and (b) the selected upstream PE for the C-RP 1514 corresponding to the C-G (see [MVPN]) is not the local PE, then the 1515 local PE MUST originate a a C-multicast route of a type Shared Tree 1516 Join. The Multicast Source field in the MCAST-VPN NLRI of the route 1517 is set to the C-RP address. The Multicast Group field in the MCAST- 1518 VPN NLRI is set to the C-G address. 1520 This C-multicast route is said to "correspond" to the C-PIM (C-*,C-G) 1521 state. 1523 The semantics of the route is that the PE has one or more receivers 1524 for (C-*, C-G) in the sites connected to the PE (the route has the 1525 (C-*, C-G) Join semantics). 1527 Whenever a C-PIM instance on a particular PE deletes a (C-*,C-G) 1528 state, the corresponding C-multicast route MUST be withdrawn. (The 1529 withdrawal of the route has the (C-S, C-G) Prune semantics). The 1530 MCAST-VPN NLRI of the withdrawn route is carried in the 1531 MP_UNREACH_NLRI attribute. 1533 11.1.2. Originating routes: mLDP as the C-Multicast protocol 1535 The following specifies construction of MCAST-VPN NLRI of C-multicast 1536 routes for the case where the C-multicast protocol is mLDP [mLDP]. 1538 Whenever a PE receives from one of its CEs a P2MP Label Map 1539 over interface I, where X is the Root Node Address, Y is the Opaque 1540 Value, and L is an MPLS label, the PE checks whether it already has 1541 state for in the VRF associated with the CE. If yes, then all 1542 the PE needs to do in this case is to update its forwarding state by 1543 adding to the forwarding state associated with . 1545 If the PE does not have state for in the VRF associated with 1546 the CE, then the PE constructs a Source Tree Join C-multicast route 1547 whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y 1548 as the Multicast Group field. 1550 Whenever a PE deletes a previously created state that had 1551 resulted in originating a C-multicast route, the PE withdraws the C- 1552 multicast route. The MCAST-VPN NLRI of the withdrawn route is carried 1553 in the MP_UNREACH_NLRI attribute. 1555 11.1.3. Constructing the rest of the C-multicast route 1557 The rest of the C-multicast route is constructed as follows (the same 1558 procedures apply to both PIM and mLDP as the C-Multicast protocol). 1560 The local PE executes the procedures of [MVPN] to find the selected 1561 Upstream Multicast Hop (UMH) route and the selected upstream PE for 1562 the address carries in the Multicast Source field of MCAST-VPN NLRI. 1564 From the selected UMH route the local PE extracts (a) the autonomous 1565 system number of the upstream PE (as carried in the Source AS 1566 extended community of the route), and (b) the C-multicast Import RT 1567 of the VRF on the upstream PE (the value of this C-multicast Import 1568 RT is the value of the VRF Route Import Extended Community carried by 1569 the route). The Source AS field in the C-multicast route is set to 1570 that autonomous system. The Route Target Extended Community of the C- 1571 multicast route is set to that C-multicast Import RT. 1573 If there is more than one (remote) PE that originates the (unicast) 1574 route to the address carried in the Multicast Source field of the 1575 MCAST-VPN NLRI, then the procedures for selecting the UMH route and 1576 the upstream PE to reach that address are as specified in [MVPN]. 1578 If the local and the upstream PEs are in the same AS, then the RD of 1579 the advertised MCAST-VPN NLRI is set to the RD of the VPN-IP route 1580 that contains the address carried in the Multicast Source field. 1582 The C-multicast route is then advertised into IBGP. 1584 If the local and the upstream PEs are in different ASes, then the 1585 local PE finds in its VRF an Inter-AS I-PMSI A-D route whose Source 1586 AS field carries the autonomous system number of the upstream PE. 1587 The RD of the found Inter-AS I-PMSI A-D route is used as the RD of 1588 the advertised C-multicast route. The local PE constructs an IP-based 1589 Route Target community by placing the next hop of the found Inter-AS 1590 I-PMSI A-D route in the Global Administrator field of this community, 1591 with the Local Administrator field of this community set to 0, and 1592 adds this community to the Extended Communities attribute of the C- 1593 multicast route. (Note that this Route Target is the same as the ASBR 1594 Import RT of the ASBR identified by the next hop of the found Inter- 1595 AS I-PMSI A-D route.) 1597 Inter-AS I-PMSI A-D routes are not used to support non-segmented 1598 inter-AS tunnels. To support non-segmented inter-AS tunnels, if the 1599 local and the upstream PEs are in different ASes, the local system 1600 finds in its VRF an Intra-AS I-PMSI A-D route from the upstream PE 1601 (the Originating Router's IP Address field of that route has the same 1602 value as the one carried in the VRF Route Import of the (unicast) 1603 route to the address carried in the Multicast Source field). The RD 1604 of the found Intra-AS I-PMSI A-D route is used as the RD of the 1605 advertised C-multicast route. The Source AS field in the C-multicast 1606 route is set to value of the Originating Router's IP Address field of 1607 the found Intra-AS I-PMSI A-D route. 1609 The Next Hop field of the MP_REACH_NLRI attribute MUST be set to a 1610 routable IP address of the local PE. 1612 If the next hop of the found (Inter-AS or Intra-AS) I-PMSI A-D route 1613 is an EBGP neighbor of the local PE, then the PE advertises the C- 1614 multicast route to that neighbor. If the next hop of the found 1615 (Inter-AS or Intra-AS) I-PMSI A-D route is within the same AS as the 1616 local PE, then the PE advertises the C-multicast route into IBGP. 1618 11.1.4. Unicast Route Changes 1620 The particular UMH route that is selected by a given PE for a given 1621 C-S may be influenced by the network's unicast routing. In that case, 1622 a change in the unicast routing may invalidate prior choices of the 1623 UMH route for some C-S. If this happens, the local PE MUST execute 1624 the UMH route selection procedures for C-S again. If the result is 1625 that a different UMH route is selected, then for all C-G, any 1626 previously originated C-multicast routes for (C-S,C-G) MUST be re- 1627 originated. 1629 Similarly, if a unicast routing change results in a change of the UMH 1630 route for a C-RP, then for all C-G such that C-RP is the RP 1631 associated with C-G, any previously originated C-multicast routes for 1632 (C-*,C-G) MUST be re-originated. 1634 11.2. Propagating C-multicast routes by an ASBR 1636 When an ASBR receives a BGP Update message that carries a C-multicast 1637 route, if at least one of the Route Targets of the route matches one 1638 of the ASBR Import RTs (auto)configured on the ASBR, the ASBR finds 1639 an Inter-AS I-PMSI A-D route whose RD and Source AS matches the RD 1640 and Source AS carried in the C-multicast route. If no matching route 1641 is found, the ASBR takes no further actions. If a matching route is 1642 found, the ASBR proceeds as follows. 1644 To support non-segmented inter-AS tunnels, instead of matching the RD 1645 and Source AS carried in the C-multicast route against the RD and 1646 Source AS of an Inter-AS I-PMSI A-D route, the ASBR should match it 1647 against the RD and the Originating Router's IP Addr of the Intra-AS 1648 I-PMSI A-D routes. 1650 The ASBR first checks if it already has one or more C-multicast 1651 routes that have the same MCAST-VPN NLRI as the newly received route. 1652 If such route(s) already exists, the ASBR keeps the newly received 1653 route, but SHALL NOT re-advertise the newly received route. 1654 Otherwise, the ASBR re-advertises the route, as described further 1655 down. 1657 When an ASBR receives a BGP Update message that carries a withdraw of 1658 a previously advertised C-multicast route, the ASBR first checks if 1659 it already has at least one other C-multicast route that has the same 1660 MCAST-VPN NLRI. If such a route already exists, the ASBR processes 1661 the withdrawn route, but SHALL NOT re-advertise the withdraw. 1662 Otherwise, the ASBR re-advertises the withdrawal of the previously 1663 advertised C-multicast route, as described below. 1665 If the ASBR is the ASBR that originated the found Inter-AS I-PMSI A-D 1666 route, then before re-advertising the C-multicast route into IBGP the 1667 ASBR removes from the route the Route Target that matches one of the 1668 ASBR Import RTs (auto)configured on the ASBR. 1670 If the ASBR is not the ASBR that originated the found Inter-AS I-PMSI 1671 A-D route, then before re-advertising the C-multicast route, the ASBR 1672 modifies the Extended Communities attribute of the C-multicast route 1673 by replacing the Route Target of the route that matches one of the 1674 ASBR Import RTs (auto)configured on the ASBR with a new Route Target 1675 constructed as follows. The new Route Target is an IP-based Route 1676 Target that has the Global Administrator field set to the Next Hop of 1677 the found Inter-AS I-PMSI A-D route, and Local Administrator field of 1678 this community set to 0. Note that this newly constructed Route 1679 Target is the same as the ASBR Import RT of the ASBR identified by 1680 the next hop of the found Inter-AS I-PMSI A-D route. The rest of the 1681 Extended Communities attribute of the route SHOULD be passed 1682 unmodified. 1684 The Next Hop field of the MP_REACH_NLRI attribute SHOULD be set to an 1685 IP address of the ASBR. 1687 If the Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or 1688 Intra-AS) I-PMSI A-D route is an EBGP neighbor of the ASBR, then the 1689 ASBR re-advertises the C-multicast route to that neighbor. If the 1690 Next Hop field of the MP_REACH_NLRI of the found (Inter-AS or Intra- 1691 AS) I-PMSI A-D route is an IBGP neighbor of the ASBR, the ASBR re- 1692 advertises the C-multicast route into IBGP. If it is the ASBR that 1693 originated the found Inter-AS I-PMSI A-D route in the first place, 1694 then the ASBR just re-advertises the C-multicast route into IBGP. 1696 11.3. Receiving C-multicast routes by a PE 1698 When a PE receives a C-multicast route the PE checks if any of the 1699 Route Target communities carried in the Extended Communities 1700 attribute of the route match any of the C-multicast Import RTs 1701 associated with the VRFs of any MVPN maintained by the PE. If no 1702 match is found the PE SHOULD discard the route. Otherwise, (if a 1703 match is found), the PE checks if the address carried in the 1704 Multicast Source field of the C-multicast route matches one of the 1705 (unicast) VPN-IP routes advertised by PE from the VRF. If no match is 1706 found the PE SHOULD discard the route. Otherwise, (if a match is 1707 found), the PE proceeds as follows, depending on the multicast 1708 routing protocol between CE and PE (C-multicast protocol). 1710 11.3.1. Receiving routes: PIM as the C-Multicast protocol 1712 The following described procedures when PIM is used as the multicast 1713 routing protocol between CE and PE (C-multicast protocol). 1715 Since C-multicast routing information is disseminated by BGP, PIM 1716 messages are never sent from one PE to another. 1718 11.3.1.1. Receiving Source Tree Join C-multicast route 1720 If the received route has the route type set to Source Tree Join, 1721 then the PE creates a new (C-S, C-G) state in its MVPN-TIB from the 1722 Multicast Source and Multicast Group fields in the MCAST-VPN NLRI of 1723 the route, if such a state does not already exist. 1725 If the local policy on the PE is to bind (C-S, C-G) to an S-PMSI, 1726 then the PE adds the S-PMSI to the outgoing interface list of the (C- 1727 S, C-G) state, if it is not already there. Otherwise, the PE adds an 1728 I-PMSI to the outgoing interface list of the (C-S, C-G) state, if it 1729 is not already there. 1731 When, for a said VRF, the last Source Tree Join C-multicast route for 1732 (C-S, C-G) is withdrawn, resulting in the situation where the VRF 1733 contains no Source Tree Join C-multicast route for (C-S, C-G) the PE 1734 MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the 1735 (C-S, C-G) state. Depending on the (C-S, C-G) state of the PE-CE 1736 interfaces, this may result in the PE using PIM procedures to prune 1737 itself off the (C-S, C-G) tree. If C-G is not in the SSM range for 1738 the VRF, then removing the I-PMSI/S-PMSI from the outgoing interface 1739 list of the (C-S, C-G) state SHOULD be done after a delay that is 1740 controlled by a timer. The value of the timer MUST be configurable. 1742 The purpose of this timer is to ensure that the PE does not stop 1743 forwarding (C-S, C-G) onto a PMSI tunnel until all the PEs of the 1744 same MVPN have had time to receive the withdrawal of the Source 1745 Active A-D route for (C-S, C-G) (see Section 13.1 "Source Within a 1746 Site - Source Active Advertisement"), and the PE connected to C-RP 1747 starts forwarding (C-S, C-G) on the C-RPT. 1749 Note that before the PE stops forwarding (C-S, C-G), there is a 1750 possibility to have (C-S, C-G) packets being sent at the same time on 1751 the PMSI by both the local PE and the PE connected to the site that 1752 contains C-RP. This would result in a transient unnecessary traffic 1753 on the provider backbone. However, no duplicates will reach customer 1754 hosts subscribed to C-G as long as the downstream PEs apply 1755 procedures described in section 9.1 of [MVPN]. 1757 11.3.1.2. Receiving Shared Tree Join C-multicast route 1759 If the received route has the route type set to Shared Tree Join, 1760 then the PE creates a new (C-*, C-G) state in its MVPN-TIB with the 1761 RP address for that state taken from the Multicast Source, and C-G 1762 for that state taken from the Multicast Group fields of the MCAST-VPN 1763 NLRI of the route, if such a state does not already exist. If there 1764 is no S-PMSI for (C-*, C-G), then the PE adds I-PMSI to the outgoing 1765 interface list of the state if it is not already there. If there is 1766 an S-PMSI for (C-*, C-G), then the PE adds S-PMSI to the outgoing 1767 interface list of the state if it is not already there. 1769 When, for a said VRF, the last Shared Tree Join C-multicast route for 1770 (C-*, C-G) is withdrawn, resulting in the situation where the VRF 1771 contains no Shared Tree Join C-multicast route for (C-*, C-G) the PE 1772 MUST remove the I-PMSI/S-PMSI from the outgoing interface list of the 1773 (C-*, C-G) state. Depending on the (C-*, C-G) state of the PE-CE 1774 interfaces, this may result in the PE using PIM procedures to prune 1775 itself off the (C-*, C-G) tree. 1777 11.3.2. Receiving routes: mLDP as the C-Multicast protocol 1779 The following described procedures when mLDP is used as the multicast 1780 routing protocol between CE and PE (C-multicast protocol). 1782 When mLDP is used as a C-multicast protocol, the only valid type of a 1783 C-multicast route that a PE could receive is a Source Tree Join C- 1784 multicast route. 1786 When the PE receives a Source Tree Join C-multicast route, the PE 1787 applies, in the scope of this VRF, the P2MP mLDP procedures for a 1788 transit node using the value carried in the Multicast Source field of 1789 the route as the C-Root Node Identifier, and the value carried in the 1790 Multicast Group of the route as the C-LDP MP Opaque Value Element. 1792 If there is no S-PMSI for then the PE creates and advertises an S-PMSI as 1794 described in Section "Using S-PMSI A-D routes to Bind C-trees to P- 1795 tunnels" using C-Root Node Identifier as the value for the Multicast 1796 Source field of the S-PMSI A-D route and C-LDP MP Opaque Value 1797 Element as the value for the Multicast Group field of the route. 1799 To improve scalability when mLDP is used as the C-Multicast protocol 1800 for a given MVPN, within each AS that has sites of that MVPN 1801 connected to the PEs of that AS, all the S-PMSIs of that MVPN MAY be 1802 aggregated into a single P-Multicast tree (by using upstream assigned 1803 labels). 1805 11.4. C-multicast routes aggregation 1807 Note that C-multicast routes are "de facto" aggregated by BGP. This 1808 is because the MCAST-VPN NLRIs advertised by multiple PEs, for a C- 1809 multicast route for a particular C-S and C-G (or a particular C-* and 1810 C-G) of a given MVPN are identical. 1812 Hence a BGP Route Reflector or ASBR that receives multiple such 1813 routes with the same NLRI will re-advertise only one of these routes 1814 to other BGP speakers. 1816 This implies that C-multicast routes for a given (S,G) of a given 1817 MVPN originated by PEs that are clients of a given Route Reflector 1818 are aggregated by the Route Reflector. For instance, if multiple PEs 1819 that are clients of a Route Reflector, have receivers for a specific 1820 SSM channel of a MVPN, they will all advertise an identical NLRI for 1821 the "Source Tree Join" C-multicast route. However only one C- 1822 multicast route will be advertised by the Route Reflector for this 1823 specific SSM channel of that MVPN, to other PEs and Route Reflectors 1824 that are clients of the Route Reflector. 1826 This also implies that an ASBR aggregates all the received C- 1827 multicast routes for a given (S,G) (or a given (*,G)) of a given MVPN 1828 into a single C-multicast route. 1830 To further reduce the routing churn due to C-multicast routes changes 1831 a Route Reflector that re-advertises a C-multicast route SHOULD set 1832 the Next Hop field of the MP_REACH_NLRI attribute of the route to an 1833 IP address of the Route Reflector. Likewise, an ASBR that re- 1834 advertises a C-multicast route SHOULD set the Next Hop field of the 1835 MP_REACH_NLRI attribute of the route to an IP address of the ASBR. 1837 Further a BGP receiver, that receives multiple such routes with the 1838 same NLRI for the same C-multicast route, will potentially create 1839 forwarding state based on a single C-multicast route. As per the 1840 procedures described in Section "Receiving C-Multicast Routes by a 1841 PE", this forwarding state will be the same as the state that would 1842 have been created based on another route with same NLRI. 1844 12. Using S-PMSI A-D routes to Bind C-trees to P-tunnels 1846 This section describes BGP-based procedures for using S-PMSIs A-D 1847 routes to bind (C-S, C-G) trees to P-tunnels. 1849 12.1. Originating S-PMSI A-D routes 1851 The following describes procedures for originating S-PMSI A-D routes 1852 by a PE. 1854 The PE constructs the MCAST-VPN NLRI of an S-PMSI A-D route for a 1855 given (C-S, C-G) as follows. 1857 + The RD in this NLRI is set to the RD of the MVPN's VRF associated 1858 with (C-S, C-G). 1860 + The Multicast Source field MUST contain the source address 1861 associated with the C-multicast stream, and the Multicast Source 1862 Length field is set appropriately to reflect this. 1864 + The Multicast Group field MUST contain the group address 1865 associated with the C-multicast stream, and the Multicast Group 1866 Length field is set appropriately to reflect this. 1868 + The Originating Router's IP Address field MUST be set to the IP 1869 address that the (local) PE places in the Global Administrator 1870 field of the VRF Route Import extended community of the VPN-IP 1871 routes advertised by the PE. Note that the tuple uniquely identifies a given multicast 1873 VRF. 1875 The PE constructs the rest of the S-PMSI A-D route as follows. 1877 Depending on the type of a P-Multicast tree used for the P-tunnel, 1878 the PMSI tunnel attribute of the S-PMSI A-D route is constructed as 1879 follows: 1881 + The PMSI tunnel attribute MUST contain the identity of the P- 1882 Multicast tree (note that the PE could create the identity of the 1883 tree prior to the actual instantiation of the tree). 1885 + If in order to establish the P-Multicast tree the PE needs to 1886 know the leaves of the tree within its own AS, then the PE 1887 obtains this information from the Leaf A-D routes received from 1888 other PEs/ASBRs within its own AS (as other PEs/ASBRs originate 1889 Leaf A-D routes in response to receiving the S-PMSI A-D route) by 1890 setting the Leaf Information Required flag in the PMSI Tunnel 1891 attribute to 1. 1893 + If a PE originates S-PMSI A-D routes with the Leaf Information 1894 Required flag in the PMSI Tunnel attribute set to 1, then the PE 1895 MUST be (auto)configured with an import Route Target, which 1896 controls acceptance of Leaf A-D routes by the PE. (Procedures for 1897 originating Leaf A-D routes by the PEs that receive the S-PMSI A- 1898 D route are described in section "Receiving S-PMSI A-D routes by 1899 PEs.) 1901 This Route Target is IP address specific. The Global 1902 Administrator field of this Route Target MUST be set to the IP 1903 address carried in the Next Hop of all the S-PMSI A-D routes 1904 advertised by this PE (if the PE uses different Next Hops, then 1905 the PE MUST be (auto)configured with multiple import RTs, one per 1906 each such Next Hop). The Local Administrator field of this Route 1907 Target MUST be set to 0. 1909 If the PE supports Route Target Constrain [RT-CONSTRAIN], the PE 1910 SHOULD advertise this import Route Target within its own AS using 1911 Route Target Constrains. To constrain distribution of the Route 1912 Target Constrain routes to the AS of the advertising PE these 1913 routes SHOULD carry the NO_EXPORT Community ([RFC1997]). 1915 + A PE MAY aggregate two or more S-PMSIs originated by the PE onto 1916 the same P-Multicast tree. If the PE already advertises S-PMSI A- 1917 D routes for these S-PMSIs, then aggregation requires the PE to 1918 re-advertise these routes. The re-advertised routes MUST be the 1919 same as the original ones, except for the PMSI tunnel attribute. 1920 If the PE has not previously advertised S-PMSI A-D routes for 1921 these S-PMSIs, then the aggregation requires the PE to advertise 1922 (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel 1923 attribute in the newly advertised/re-advertised routes MUST carry 1924 the identity of the P-Multicast tree that aggregates the S-PMSIs. 1925 If at least some of the S-PMSIs aggregated onto the same P- 1926 Multicast tree belong to different MVPNs, then all these routes 1927 MUST carry an MPLS upstream assigned label [RFC5331]. 1929 If all these aggregated S-PMSIs belong to the same MVPN, and this 1930 MVPN uses PIM as its C-multicast routing protocol, then the 1931 corresponding S-PMSI A-D routes MAY carry an MPLS upstream 1932 assigned label [RFC5331]. Moreover, in this case the labels MUST 1933 be distinct on a per MVPN basis, and MAY be distinct on a per 1934 route basis. 1936 If all these aggregated S-PMSIs belong to the MVPN(s) that use 1937 mLDP as its C-multicast routing protocol, then the corresponding 1938 S-PMSI A-D routes MUST carry an MPLS upstream assigned label 1940 [RFC5331], and these labels MUST be distinct on a per route (per 1941 mLDP FEC) basis, irrespective of whether the aggregated S-PMSIs 1942 belong to the same or different MVPNs. 1944 The Next Hop field of the MP_REACH_NLRI attribute of the route MUST 1945 be set to the same IP address as the one carried in the Originating 1946 Router's IP Address field. 1948 The route always carries a set of Route Targets. The default set of 1949 Route Targets is determined as follows: 1951 + If there is a (unicast) VPN-IP route to C-S originate from the 1952 VRF, but no (unicast) VPN-IP route to C-RP originated from the 1953 VRF, then the set of Route Targets is set to a set intersection 1954 between the set of Route Targets carried in the intra-AS I-PMSI 1955 A-D route originated from the VRF, and the set of Route Targets 1956 carried by the (unicast) VPN-IP route to C-S. 1958 + If there is no (unicast) VPN-IP route to C-S originated from the 1959 VRF, but there is a (unicast) VPN-IP route to C-RP originated 1960 from the VRF, then the set of Route Targets is set to a set 1961 intersection between the set of Route Targets carried in the 1962 intra-AS I-PMSI A-D route originated from the VRF, and the set of 1963 Route Targets carried by the (unicast) VPN-IP route to C-RP. 1965 + If there is a (unicast) VPN-IP route to C-S originate from the 1966 VRF, and a (unicast) VPN-IP route to C-RP originated from the 1967 VRF, then the set of Route Targets is set to a set intersection 1968 between the set of Route Targets carried in the intra-AS I-PMSI 1969 A-D route originated from the VRF, and the set union of Route 1970 Targets carried by the (unicast) VPN-IP route to C-S and the 1971 (unicast) VPN-IP route to C-RP. 1973 In each of the above cases, an implementation MUST allow the set of 1974 Route Targets carried by the route to be specified by configuration. 1975 In the absence of a configured set of Route Targets, the route MUST 1976 carry the default set of Route Targets, as specified above. 1978 12.2. Handling S-PMSI A-D routes by ASBRs 1980 Procedures for handling an S-PMSI A-D route by ASBRs (both within and 1981 outside of the AS of the PE that originates the route) are the same 1982 as specified in Section "Propagating Inter-AS Auto-Discovery 1983 Information", except that instead of Inter-AS I-PMSI A-D routes the 1984 procedures apply to S-PMSI A-D routes. 1986 12.2.1. Merging S-PMSI into an I-PMSI 1988 Consider the situation where: 1990 + An ASBR is receiving (or expecting to receive) inter-AS (C-S, C- 1991 G) data from upstream via an S-PMSI. 1993 + The ASBR is sending (or expecting to send) the inter-AS (C-S, C- 1994 G) data downstream via an I-PMSI. 1996 This situation may obtain if the upstream providers have a policy of 1997 using S-PMSIs but the downstream providers have a policy of using I- 1998 PMSIs. To support this situation, an ASBR MAY, under certain 1999 conditions, merge one or more upstream S-PMSIs into a downstream I- 2000 PMSI. 2002 An S-PMSI (corresponding to a particular S-PMSI A-D route) MAY be 2003 merged by a particular ASBR into an I-PMSI (corresponding to a 2004 particular Inter-AS I-PMSI A-D route) if and only if the following 2005 conditions all hold: 2007 + BGP is used to exchange C-multicast routes. 2009 + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route originate 2010 in the same AS. The Inter-AS I-PMSI A-D route carries the 2011 originating AS in the Source AS field of the NLRI of the route, 2012 and also in the AS_PATH attribute of the route. The S-PMSI A-D 2013 route carries the originating AS in the AS_PATH attribute of the 2014 route. 2016 + The S-PMSI A-D route and the Inter-AS I-PMSI A-D route have 2017 exactly the same set of RTs. 2019 + For each (C-S,C-G) mentioned in the S-PMSI route, if the ASBR has 2020 installed a Source Tree Join (C-S, C-G) C-multicast route, then 2021 the S-PMSI route was originated by the upstream PE of the C- 2022 multicast route. The address of the upstream PE is carried in the 2023 RT of the C-multicast route. The address of the PE that 2024 originated the S-PMSI route is carried in the Originating 2025 Router's IP Addr field of the MCAST-VPN NLRI of the route. 2027 + The ASBR supports the optional capability to discard (C-S, C-G) 2028 traffic received on an I-PMSI. 2030 An ASBR performs merging by stitching the tail end of the P-tunnel, 2031 as specified in the the PMSI Tunnel Attribute of the S-PMSI A-D route 2032 received by the ASBR, to the to the head of the P-tunnel, as 2033 specified in the PMSI Tunnel Attribute of the Inter-AS I-PMSI A-D 2034 route re-advertised by the ASBR. 2036 IP processing during merge: If an ASBR merges an (C-S, C-G) S-PMSI A- 2037 D route into an Inter-AS I-PMSI A-D route, the ASBR MUST discard all 2038 (C-S, C-G) traffic it receives on the tunnel advertised in the I-PMSI 2039 A-D route. 2041 An ASBR that merges an S-PMSI A-D route into an Inter-AS I-PMSI A-D 2042 route MUST NOT re-advertise the S-PMSI A-D route. 2044 12.3. Receiving S-PMSI A-D routes by PEs 2046 Consider a PE that receives an S-PMSI A-D route. If one or more of 2047 the VRFs on the PE have their import Route Targets that contain one 2048 or more of the Route Targets carried by the received S-PMSI A-D 2049 route, then for each such VRF (and associated with it MVPN-TIB) the 2050 PE performs the following. 2052 Procedures for receiving an S-PMSI A-D route by a PE (both within and 2053 outside of the AS of the PE that originates the route) are the same 2054 as specified in Section "Inter-AS I-PMSI A-D route received via IBGP" 2055 except that (a) instead of Inter-AS I-PMSI A-D routes the procedures 2056 apply to S-PMSI A-D routes, and (b) a PE performs procedures 2057 specified in that section only if in addition to the criteria 2058 specified in that section one of the following is true: 2060 + the PE originates a Source Tree Join (C-S, C-G) C-multicast 2061 route, and the upstream PE of that route is the PE that 2062 originates the S-PMSI A-D route, or 2064 + the PE does not originate a Source Tree Join (C-S, C-G) C- 2065 multicast route, but originates a Shared Tree Join (C-*, C-G) C- 2066 multicast route, and the best (as determined by the BGP route 2067 selection procedures) Source Active A-D route for (C-S, C-G) 2068 selected by the PE is originated by the same PE as the one that 2069 originates the S-PMSI A-D route, or 2071 + the PE does not originate a Source Tree Join (C-S, C-G), has not 2072 received any Source Active A-D routes for (C-S, C-G), but does 2073 originate a Shared Tree Join (C-*, C-G) route, and the upstream 2074 PE for that route is the PE that originates the received S-PMSI 2075 A-D route. 2077 If the received S-PMSI A-D route has a PMSI Tunnel attribute with the 2078 Leaf Information Required flag set to 1, then the PE originates a 2079 Leaf A-D route. The Route Key of the Leaf A-D route is set to the 2080 MCAST-VPN NLRI of the S-PMSI A-D route. The rest of the Leaf A-D 2081 route is constructed using the same procedures as specified in 2082 section "Originating Leaf A-D route into IBGP", except that instead 2083 of originating Leaf A-D routes in response to receiving Inter-AS I- 2084 PMSI A-D routes the procedures apply to originating Leaf A-D routes 2085 in response to receiving S-PMSI A-D routes. 2087 In addition to the procedures specified in Section "Inter-AS I-PMSI 2088 A-D route received via IBGP" the PE MUST set up its forwarding path 2089 to receive (C-S, C-G) traffic from the tunnel advertised by the S- 2090 PMSI A-D route (the PE MUST switch to the S-PMSI). 2092 If a PE that is a leaf node of a particular Selective tunnel 2093 determines that it no longer needs to receive any of (C-S, C-G)s 2094 carried over that tunnel, the PE SHOULD prune itself off that tunnel. 2095 Procedures for pruning are specific to a particular tunneling 2096 technology. 2098 13. Switching from Shared C-tree to Source C-tree 2100 The procedures defined in this section only apply when the C- 2101 multicast routing protocol is PIM [RFC4601], moreover only apply for 2102 the multicast ASM mode, and MUST NOT be applied to Multicast Group 2103 addresses belonging to the SSM range. The procedures also MUST NOT be 2104 applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015]. 2106 The procedures of this section are applicable only to MVPNs that use 2107 both shared (i.e., rooted at a C-RP) and source (i.e., rooted at a C- 2108 S) inter-site C-trees. 2110 These procedures are not applicable to MVPNs that do not use shared 2111 inter-site C-trees and rely solely on source inter-site C-trees. See 2112 section ""Supporting PIM-SM without Inter-Site C-Shared Trees" for 2113 the procedures applicable to that scenario. 2115 Whether a given MPVN uses both inter-site shared and source C-trees 2116 or not must be known a priori (e.g., via provisioning). 2118 In the scenario where an MVPN customer switches from an C-RP based 2119 tree (RPT) to the shortest path tree (SPT), in order to avoid packet 2120 duplication choosing of a single consistent upstream PE, as described 2121 in [MVPN], may not suffice. To illustrate this consider a set of PEs 2122 {PE2, PE4, PE6} that are on the C-RP tree for (C-*, C-G) and have 2123 chosen a consistent upstream PE, as described in [MVPN], for (C-*, C- 2124 G) state. Further this upstream PE, say PE1, is using an MI-PMSI for 2125 (C-*, C-G). If a site attached to one of these PEs, say PE2, switches 2126 to the C-S tree for (C-S, C-G), PE2 generates a Source Tree Join C- 2127 multicast route towards the upstream PE that is on the path to C-S, 2128 say PE3. PE3 also uses the MI-PMSI for (C-S, C-G), as PE1 uses for 2129 (C-*, C-G). This results in {PE2, PE4, PE6} receiving duplicate 2130 traffic for (C-S, C-G) - both on the C-RP tree (from PE1) and C-S 2131 tree (from PE3). If it is desirable to suppress receiving duplicate 2132 traffic then it is necessary to choose a single forwarder PE for (C- 2133 S, C-G). The following describes how this is achieved. 2135 13.1. Source Within a Site - Source Active Advertisement 2137 Whenever as a result of receiving a Source Tree Join C-multicast 2138 route for (C-S, C-G) from some other PE the local PE adds either the 2139 S-PMSI or I-PMSI to the outgoing interface list of the (C-S, C-G) 2140 state (see Section 11.3.1.1 "Receiving Source Tree Join C-multicast 2141 route"), the local PE MUST originate a Source Active A-D route if the 2142 PE has not originated such route already. The route carries a single 2143 MCAST-VPN NLRI constructed as follows: 2145 + The RD in this NLRI is set to the RD of the VRF of the MVPN on 2146 the PE. 2148 + The Multicast Source field MUST be set to C-S. The Multicast 2149 Source Length field is set appropriately to reflect this. 2151 + The Multicast Group field MUST be set to C-G. The Multicast Group 2152 Length field is set appropriately to reflect this. 2154 The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the 2155 IP address that the PE places in the Global Administrator field of 2156 the VRF Route Import extended community of the VPN-IP routes 2157 advertised by the PE from the MVPN's VRF. 2159 The route SHOULD carry the same set of Route Targets as the Intra-AS 2160 I-PMSI A-D route of the MVPN originated by the PE. 2162 Using the normal BGP procedures the Source Active A-D route is 2163 propagated to all the PEs of the MVPN. 2165 Note that the advertisement of a Source Active A-D route for a given 2166 (C-S, C-G) could be combined, if desired, with the advertisement of 2167 an S-PMSI A-D route for the same (C-S, C-G) This is accomplished by 2168 using the same BGP Update message to carry both the NLRI of the S- 2169 PMSI A-D route and the NLRI of the Source Active A-D route. 2171 Note that even if the originating PE advertises both the Source 2172 Active A-D route and the S-PMSI A-D route in the same BGP Update 2173 message, an implementation can not assume that all other PEs will 2174 receive both of these routes in the same Update message. 2176 Whenever as a result of receiving a withdrawal of the previousely 2177 advertise Source Tree Join C-multicast route for (C-S, C-G), the PE 2178 is going to remove the S-PMSI/I-PMSI from the outgoing interface list 2179 of the (C-S, C-G) state, the local PE MUST also withdraw the Source 2180 Active A-D route for (C-S, C-G), if such a route has been advertised. 2182 Note that if the PE is also acting as a C-RP, but inter-site shared 2183 trees are being used, the reception of a PIM Register message by the 2184 PE does not result in the origination of a Source Active A-D route. 2186 13.2. Receiving Source Active A-D route 2188 When a PE receives a new Source Active A-D route from some other PE, 2189 the PE finds a VRF whose import Route Targets match one or more of 2190 the Route Targets carried by the route. If the match is found, then 2191 the PE updates the VRF with the received route. 2193 We say that a given (C-S, C-G) Source Active A-D route stored in a 2194 given VRF on a PE matches a given (C-*, C-G) entry present in the 2195 MVPN-TIB associated with the VRF if C-G carried by the route is the 2196 same as C-G of the entry, and the PE originates a Shared Tree Join C- 2197 multicast route for the same C-G as C-G of the entry. 2199 When (as a result of receiving PIM messages from one of its CEs) a PE 2200 creates in one of its MVPN-TIBs a (new) (C-*, C-G) entry with a non- 2201 empty outgoing interface list that contains one or more PE-CE 2202 interfaces, the PE MUST check if it has any matching Source Active A- 2203 D routes. If there is one or more such matching route, such that the 2204 PE does not have (C-S, C-G) state in its MVPN-TIB for (C-S, C-G) 2205 carried in the route, then the PE selects one of them (using the BGP 2206 route selection procedures), and sets up its forwarding path to 2207 receive (C-S, C-G) traffic from the tunnel the originator of the 2208 selected Source Active A-D route uses for sending (C-S, C-G). 2210 When as a result of receiving a new Source Active A-D route a PE 2211 updates its VRF with the route, the PE MUST check if the newly 2212 received route matches any (C-*, C-G) entries. If (a) there is a 2213 matching entry, (b) the PE does not have (C-S, C-G) state in its 2214 MVPN-TIB for (C-S, C-G) carried in the route, and (c) the received 2215 route is selected as the best(using the BGP route selection 2216 procedures), then the PE sets up its forwarding path to receive (C-S, 2217 C-G) traffic from the tunnel the originator of the selected Source 2218 Active A-D route uses for sending (C-S, C-G). 2220 Note that if the PE is also acting as a C-RP, and inter-site shared 2221 trees are being used, the BGP Source Active A-D routes do not replace 2222 the MSDP or PIM-based Anycast RP peerings among C-RPs that would be 2223 needed to disseminate source discovery information among C-RPs. 2225 13.2.1. Pruning Sources off the Shared Tree 2227 In addition to the procedures in the previous section, a PE applies 2228 the following procedure when importing a Source Active A-D route for 2229 (C-S,C-G) into a VRF. 2231 The PE finds an (C-*, C-G) entry in the MVPN-TIB whose C-G is the 2232 same as C-G carried in the Multicast Group field of the Source Active 2233 A-D route. 2235 If the outgoing interface list (oif) for the found (C-*, C-G) entry 2236 in the MVPN-TIB on the PE contains either I-PMSI or S-PMSI, and the 2237 PE does not originate the Source Tree Join C-multicast route for (C- 2238 S, C-G) (where C-S is address carried in the Multicast Source field, 2239 and C-G is the address carried in the Multicast Group field of the 2240 received Source Active A-D route), then the PE MUST transition the 2241 (C-S, C-G, rpt) downstream state machine on I-PMSI/S-PMSI to the 2242 Prune state. [Conceptually the C-PIM state machine on the PE will act 2243 "as if" it had received Prune (C-S, C-G,Rpt) on I-PMSI/S-PMSI, 2244 without actually having received one.] Depending on the (C-S,C-G,rpt) 2245 state of the PE-CE interfaces, this may result in the PE using PIM 2246 procedures to prune C-S off the (C-*,C-G) tree. 2248 Transitioning the state machine to the Prune state SHOULD be done 2249 after a delay that is controlled by a timer. The value of the timer 2250 MUST be configurable. The purpose of this timer is to ensure that C-S 2251 is not pruned off the shared tree until all PEs have had time to 2252 receive the Source Active A-D route for (C-S, C-G). 2254 Note that before C-S is prune off the shared tree, there is a 2255 possibility to have (C-S,C-G) packets be sent at the same time on the 2256 PMSI by distinct PEs. This would result in a transient unnecessary 2257 traffic on the provider backbone. However, no duplicates will reach 2258 customer hosts subscribed to C-G as long as the downstream PEs apply 2259 procedures described in section 9.1 of [MVPN]. 2261 The PE MUST keep the (C-S, C-G, rpt) downstream state machine on I- 2262 PMSI/S-PMSI in the Prune state for as long as (a) the outgoing 2263 interface list (oif) for the found (C-*, C-G) entry in the MVPN-TIB 2264 on the PE contains either I-PMSI or S-PMSI, and (b) the PE has at 2265 least one Source Active A-D route for (C-S, C-G), and (c) the PE does 2266 not originate the Source Tree Join C-multicast route for (C-S, C-G). 2267 Once either of these conditions become no longer valid, the PE MUST 2268 transition the (C-S, C-G, rpt) downstream state machine on I-PMSI/S- 2269 PMSI to the NoInfo state. 2271 Note that changing the state on the downstream state machine on I- 2272 PMSI/S-PMSI, as described above, does not imply exchanging PIM 2273 messages over I-PMSI/S-PMSI. 2275 Note also, that except for the scenario described in the third 2276 paragraph of this section, in all other scenarios relying solely on 2277 PIM procedures on the PE is sufficient to ensure the correct behavior 2278 when pruning sources off the shared tree. 2280 14. Supporting PIM-SM without Inter-Site Shared C-trees 2282 The procedures defined in this section only apply when the C- 2283 multicast routing protocol is PIM [RFC4601], moreover only apply for 2284 the multicast ASM mode, and MUST NOT be applied to Multicast Group 2285 addresses belonging to the SSM range. The procedures also MUST NOT be 2286 applied when the C-multicast routing protocol is BIDIR-PIM [RFC5015]. 2288 The procedures of this section are applicable only to MVPNs that do 2289 not use inter-site shared (i.e., rooted at a C-RP) C-trees. 2291 These procedures are not applicable to MVPNs that use both shared and 2292 shortest path inter-site C-trees. See section "Switching from Shared 2293 C-trees to Source C-trees" for the procedures applicable to that 2294 scenario. 2296 Whether a given MPVN uses inter-site shared C-trees or not must be 2297 known a priori (e.g., via provisioning). 2299 14.1. Discovering Active Multicast Sources 2301 A PE can obtain information about active multicast sources within a 2302 given MVPN in a variety of ways. One way is for the PE to act as a 2303 fully functional customer RP (C-RP) for that MVPN. Another way is to 2304 use PIM Anycast RP procedures [PIM-ANYCAST-RP] to convey information 2305 about active multicast sources from one or more of the MVPN C-RPs to 2306 the PE. Yet another way is to use MSDP [MSDP] to convey information 2307 about active multicast sources from the MVPN C-RPs to the PE. 2309 When a PE using any of the above methods first learns of a new 2310 (multicast) source within that MVPN, the PE constructs a Source 2311 Active A-D route, and sends this route to all other PEs that have one 2312 or more sites of that MVPN connected to them. The route carries a 2313 single MCAST-VPN NLRI constructed as follows: 2315 + The RD in this NLRI is set to the RD of the VRF of the MVPN on 2316 the PE. 2318 + The Multicast Source field MUST be set to the source IP address 2319 of the multicast data packet carried in the PIM-Register message 2320 (RP/PIM register case) or of the MSDP Source-Active message (MSDP 2321 case). The Multicast Source Length field is set appropriately to 2322 reflect this. 2324 + The Multicast Group field MUST be set to the group IP address of 2325 the multicast data packet carried in the PIM-Register message 2326 (RP/PIM register case) or of the MSDP Source-Active message (MSDP 2327 case). The Multicast Group Length field is set appropriately to 2328 reflect this. 2330 The Next Hop field of the MP_REACH_NLRI attribute MUST be set to the 2331 IP address that the PE places in the Global Administrator field of 2332 the VRF Route Import extended community of the VPN-IP routes 2333 advertised by the PE. 2335 The route SHOULD carry the same set of Route Targets as the Intra-AS 2336 I-PMSI A-D route of the MVPN originated by the PE. 2338 Using the normal BGP procedures the Source Active A-D route is 2339 propagated to all the PEs of the MVPN. 2341 When a PE that previously advertised a Source Active A-D route for a 2342 given (multicast) source learns that the source is no longer active 2343 (the PE learns this by using the same mechanism by which the PE 2344 learned that the source was active), the PE SHOULD withdraw the 2345 previously advertised Source Active route. 2347 14.2. Receiver(s) Within a Site 2349 A PE follows the procedures specified in Section "Originating C- 2350 multicast routes by a PE", except that the procedures specified in 2351 Section "Originating Shared Tree Join C-multicast route" are replaced 2352 with the procedures specified in this Section below. 2354 When a PE receives a new Source Active A-D route, the PE finds a VRF 2355 whose import Route Targets match one or more of the Route Targets 2356 carried by the route. If the match is found, then the PE updates the 2357 VRF with the received route. 2359 We say that a given (C-S, C-G) Source Active A-D route stored in a 2360 given VRF matches a given (C-*, C-G) entry present in the MVPN-TIB 2361 associated with the VRF if C-G carried by the route is the same as C- 2362 G of the entry. 2364 When (as a result of receiving PIM messages from one of its CEs) a PE 2365 creates in one of its MVPN-TIBs a (new) (C-*, C-G) entry with a non- 2366 empty outgoing interface list that contains one or more PE-CE 2367 interfaces, the PE MUST check if it has any matching Source Active A- 2368 D routes. If there is one or more such matching routes, and the best 2369 path to C-S carried in the matching route(s) is reachable through 2370 some other PE, then for each such route the PE MUST originate a 2371 Source Tree Join C-multicast route. If there is one or more such 2372 matching routes, and the best path to C-S carried in the matching 2373 route(s) is reachable through a CE connected to the PE, then for each 2374 such route the PE MUST originate a PIM Join (C-S, C-G) towards the 2375 CE. 2377 When as a result of receiving a new Source Active A-D route a PE 2378 updates its VRF with the route, the PE MUST check if the newly 2379 received route matches any (C-*, C-G) entries. If there is a matching 2380 entry, and the best path to C-S carried in the (A-D) route is 2381 reachable through some other PE, the PE MUST originate a Source Tree 2382 Join C-multicast route for the (C-S, C-G) carried by the route. If 2383 there is a matching entry, and the best path to C-S carried in the 2384 (A-D) route is reachable through a CE connected to the PE, the PE 2385 MUST originate a PIM Join (C-S, C-G) towards the CE. 2387 Construction and distribution of the Source Tree Join C-multicast 2388 route follows the procedures specified in Section "Originating Source 2389 Tree Join C-multicast route", except that the Multicast Source 2390 Length, Multicast Source, Multicast Group Length, and Multicast Group 2391 fields in the MCAST-VPN NLRI of the Source Tree Join C-multicast 2392 route are copied from the corresponding field in the Source Active A- 2393 D route. 2395 A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C- 2396 G) if, as a result of having received PIM messages from one of its 2397 CEs, the PE creates a Prune (C-S, C-G, RPT-bit) upstream state in one 2398 of its MVPN-TIBs, but has no (C-S, C-G) Joined state in that MVPN- 2399 TIB, and had previously advertised the said route. (This is even if 2400 the VRF associated with the MVPN-TIB still has a (C-S, C-G) Source 2401 Active A-D route). 2403 A PE MUST withdraw a Source Tree Join C-multicast route for (C-S, C- 2404 G) if the Source Active A-D route that triggered the advertisement of 2405 the C-multicast route is withdrawn. 2407 When a PE deletes the (C-*, C-G) state (e.g., due to to receiving PIM 2408 Prune (C-*, C-G) from its CEs), the PE MUST withdraw all the Source 2409 Tree Join C-multicast routes for C-G that have been advertised by the 2410 PE, except for the routes for which the PE still maintains the 2411 corresponding (C-S, C-G) state. 2413 Even though PIM is used as a C-multicast protocol, procedures 2414 described in Section "Originating Shared Tree Join C-multicast route" 2415 do not apply here, as only the Source Tree Join C-multicast routes 2416 are exchanged among PEs. 2418 14.3. Receiving C-multicast routes by a PE 2420 In this model the only valid type of a C-multicast route that a PE 2421 could receive is a Source Tree Join C-multicast route. Processing of 2422 such a route follows the procedures specified in Section "Receiving 2423 Source Tree Join C-multicast route". 2425 15. Carrier's Carrier 2427 A way to support the Carrier's Carrier model is provided by using 2428 mLDP as the CE-PE multicast routing and label distribution protocol, 2429 as specified in this document. 2431 To improve scalability it is RECOMMENDED that for the Carrier's 2432 Carrier scenario within an AS all the S-PMSIs of a given MVPN be 2433 aggregated into a single P-Multicast tree (by using upstream assigned 2434 labels). 2436 16. Scalability Considerations 2438 A PE should use Route Target Constrain [RT-CONSTRAIN] to advertise 2439 the Route Targets that the PE uses for the VRF Route Imports extended 2440 community (note that doing this requires just a single Route Target 2441 Constraint advertisement by the PE). This allows each C-multicast 2442 route to reach only the relevant PE, rather than all the PEs 2443 participating the an MVPN. 2445 To keep the intra-AS membership/binding information within the AS of 2446 the advertising router the BGP Update message originated by the 2447 advertising router SHOULD carry the NO_EXPORT Community ([RFC1997]). 2449 An Inter-AS I-PMSI A-D route originated by an ASBR aggregates Intra- 2450 AS I-PMSI A-D routes originated within the ASBR's own AS. Thus while 2451 the Intra-AS I-PMSI A-D routes originated within an AS are at the 2452 granularity of within that AS, outside of that AS the 2453 (aggregated) Inter-AS I-PMSI A-D routes are at the granularity of 2454 . An Inter-AS I-PMSI A-D route for a given 2455 indicates the presence of or or more sites of the MVPN connected to 2456 the PEs of the AS. 2458 For a given inter-AS tunnel each of its intra-AS segments could be 2459 constructed by its own mechanism. Moreover, by using upstream 2460 assigned labels within a given AS multiple intra-AS segments of 2461 different inter-AS tunnels of either the same or different MVPNs may 2462 share the same P-Multicast tree. 2464 Since (aggregated) Inter-AS I-PMSI A-D routes may have granularity of 2465 , an MVPN that is present in N ASes would have total of N 2466 inter-AS tunnels. Thus for a given MVPN the number of inter-AS 2467 tunnels is independent of the number of PEs that have this MVPN. 2469 Within each Autonomous System BGP Route reflectors can be partitioned 2470 among MVPNs present in that Autonomous System so that each partition 2471 carries routes for only a subset of the MVPNs supported by the 2472 Service Provider. Thus no single Route Reflector is required to 2473 maintain routes for all MVPNs. Moreover, Route Reflectors used for 2474 MVPN do not have to be used for VPN-IP routes (although they may be 2475 used for VPN-IP routes as well). 2477 As described in Section "C-multicast routes aggregation", C-multicast 2478 routes for a given (S,G) of a given MVPN originated by PEs that are 2479 clients of a given Route Reflector are aggregated by the Route 2480 Reflector. Therefore, even if within a Route Reflector cluster there 2481 are multiple C-multicast routes for a given (S,G) of a given MVPN, 2482 outside of the cluster all these routes are aggregated into a single 2483 C-multicast route. Additional aggregation of C-multicast routes 2484 occurs at ASBRs, where an ASBR aggregates all the received C- 2485 multicast routes for a given (S,G) of a given MVPN into a single C- 2486 multicast route. Moreover, both Route Reflectors and ASBRs maintain 2487 C-multicast routes only in the control plane, but not in the data 2488 plane. 2490 16.1. Dampening C-multicast routes 2492 The rate of C-multicast routing changes advertised by a PE is not 2493 necessarily directly proportional to the rate of multicast routing 2494 changes within the MVPN sites connected to the PE, as after the first 2495 (C-S,C-G) Join originated within a site, all the subsequent Joins for 2496 same (C-S,C-G) originated within the sites of the same MVPN connected 2497 to the PE do not cause origination of new C-multicast routes by the 2498 PE. 2500 Depending on how multicast VPN is engineered, dynamic addition and 2501 removal of P2MP RSVP-TE leaves through advertisement/withdrawal of 2502 Leaf A-D routes, will happen. Dampening techniques can be used to 2503 limit corresponding processing. 2505 To lessen the control plane overhead associated with processing of C- 2506 multicast routes, this document proposes OPTIONAL route dampening 2507 procedures similar to what is described in RFC2439. The following 2508 OPTIONAL procedures can be enabled on a PE, ASBR, or BGP Route 2509 Reflector advertising or receiving C-multicast routes. 2511 16.1.1. Dampening withdrawals of C-multicast routes 2513 A PE/ASBR/Route Reflector can OPTIONALLY delay the advertisement of 2514 withdrawals of C-multicast routes. An implementation SHOULD provide 2515 the ability to control the delay via a configurable timer, possibly 2516 with some backoff algorithm to adapt the delay to multicast routing 2517 activity. 2519 Dampening of withdrawals of C-multicast routes does not impede the 2520 multicast join latency observed by MVPN customers, and also does not 2521 impede the multicast leave latency observed by a CE, as multicast 2522 forwarding from the VRF will stop as soon as C-multicast state is 2523 removed in the VRF. 2525 The potential drawbacks of dampening of withdrawals of C-multicast 2526 routes are: 2528 + Until the withdrawals are actually sent, multicast traffic for 2529 the C-multicast routes in question will be continued to be 2530 transmitted to the PE, which will just have to discard it. Note 2531 that the PE may receive useless (multicast) traffic anyway, 2532 irrespective of dampening of withdrawals of C-multicast routes 2533 due to the use of I-PMSIs. 2535 + Any state in the upstream PEs that would be removed as a result 2536 of processing the withdrawals will remain until the withdrawals 2537 are sent. 2539 Discussion on whether the potential drawbacks mentioned above are of 2540 any practical significance is outside the scope of this document. 2542 16.1.2. Dampening Source/Shared Tree Join C-multicast routes 2544 A PE/ASBR/Route Reflector can OPTIONALLY delay the advertisement of 2545 Source/Shared Tree Join C-multicast routes. An implementation SHOULD 2546 provide the ability to control the delay via a configurable timer, 2547 possibly with some backoff algorithm to adapt the delay to multicast 2548 routing activity. 2550 Dampening Source/Shared Tree Join C-multicast routes will not impede 2551 multicast join latency observed by a given MVPN, except if the PE 2552 advertising the Source/Shared Tree Join C-multicast route for a 2553 particular C-S/C-RP is the first to do so for all the sites of the 2554 MVPN that share the same upstream PE with respect to the C-S/C-RP. 2556 16.2. Dampening withdrawals of Leaf A-D routes 2558 Similarly to the procedures proposed above for withdrawal of C- 2559 multicast routes, dampening can be applied to the withdrawal of Leaf 2560 A-D routes. 2562 17. Security Considerations 2564 The mechanisms described in this document could re-use the existing 2565 BGP security mechanisms. 2567 A PE router MUST NOT accept from CEs routes with MCAST-VPN SAFI. 2569 If BGP is used as a CE-PE routing protocol, then when PE receives a 2570 route from CE, if this route carries the VRF Route Import extended 2571 community, the PE MUST remove this community from the route before 2572 turning it into a VPN-IP route. Routes that a PE advertises to a CE 2573 MUST NOT carry the VRF Route Import extended community. 2575 It is important to protect the control plane resources within the PE 2576 to prevent any one VPN from hogging excessive resources. This is the 2577 subject of the remainder of the security considerations section. 2579 When C-multicast routing information is exchanged among PEs using 2580 BGP, an implementation SHOULD provide the ability to rate limit BGP 2581 messages used for this exchange. This SHOULD be provided on a per PE, 2582 per MVPN granularity. 2584 An implementation SHOULD provide capabilities to impose an upper 2585 bound on the number of S-PMSI A-D routes, as well as on how 2586 frequently they may be originated. This SHOULD be provided on a per 2587 PE, per MVPN granularity. 2589 In conjunction with the procedures specified in Section "Supporting 2590 PIM-SM without Inter-Site Shared C-trees" an implementation SHOULD 2591 provide capabilities to impose an upper bound on the number of Source 2592 Active A-D routes, as well as on how frequently they may be 2593 originated. This SHOULD be provided on a per PE, per MVPN 2594 granularity. 2596 In conjunction with the procedures specified in Section "Switching 2597 from Shared C-tree to Source C-tree" limiting the amount of (C-S,C-G) 2598 state would limit the amount of Source Active A-D route, as in the 2599 context of this section Source Active A-D routes are created in 2600 response to Source Tree Join C-multicast routes, and Source Tree Join 2601 C-multicast routes are created as a result of creation of (C-S, C-G) 2602 state on PEs. However, to provide an extra level of robustness in the 2603 context of these procedures an implementation MAY provide 2604 capabilities to impose an upper bound on the number of Source Active 2605 A-D routes, as well as on how frequently they may be originated. 2606 This MAY be provided on a per PE, per MVPN granularity. 2608 Section "Dampening withdrawals of C-multicast routes" describes 2609 optional procedures for dampening withdrawals of C-multicast routes. 2610 It is RECOMMENDED that an implementation supports such procedures. 2612 Section "Dampening withdrawals of Leaf A-D routes" describes optional 2613 procedures for dampening withdrawals of Leaf A-D routes. It is 2614 RECOMMENDED that an implementation supports such procedures. 2616 18. IANA Considerations 2618 This document defines a new BGP Extended Community called Source AS. 2619 This community is 2-octet AS specific, of an extended type, and is 2620 transitive. 2622 This document defines a new BGP Extended Community called VRF Route 2623 Import. This community is IP address specific, of an extended type, 2624 and is transitive. 2626 This document defines a new NLRI, called MCAST-VPN, to be carried in 2627 BGP using multiprotocol extensions. It requires assignment of a new 2628 SAFI. 2630 This document defines a new BGP optional transitive attribute, called 2631 PMSI Tunnel. 2633 19. Acknowledgement 2635 Some of the text in Section "Supporting PIM-SM without Inter-Site 2636 Shared C-trees" has been taken almost verbatim from RFC3618. We would 2637 like to thank Chaitanya Kodeboniya for helpful discussions. We would 2638 also like to thank members of the L3VPN IETF Working Group for 2639 insightful comments and review. 2641 20. Authors' Addresses 2643 Rahul Aggarwal 2644 Juniper Networks 2645 1194 North Mathilda Ave. 2646 Sunnyvale, CA 94089 2647 Email: rahul@juniper.net 2649 Eric C. Rosen 2650 Cisco Systems, Inc. 2651 1414 Massachusetts Avenue 2652 Boxborough, MA, 01719 2653 E-mail: erosen@cisco.com 2655 Thomas Morin 2656 France Telecom R & D 2657 2, avenue Pierre-Marzin 2658 22307 Lannion Cedex 2659 France 2660 Email: thomas.morin@francetelecom.com 2662 Yakov Rekhter 2663 Juniper Networks 2664 1194 North Mathilda Ave. 2665 Sunnyvale, CA 94089 2666 Email: yakov@juniper.net 2668 21. References 2670 21.1. Normative References 2672 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace 2674 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP 2675 VPNs", draft-ietf-l3vpn-2547bis-mcast 2677 [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", 2678 RFC1997, August 1996. 2680 [RFC2119] "Key words for use in RFCs to Indicate Requirement 2681 Levels.", Bradner, RFC2119, March 1997. 2683 [RFC4271] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 2684 4 (BGP-4)", RFC 4271, January 2006 2686 [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 2687 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 2689 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 2690 Communities Attribute", RFC 4360, February 2006. 2692 [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks 2693 (VPNs)", RFC4364, February 2006 2695 [RFC4601] B. Fenner et. al., "Protocol Independent Multicast - Sparse 2696 Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2697 2006 2699 [RFC4659] J. De Clercq et. al., "BGP-MPLS IP Virtual Private Network 2700 (VPN) Extension for IPv6 VPN", RFC 4659, September 2006 2702 21.2. Informative References 2704 [RFC5331] R. Aggrwal, Y. Rekhter, E. Rosen, " MPLS Upstream Label 2705 Assignment and Context Specific Label Space", RFC 5331, August 2008 2707 [RT-CONSTRAIN] P. Marques et. al., "Constrained Route Distribution 2708 for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 2709 Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, 2710 November 2006 2712 [mLDP] I. Minei et. al., "Label Distribution Protocol Extensions for 2713 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 2714 Paths", draft-ietf-mpls-ldp-p2mp 2716 [RFC4607] H. Holbrook, B. Cain "Source-Specific Multicast for IP", 2717 RFC 4607, August 2006 2719 [RFC5015] M. Handley et. al., "Bidirectional Protocol Independent 2720 Multicast (BIDIR-PIM)", RFC5015, October 2007 2722 [RFC4875] R. Aggarwal et. al., "Extensions to RSVP-TE for Point-to- 2723 Multipoint TE LSPs", RFC 4875, May 2007 2725 [PIM-ANYCAST-RP] D. Farinacci, Y. Cai, "Anycast-RP using PIM" RFC 2726 4610, August 2006 2728 [MSDP] B. Fenner, D. Meyer, "Multicast Source Discovery Protocol 2729 (MSDP)", RFC3618, October 2003