idnits 2.17.1 draft-ietf-l3vpn-mvpn-pe-ce-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 05, 2013) is 3827 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) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group K. Patel 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track Y. Rekhter 5 Expires: April 08, 2014 Juniper Networks 6 E. Rosen 7 Cisco Systems 8 October 05, 2013 10 BGP as an MVPN PE-CE Protocol 11 draft-ietf-l3vpn-mvpn-pe-ce-00 13 Abstract 15 When a Service Provider offers BGP/MPLS IP VPN service to its 16 customers, RFCs 6513 and 6514 describe protocols and procedures that 17 the Service Provider can use in order to carry the customer's IP 18 multicast traffic from one customer site to others. BGP can be used 19 to carry customer multicast routing information from one Provider 20 Edge (PE) router to another, but it is assumed that PIM is running on 21 the interface between a Customer Edge (CE) router and a PE router. 22 This document specifies protocols and procedures that, under certain 23 conditions, allow customer multicast routing information to carried 24 between PE and CE via BGP. This can eliminate the need to run PIM on 25 the PE-CE interfaces, potentially eliminating the need to run PIM on 26 the PE routers at all. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 08, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. C-MCAST SAFI NLRI Format . . . . . . . . . . . . . . . . . . 4 76 2.1. C-MCAST Join and Prune Routes . . . . . . . . . . . . . . 5 77 3. Exchanging C-MCAST Join Routes . . . . . . . . . . . . . . . 7 78 3.1. Originating C-MCAST Join Route at the CE router . . . . . 7 79 3.2. Receiving a C-MCAST Join Route by the CE Router . . . . . 8 80 3.3. Originating a C-MCAST Join Route at the PE Router . . . . 9 81 3.4. Receiving a C-MCAST Join Route by the PE Router . . . . . 10 82 4. Pruning Sources off the Shared Tree . . . . . . . . . . . . . 11 83 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 8.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 When a Service Provider offers BGP/MPLS IP VPN service to its 94 customers, [RFC6513] and [RFC6514] describe protocols and procedures 95 that the Service Provider can use in order to carry the customer's IP 96 multicast traffic from one customer site to others. BGP can be used 97 to carry customer multicast routing information from one Provider 98 Edge (PE) router to another, but it is assumed that PIM is running on 99 the interface between a Customer Edge (CE) router and a PE router. 100 This document specifies protocols and procedures that under certain 101 conditions, allow customer multicast routing information to carried 102 between PE and CE via BGP. This can eliminate the need to run PIM on 103 the PE-CE interfaces, potentially eliminating the need to run PIM on 104 the PE routers at all. It is however assumed that PIM is the 105 multicast routing protocol running at the customer sites. 107 This document defines a new SAFI known as Customer-Multicast 108 (C-MCAST) SAFI. This SAFI is used to carry customer multicast 109 routing information from CE to PE (and vice versa). The use of this 110 SAFI is only defined when the AFI is either IPv4 or IPv6. The 111 procedures of this document are applicable only if BGP is being used 112 as the PE-PE control protocol for carrying customer multicast 113 routing. It is presupposed that if these procedures are being used 114 on any interface of a given VRF, then PIM is NOT enabled on that 115 interface or on any other VRF interface of that same VRF. It is also 116 assumed that if a CE is using BGP C-MCAST on its interface to one PE, 117 then it is using BGP C-MCAST on its interfaces to all the PEs to 118 which it is connected, and that PIM is not enabled on any of these 119 interfaces. 121 Throughout this document, we will use the terms "MCAST-VPN route" and 122 "C-MCAST route" to mean routes that have the corresponding SAFI. 124 This document assumes that a CE and a PE exchange C-MCAST routes over 125 a direct BGP session (i.e., the C-MCAST routes do not pass through a 126 route reflector or other third party on their way from CE to PE, or 127 vice versa). 129 The NLRI format of a C-MCAST route is modeled on the NLRI format of 130 the MCAST-VPN SAFI, as defined in [RFC6514]. However, since the 131 C-MCAST routes are always exchanged in the context of a particular 132 VPN, Route Distinguishers (RDs) are not used. Also, C-MCAST routes 133 are never distributed from one PE to another. 135 Where the procedures of this document require a PE or a CE to 136 determine the upstream neighbor for a particular multicast (*,G) or 137 (S,G) state, the upstream neighbor is determined using the procedures 138 of [RFC4601], rather than the procedures of [RFC6513] or [RFC6514]. 139 That is, the upstream neighbor selected for a particular (*,G) or 140 (S,G) is the same as it would be if PIM were being used between the 141 PE and CE. This includes support for non-congruent multicast 142 topologies. The upstream neighbor address determined through these 143 procedures MUST be the same address that the upstream neighbor puts 144 in the next hop field of BGP Updates that it sends to the 145 "downstream" PE or CE. Note that neither the VRF Route Import 146 Extended Community nor the Source AS Extended Community, defined in 147 [RFC6514], are used. 149 When following the procedures of this document, customer IP multicast 150 traffic is sent natively from CE to PE, and vice versa. There is no 151 encapsulation or tunneling of the multicast traffic. Therefore there 152 is no need for C-MCAST routes corresponding to the I-PMSI A-D routes 153 or S-PMSI A-D routes or [RFC6514]. Similarly, there is no need for 154 the PMSI Tunnel attribute of [RFC6514]. 156 This document does not provide a mechanism corresponding to the "PIM 157 Assert" mechanism of [RFC4601]. It is assumed either that the PE-CE 158 interfaces are point-to-point interfaces, or else that the multicast 159 procedures in the PE and CE can determine, by examination of the 160 layer 2 headers, the node from which a given multicast data packet 161 was received. 163 Support for "Dense Mode Multicast" (PIM-DM) is outside the scope of 164 this document. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 2. C-MCAST SAFI NLRI Format 172 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 173 from multiple different "AFI/SAFIs". This document defines a new a 174 new SAFI known as a C-MCAST SAFI with a value to be assigned by the 175 IANA. This SAFI is used along with the AFI of IPv4 (1) or IPv6 (2). 177 The C-MCAST NLRI defined below is carried in the BGP UPDATE messages 178 [RFC4271] using the BGP multiprotocol extensions [RFC4760] with a AFI 179 of IPv4 (1) or IPv6 (2) assigned by IANA and a C-MCAST SAFI with a 180 value to be assigned by the IANA. 182 The Next hop field of MP_REACH_NLRI attribute SHALL be interpreted as 183 an IPv4 adress whenever the length of the Next Hop address is 4 184 octets, and as an IPv6 address whenever the length of the Next Hop is 185 address is 16 octets. 187 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 188 with a maximum length of 12 octers for IPv4 AFI and 36 octets for 189 IPv6 AFI. The following is the format of the C-MCAST NLRI: 191 +-----------------------------------+ 192 | Route Type (1 octet) | 193 +-----------------------------------+ 194 | Length (1 octet) | 195 +-----------------------------------+ 196 | Route Type specific (variable) | 197 +-----------------------------------+ 199 The Route Type field defines encoding of the rest of the C-MCAST 200 NLRI. (Route Type specific C-MCAST NLRI). 202 The Length field indicates the length in octets of the Route Type 203 specific field of C-MCAST NLRI. 205 This document defines the following Route Types: 207 1 - Shared Tree Join Route 208 2 - Source Tree Join Route 209 4 - Source Prune A-D Route 211 The encodings and procedures for these route types are described in 212 the subsequent sections. The NLRI encodings are modeled after those 213 of [RFC6514], in order to facilitate implementation in generation of 214 MCAST-VPN routes. 216 In order for two BGP speakers to exchange C-MCAST NLRI, they must use 217 BGP Capabilities Advertisement [RFC5492] to ensure that they both are 218 capable of properly processing the C-MCAST NLRI. This is done as 219 specified in [RFC4760], by using a capability code 1 (multiprotocol 220 BGP) with an AFI of IPv4 (1) or IPv6 (2) and a SAFI of C-MCAST with a 221 value to be assigned by IANA. 223 2.1. C-MCAST Join and Prune Routes 225 The "route type specific" part of the C-MCAST NLRI is the same for 226 the Shared Tree Join, Source Tree Join, and Source Prune A-D Route 227 Types. 229 +-----------------------------------+ 230 | Multicast Source Length (1 octet) | 231 +-----------------------------------+ 232 | Multicast Source (variable) | 233 +-----------------------------------+ 234 | Multicast Group Length (1 octet) | 235 +-----------------------------------+ 236 | Multicast Group (variable) | 237 +-----------------------------------+ 239 The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI that 240 carries the C-MCAST NLRI determines whether the multicast source and 241 multicast group addresses fields are IPv4 addresses (AFI 1) or IPv6 242 addresses (AFI 2). The length field of IPv4 source and group 243 addresses is 32 bits and the length field of IPv6 addresses is 128 244 bits. 246 Use of other values of the Multicast Source Length and Multicast 247 Group Length fields is outside the scope of this document. If other 248 values occur, or if the NLRI length is not as expected, given the AFI 249 value, the NLRI should be considered to be malformed. An 250 implementation SHOULD treat such an UPDATE as though the NLRI has 251 been withdrawn, SHOULD log an error. 253 In a Source Tree Join route, the Multicast Source field and the 254 Multicast Group field identify an (S,G) multicast flow, where the IP 255 address of S appears in the Multicast Source field and the IP address 256 of G appears in the Multicast Group field. 258 In a Shared Tree Join route, the Multicast Source field contains the 259 Rendezvous Point (RP) address that is associated, at the originator 260 of the UPDATE, with the multicast group whose address appears in the 261 Multicast Group field. 263 In the Source Prune route, the Multicast Source field contains the 264 address of a source that is to be pruned from the shared tree 265 associated with the multicast group whose address appears in the 266 Multicast Group field. 268 Usage of C-MCAST Join routes is described in Section 3. Usage of 269 C-MCAST Source Prune routes is described in Section 4. 271 3. Exchanging C-MCAST Join Routes 273 Multiast Routing Information is exchanged between a CE router and a 274 PE a router using C-MCAST NLRIs. If the procedures of this draft are 275 followed, the CE router and the PE router MUST NOT exchange PIM 276 messages with each other. The C-MCAST routes are originated and 277 propagated as follows. 279 3.1. Originating C-MCAST Join Route at the CE router 281 Whenever a) PIM instance on a particular CE router creates a new 282 (S,G) or (*,G) state and b) the selected upstream neighbor address 283 for that state is a PE router to which the CE router is directly 284 connected and with which the CE has a BGP session on whch the C-MCAST 285 SAFI is enabled, then the CE router MUST originate a C-MCAST Source 286 Tree Join route or a C-MCAST Shared Tree Join route. The CE router 287 uses the procedures of [RFC4601] to determine the upstream neighbor 288 (also called the "RPF neighbor"). Note that, unlike [RFC6513], the 289 upstream nexthop selection procedures defined in this document are 290 not based on the VRF Route Import Extended community [RFC6513]. 292 The Route Type field of the NLRI is set to "Source Tree Join" if the 293 corresponding state is (S,G), and to "Shared Tree Join" if the 294 corresponding state is (*,G). 296 The Multicast Source field of the NLRI of a C-MCAST Source Tree Join 297 route MUST be set to the source address of the corresponding (S,G). 298 The Multicast Source field of the NLRI of a C-MCAST Shared Tree Join 299 route MUST be set to the address of the RP that is mapped to the 300 corresponding (*,G) state. 302 The Multicast Group field of the NLRI of either kind of C-MCAST Join 303 route MUST be set to the multicast group address of the (S,G) or 304 (*,G) state. 306 The CE router MUST put its own IP address in the Next Hop field of 307 either type of C-MCAST Join route. 309 The CE router MUST attach a particular RT to the C-MCAST Join route. 310 This RT MUST be either an IP Address Specific RT or an IPv6 Address 311 Specific RT, depending upon whether the address of the upstream 312 neighbor is an IPv4 address or an IPv6 address. In either case, the 313 address of the upstream neighbor is placed in the Global 314 Administrator field of the RT, and the Local Administrator field is 315 set to 0. (Compare to the "C-multicast Import RT" described in 316 section 7 of [RFC6514].) The "address of the upstream neighbor" MUST 317 be the address that the upstream neighbor puts in the Next Hop field 318 of BGP UPDATEs that it sends to the CE router. 320 The CE MUST send the C-MCAST Join route on the BGP session to the PE 321 that it has selected as the upstream neighbor for the (*,G) or (S,G) 322 identified in the NLRI of the route. Although not required for 323 correctness, it is RECOMMENDED that the C-MCAST Join not be sent on 324 other BGP sessions. How this distribution constraint is met is a 325 local matter. Policy based filtering based on the RT is one possible 326 way to meet the constraint. Use of [RFC4684] is another. 328 The C-MCAST Shared Tree Join is used to join the shared tree of an 329 "Any Source Multicast" (ASM) group. The C-MCAST Source Tree Join is 330 used in both ASM mode and in "Single Source Multicast" (SSM) mode to 331 join a source tree. The C-MCAST Shared Tree Join can be used to join 332 a BIDIR-PIM [RFC5015] multicast group, as long as the interface 333 between the PE and the CE is a point-to-point interface. 335 If a PIM instance on a particular CE router deletes its (S,G) or a 336 (*,G) entry, and if there is a currently originated corresponding 337 C-MCAST Join route, then that route MUST be withdrawn. The C-MCAST 338 route is withdrawn using the MP_UNREACH_NLRI attribute. If the 339 upstream neighbor of a (S,G) or (*,G) route changes, and if there is 340 a currently originated corresponding C-MCAST Join route, then the RT 341 MUST be changed to identify the new upstream neighbor, and the route 342 MUST be advertised on the BGP session to that neighbor. 344 3.2. Receiving a C-MCAST Join Route by the CE Router 346 When a CE router receives a C-MCAST route from its PE router, it 347 checks to see if the route carries an IP Address Specific Route 348 Target Extended Community whose Global Administrator field contains 349 the address that the CE puts in the Next Hop field of the BGP UPDATEs 350 it sends to the PE router. If there is no such Route Target, the 351 received route does not impact the CE's multicast state. Otherwise, 352 the received route is used to create or modify the corresponding 353 (S,G) or (*,G) state in the multicast forwarding information base 354 (FIB). The CE-to-PE interface is stored in the outgoing interface 355 list of the corresponding (S,G) or a (*,G) state. If the C-MCAST 356 route is received with the Route Type of Shared Tree Join, then the 357 CE router attaches RP address to the corresponding (*,G) state. 359 If the CE router is connected to the multiple PE routers, it is 360 possible that it will receive C-MCAST routes with the same NLRI from 361 multiple PE routers. In this case, the CE router adds multiple CE- 362 to-PE interfaces to its outgoing interface list, one for each PE 363 router from which the given route was received. (Note that a 364 particular CE-to-PE interface is added only if the route from the 365 corresponding PE identifies the CE in its IP Address Specific RT.) 366 When the last C-MCAST route for a given (S,G) or a (*,G) is 367 withdrawn, resulting in a state where BGP C-MCAST SAFI has no route 368 for a given (S,G) or a (*,G) state, the CE router MUST remove all the 369 interfaces learnt via BGP from the outgoing interface list. If this 370 results in an empty outgoing interface list then the CE router using 371 PIM procedures MUST prune itself off the corresponding (S,G) or a 372 (*,G) tree. 374 3.3. Originating a C-MCAST Join Route at the PE Router 376 The C-MCAST routes on a PE router are originated in BGP as a result 377 of updates in the (C-S,C-G) or (C-*,C-G) state in the associated VRF 378 of a PE router. These states are created by BGP routes learnt from 379 other PEs via the BGP MCAST-VPN SAFI [RFC6514], or from CEs via the 380 C-MCAST SAFI. Whenever a) a particular VRF on a particular PE router 381 creates a new (C-S,C-G) or a (C-*,C-G) state, b) the selected 382 upstream neighbor address identifies a CE, and c) the PE has a direct 383 BGP session to the CE, on which C-MCAST SAFI is enabled, then the PE 384 router MUST originate a C-MCAST Join route from the given VRF. The 385 PE router finds the upstream neighbor address based on the procedures 386 of [RFC6513]. 388 The Route Type field of the NLRI is set to "Source Tree Join" if the 389 corresponding state is (S,G), and to "Shared Tree Join" if the 390 corresponding state is (*,G). 392 The Multicast Source field of the NLRI of a C-MCAST Source Tree Join 393 route MUST be set to the source address of the corresponding (S,G). 394 The multicast source address field of the NLRI of a C-MCAST Shared 395 Tree Join route MUST be set to the address of the RP that is mapped 396 to the corresponding (*,G) state. 398 The Multicast Group field of the NLRI of either kind of C-MCAST Join 399 route MUST be set to the multicast group address of the (S,G) or 400 (*,G) state. 402 The PE router must put its own IP address in the Next Hop field of 403 the C-MCAST Join route. 405 The PE router MUST attach a particular RT to the C-MCAST Join route. 406 This RT MUST be either an IP Address Specific RT or an IPv6 Address 407 Specific RT, depending upon whether the address of the upstream 408 neighbor is an IPv4 address or an IPv6 address. In either case, the 409 address of the upstream neighbor is placed in the Global 410 Administrator field of the RT, and the Local Administrator field is 411 set to 0. (Compare to the "C-multicast Import RT" described in 412 section 7 of [RFC6514].) The "address of the upstream neighbor" MUST 413 be the address that the upstream neighbor puts in the Next Hop field 414 of BGP UPDATEs that it sends to the PE router. 416 The PE MUST send the C-MCAST Join route on the BGP session to the CE 417 that it has selected as the upstream neighbor for the (*,G) or (S,G) 418 identified in the NLRI of the route. Although not required for 419 correctness, it is RECOMMENDED that the C-MCAST Join not be sent on 420 other BGP sessions. How this distribution constraint is met is a 421 local matter. Policy based filtering based on the RT is one possible 422 way to meet the constraint. Use of [RFC4684] is another. Of course, 423 a C-MCAST route originated by a particular PE is originated in the 424 context of a particular VRF, and MUST NOT be advertised to a 425 particular CE unless the interface between that PE and that CE is 426 associated with that VRF. 428 The C-MCAST Shared Tree Join is used to join the shared tree of an 429 "Any Source Multicast" (ASM) group. The C-MCAST Source Tree Join is 430 used in both ASM mode and in "Single Source Multicast" (SSM) mode to 431 join a source tree. The C-MCAST Shared Tree Join can be used to join 432 a BIDIR-PIM [RFC5015] multicast group, as long as the interface 433 between the PE and the CE is a point-to-point interface. 435 If a PE router deletes its (S,G) or a (*,G) entry in the context of a 436 particular VRF, and if there is a currently originated corresponding 437 C-MCAST Join route from that VRF, then that route MUST be withdrawn. 438 The C-MCAST route is withdrawn using the MP_UNREACH_NLRI attribute. 439 If the upstream neighbor of a (S,G) or (*,G) route changes, and if 440 there is a currently originated corresponding C-MCAST Join route, 441 then the RT MUST be changed to identify the new upstream neighbor. 443 3.4. Receiving a C-MCAST Join Route by the PE Router 445 When a PE router receives a C-MCAST Join route from a CE router, it 446 checks to see if the route carries an IP Address Specific Route 447 Target Extended Community whose Global Administrator field contains 448 the address that the PE puts in the Next Hop field of the BGP UPDATEs 449 it sends to the CE router. If there is no such Route Target, the 450 received route does not impact the PE's multicast state. Otherwise, 451 the received route is used to create or modify the corresponding 452 (S,G) or (*,G) state in the MVPN-TIB ([RFC6514]). The PE-to-CE 453 interface is stored in the outgoing interface list of the 454 corresponding (S,G) or a (*,G) state. If the C-MCAST route is 455 received with the Route Type of Shared Tree Join, then the CE router 456 attaches RP address to the corresponding (*,G) state. 458 If the PE router is connected to the multiple CE routers, it is 459 possible that it will receive C-MCAST routes with the same NLRI from 460 multiple CE routers. In this case, the PE router adds multiple PE- 461 to-CE interfaces to its outgoing interface list, one for each CE 462 router from which the given route was received. (Note that a 463 particular PE-to-CE interface is added only if the route from the 464 corresponding CE identifies the PE in its IP Address Specific RT.) 466 When the last C-MCAST route for a given (S,G) or a (*,G) is 467 withdrawn, resulting in a state where BGP C-MCAST SAFI has no route 468 for a given (S,G) or a (*,G) state, the withdrawal of the route has 469 the (S,G) or a (*,G) prune semantics. The corresponding MCAST-VPN 470 route is withdrawn using the MP_UNREACH_NLRI attribute. 472 4. Pruning Sources off the Shared Tree 474 Suppose a router, say R1, has originated a C-MCAST Source Tree Join 475 A-D route for (*,G), and has identified another router, say R2, in 476 that route's RT. Under certain conditions, R1 may need to prune a 477 particular source, say S1, off the (*,G) tree. To do so, R1 478 originates a C-MCAST Prune Source A-D route whose NLRI contains S1 in 479 the multicast source field and G in the multicast group field. This 480 route MUST have the same IP Address Specific RT (identifying R2), and 481 the same Next Hop field, as the corresponding C-MCAST Source Tree 482 Join A-D route. This route MUST be sent on the BGP session to R2. 483 It is RECOMMENDED that it not be sent on other BGP sessions. Note 484 that either R1 is a CE and R2 is a PE, or vice versa. The procedures 485 are the same in either case. When R1 no longer needs to prune S1 486 from the (*,G) tree, R1 MUST withdraw the (S1,G) Source Prune route. 487 If R1 changes the RT on the (*,G) Shared Tree Join route, it MUST 488 change the RT on all the corresponding (S,G) Source Prune routes. If 489 R1 withdraws the (*,G) Shared Tree Join route, it MUST also withdraw 490 all the corresponding (S,G) Source Prune routes. When a router 491 withdraws a Source Tree Join route for (*,G), it MUST withdraw all 492 its Source Prune (S,G) routes. A received Source Prune (S,G) route 493 does not impact a router's multicast state unless there is a the 494 router has also received a Shared Tree Join (*,G) route over the same 495 BGP session. However, a router should handle the case where one or 496 more Source Prune routes are received before the corresponding Shared 497 Tree Join route. Further details will be provided in future 498 revisions of this document. 500 5. Acknowledgements 502 The authors would like to thank ..... for his review and comments. 504 6. IANA Considerations 506 This document define a new SAFI called "C-MCAST SAFI". IANA is 507 requested to allocate a code point for C-MCAST SAFI. 509 7. Security Considerations 511 This extension to BGP does not change the underlying security issues 512 inherent in the existing [RFC4271] and [RFC6514]. 514 8. References 516 8.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 522 Protocol 4 (BGP-4)", RFC 4271, January 2006. 524 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 525 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 526 Protocol Specification (Revised)", RFC 4601, August 2006. 528 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 529 "Multiprotocol Extensions for BGP-4", RFC 4760, January 530 2007. 532 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 533 "Bidirectional Protocol Independent Multicast (BIDIR- 534 PIM)", RFC 5015, October 2007. 536 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 537 with BGP-4", RFC 5492, February 2009. 539 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 540 VPNs", RFC 6513, February 2012. 542 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 543 Encodings and Procedures for Multicast in MPLS/BGP IP 544 VPNs", RFC 6514, February 2012. 546 8.2. Informative References 548 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 549 R., Patel, K., and J. Guichard, "Constrained Route 550 Distribution for Border Gateway Protocol/MultiProtocol 551 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 552 Private Networks (VPNs)", RFC 4684, November 2006. 554 Authors' Addresses 556 Keyur Patel 557 Cisco Systems 558 170 W. Tasman Drive 559 San Jose, CA 95134 560 USA 562 Email: keyupate@cisco.com 564 Yakov Rekhter 565 Juniper Networks 566 1194 North Mathilda Avenue 567 Sunnyvale, CA 94089 568 USA 570 Email: yakov@juniper.net 572 Eric Rosen 573 Cisco Systems 574 1414 Massachusetts Avenue 575 Boxborough, MA 01719 576 USA 578 Email: erosen@cisco.com