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