idnits 2.17.1 draft-ietf-bess-mvpn-pe-ce-01.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 5, 2015) is 3126 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 E. Rosen 5 Expires: April 7, 2016 Juniper Networks 6 Y. Rekhter 7 October 5, 2015 9 BGP as an MVPN PE-CE Protocol 10 draft-ietf-bess-mvpn-pe-ce-01 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 7, 2016. 44 Copyright Notice 46 Copyright (c) 2015 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 7.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 When a Service Provider offers BGP/MPLS IP VPN service to its 80 customers, [RFC6513] and [RFC6514] describe protocols and procedures 81 that the Service Provider can use in order to carry the customer's IP 82 multicast traffic from one customer site to others. BGP can be used 83 to carry customer multicast routing information from one Provider 84 Edge (PE) router to another, but it is assumed that PIM is running on 85 the interface between a Customer Edge (CE) router and a PE router. 86 This document specifies protocols and procedures that under certain 87 conditions, allow customer multicast routing information to carried 88 between PE and CE via BGP. This can eliminate the need to run PIM on 89 the PE-CE interfaces, potentially eliminating the need to run PIM on 90 the PE routers at all. It is however assumed that PIM is the 91 multicast routing protocol running at the customer sites. 93 This document defines a new SAFI known as Customer-Multicast 94 (C-MCAST) SAFI. This SAFI is used to carry customer multicast 95 routing information from CE to PE (and vice versa). The use of this 96 SAFI is only defined when the AFI is either IPv4 or IPv6. The 97 procedures of this document are applicable only if BGP is being used 98 as the PE-PE control protocol for carrying customer multicast 99 routing. It is presupposed that if these procedures are being used 100 on any interface of a given VRF, then PIM is NOT enabled on that 101 interface or on any other VRF interface of that same VRF. It is also 102 assumed that if a CE is using BGP C-MCAST on its interface to one PE, 103 then it is using BGP C-MCAST on its interfaces to all the PEs to 104 which it is connected, and that PIM is not enabled on any of these 105 interfaces. 107 Throughout this document, we will use the terms "MCAST-VPN route" and 108 "C-MCAST route" to mean routes that have the corresponding SAFI. 110 This document assumes that a CE and a PE exchange C-MCAST routes over 111 a direct BGP session (i.e., the C-MCAST routes do not pass through a 112 route reflector or other third party on their way from CE to PE, or 113 vice versa). 115 The NLRI format of a C-MCAST route is modeled on the NLRI format of 116 the MCAST-VPN SAFI, as defined in [RFC6514]. However, since the 117 C-MCAST routes are always exchanged in the context of a particular 118 VPN, Route Distinguishers (RDs) are not used. Also, C-MCAST routes 119 are never distributed from one PE to another. 121 Where the procedures of this document require a PE or a CE to 122 determine the upstream neighbor for a particular multicast (*,G) or 123 (S,G) state, the upstream neighbor is determined using the procedures 124 of [RFC4601], rather than the procedures of [RFC6513] or [RFC6514]. 126 That is, the upstream neighbor selected for a particular (*,G) or 127 (S,G) is the same as it would be if PIM were being used between the 128 PE and CE. This includes support for non-congruent multicast 129 topologies. The upstream neighbor address determined through these 130 procedures MUST be the same address that the upstream neighbor puts 131 in the next hop field of BGP Updates that it sends to the 132 "downstream" PE or CE. Note that neither the VRF Route Import 133 Extended Community nor the Source AS Extended Community, defined in 134 [RFC6514], are used. 136 When following the procedures of this document, customer IP multicast 137 traffic is sent natively from CE to PE, and vice versa. There is no 138 encapsulation or tunneling of the multicast traffic. Therefore there 139 is no need for C-MCAST routes corresponding to the I-PMSI A-D routes 140 or S-PMSI A-D routes or [RFC6514]. Similarly, there is no need for 141 the PMSI Tunnel attribute of [RFC6514]. 143 This document does not provide a mechanism corresponding to the "PIM 144 Assert" mechanism of [RFC4601]. It is assumed either that the PE-CE 145 interfaces are point-to-point interfaces, or else that the multicast 146 procedures in the PE and CE can determine, by examination of the 147 layer 2 headers, the node from which a given multicast data packet 148 was received. 150 Support for "Dense Mode Multicast" (PIM-DM) is outside the scope of 151 this document. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. C-MCAST SAFI NLRI Format 159 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 160 from multiple different "AFI/SAFIs". This document defines a new a 161 new SAFI known as a C-MCAST SAFI with a value to be assigned by the 162 IANA. This SAFI is used along with the AFI of IPv4 (1) or IPv6 (2). 164 The C-MCAST NLRI defined below is carried in the BGP UPDATE messages 165 [RFC4271] using the BGP multiprotocol extensions [RFC4760] with a AFI 166 of IPv4 (1) or IPv6 (2) assigned by IANA and a C-MCAST SAFI with a 167 value to be assigned by the IANA. 169 The Next hop field of MP_REACH_NLRI attribute SHALL be interpreted as 170 an IPv4 adress whenever the length of the Next Hop address is 4 171 octets, and as an IPv6 address whenever the length of the Next Hop is 172 address is 16 octets. 174 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 175 with a maximum length of 12 octers for IPv4 AFI and 36 octets for 176 IPv6 AFI. The following is the format of the C-MCAST NLRI: 178 +-----------------------------------+ 179 | Route Type (1 octet) | 180 +-----------------------------------+ 181 | Length (1 octet) | 182 +-----------------------------------+ 183 | Route Type specific (variable) | 184 +-----------------------------------+ 186 Figure 1 188 The Route Type field defines encoding of the rest of the C-MCAST 189 NLRI. (Route Type specific C-MCAST NLRI). 191 The Length field indicates the length in octets of the Route Type 192 specific field of C-MCAST NLRI. 194 This document defines the following Route Types: 196 1 - Shared Tree Join Route 198 2 - Source Tree Join Route 200 4 - Source Prune A-D Route 202 The encodings and procedures for these route types are described in 203 the subsequent sections. The NLRI encodings are modeled after those 204 of [RFC6514], in order to facilitate implementation in generation of 205 MCAST-VPN routes. 207 In order for two BGP speakers to exchange C-MCAST NLRI, they must use 208 BGP Capabilities Advertisement [RFC5492] to ensure that they both are 209 capable of properly processing the C-MCAST NLRI. This is done as 210 specified in [RFC4760], by using a capability code 1 (multiprotocol 211 BGP) with an AFI of IPv4 (1) or IPv6 (2) and a SAFI of C-MCAST with a 212 value to be assigned by IANA. 214 2.1. C-MCAST Join and Prune Routes 216 The "route type specific" part of the C-MCAST NLRI is the same for 217 the Shared Tree Join, Source Tree Join, and Source Prune A-D Route 218 Types. 220 +-----------------------------------+ 221 | Multicast Source Length (1 octet) | 222 +-----------------------------------+ 223 | Multicast Source (variable) | 224 +-----------------------------------+ 225 | Multicast Group Length (1 octet) | 226 +-----------------------------------+ 227 | Multicast Group (variable) | 228 +-----------------------------------+ 230 Figure 2 232 The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI that 233 carries the C-MCAST NLRI determines whether the multicast source and 234 multicast group addresses fields are IPv4 addresses (AFI 1) or IPv6 235 addresses (AFI 2). The length field of IPv4 source and group 236 addresses is 32 bits and the length field of IPv6 addresses is 128 237 bits. 239 Use of other values of the Multicast Source Length and Multicast 240 Group Length fields is outside the scope of this document. If other 241 values occur, or if the NLRI length is not as expected, given the AFI 242 value, the NLRI should be considered to be malformed. An 243 implementation SHOULD treat such an UPDATE as though the NLRI has 244 been withdrawn, SHOULD log an error. 246 In a Source Tree Join route, the Multicast Source field and the 247 Multicast Group field identify an (S,G) multicast flow, where the IP 248 address of S appears in the Multicast Source field and the IP address 249 of G appears in the Multicast Group field. 251 In a Shared Tree Join route, the Multicast Source field contains the 252 Rendezvous Point (RP) address that is associated, at the originator 253 of the UPDATE, with the multicast group whose address appears in the 254 Multicast Group field. 256 In the Source Prune route, the Multicast Source field contains the 257 address of a source that is to be pruned from the shared tree 258 associated with the multicast group whose address appears in the 259 Multicast Group field. 261 Usage of C-MCAST Join routes is described in Section 3. Usage of 262 C-MCAST Source Prune routes is described in Section 4. 264 3. Exchanging C-MCAST Join Routes 266 Multicast Routing Information is exchanged between a CE router and a 267 PE a router using C-MCAST NLRIs. If the procedures of this draft are 268 followed, the CE router and the PE router MUST NOT exchange PIM 269 messages with each other. The C-MCAST routes are originated and 270 propagated as follows. 272 3.1. Originating C-MCAST Join Route at the CE router 274 Whenever a) PIM instance on a particular CE router creates a new 275 (S,G) or (*,G) state and b) the selected upstream neighbor address 276 for that state is a PE router to which the CE router is directly 277 connected and with which the CE has a BGP session on whch the C-MCAST 278 SAFI is enabled, then the CE router MUST originate a C-MCAST Source 279 Tree Join route or a C-MCAST Shared Tree Join route. The CE router 280 uses the procedures of [RFC4601] to determine the upstream neighbor 281 (also called the "RPF neighbor"). Note that, unlike [RFC6513], the 282 upstream nexthop selection procedures defined in this document are 283 not based on the VRF Route Import Extended community [RFC6513]. 285 The Route Type field of the NLRI is set to "Source Tree Join" if the 286 corresponding state is (S,G), and to "Shared Tree Join" if the 287 corresponding state is (*,G). 289 The Multicast Source field of the NLRI of a C-MCAST Source Tree Join 290 route MUST be set to the source address of the corresponding (S,G). 291 The Multicast Source field of the NLRI of a C-MCAST Shared Tree Join 292 route MUST be set to the address of the RP that is mapped to the 293 corresponding (*,G) state. 295 The Multicast Group field of the NLRI of either kind of C-MCAST Join 296 route MUST be set to the multicast group address of the (S,G) or 297 (*,G) state. 299 The CE router MUST put its own IP address in the Next Hop field of 300 either type of C-MCAST Join route. 302 The CE router MUST attach a particular RT to the C-MCAST Join route. 303 This RT MUST be either an IP Address Specific RT or an IPv6 Address 304 Specific RT, depending upon whether the address of the upstream 305 neighbor is an IPv4 address or an IPv6 address. In either case, the 306 address of the upstream neighbor is placed in the Global 307 Administrator field of the RT, and the Local Administrator field is 308 set to 0. (Compare to the "C-multicast Import RT" described in 309 section 7 of [RFC6514].) The "address of the upstream neighbor" MUST 310 be the address that the upstream neighbor puts in the Next Hop field 311 of BGP UPDATEs that it sends to the CE router. 313 The CE MUST send the C-MCAST Join route on the BGP session to the PE 314 that it has selected as the upstream neighbor for the (*,G) or (S,G) 315 identified in the NLRI of the route. Although not required for 316 correctness, it is RECOMMENDED that the C-MCAST Join not be sent on 317 other BGP sessions. How this distribution constraint is met is a 318 local matter. Policy based filtering based on the RT is one possible 319 way to meet the constraint. Use of [RFC4684] is another. 321 The C-MCAST Shared Tree Join is used to join the shared tree of an 322 "Any Source Multicast" (ASM) group. The C-MCAST Source Tree Join is 323 used in both ASM mode and in "Single Source Multicast" (SSM) mode to 324 join a source tree. The C-MCAST Shared Tree Join can be used to join 325 a BIDIR-PIM [RFC5015] multicast group, as long as the interface 326 between the PE and the CE is a point-to-point interface. 328 If a PIM instance on a particular CE router deletes its (S,G) or a 329 (*,G) entry, and if there is a currently originated corresponding 330 C-MCAST Join route, then that route MUST be withdrawn. The C-MCAST 331 route is withdrawn using the MP_UNREACH_NLRI attribute. If the 332 upstream neighbor of a (S,G) or (*,G) route changes, and if there is 333 a currently originated corresponding C-MCAST Join route, then the RT 334 MUST be changed to identify the new upstream neighbor, and the route 335 MUST be advertised on the BGP session to that neighbor. 337 3.2. Receiving a C-MCAST Join Route by the CE Router 339 When a CE router receives a C-MCAST route from its PE router, it 340 checks to see if the route carries an IP Address Specific Route 341 Target Extended Community whose Global Administrator field contains 342 the address that the CE puts in the Next Hop field of the BGP UPDATEs 343 it sends to the PE router. If there is no such Route Target, the 344 received route does not impact the CE's multicast state. Otherwise, 345 the received route is used to create or modify the corresponding 346 (S,G) or (*,G) state in the multicast forwarding information base 347 (FIB). The CE-to-PE interface is stored in the outgoing interface 348 list of the corresponding (S,G) or a (*,G) state. If the C-MCAST 349 route is received with the Route Type of Shared Tree Join, then the 350 CE router attaches RP address to the corresponding (*,G) state. 352 If the CE router is connected to the multiple PE routers, it is 353 possible that it will receive C-MCAST routes with the same NLRI from 354 multiple PE routers. In this case, the CE router adds multiple CE- 355 to-PE interfaces to its outgoing interface list, one for each PE 356 router from which the given route was received. (Note that a 357 particular CE-to-PE interface is added only if the route from the 358 corresponding PE identifies the CE in its IP Address Specific RT.) 360 When the last C-MCAST route for a given (S,G) or a (*,G) is 361 withdrawn, resulting in a state where BGP C-MCAST SAFI has no route 362 for a given (S,G) or a (*,G) state, the CE router MUST remove all the 363 interfaces learnt via BGP from the outgoing interface list. If this 364 results in an empty outgoing interface list then the CE router using 365 PIM procedures MUST prune itself off the corresponding (S,G) or a 366 (*,G) tree. 368 3.3. Originating a C-MCAST Join Route at the PE Router 370 The C-MCAST routes on a PE router are originated in BGP as a result 371 of updates in the (C-S,C-G) or (C-*,C-G) state in the associated VRF 372 of a PE router. These states are created by BGP routes learnt from 373 other PEs via the BGP MCAST-VPN SAFI [RFC6514], or from CEs via the 374 C-MCAST SAFI. Whenever a) a particular VRF on a particular PE router 375 creates a new (C-S,C-G) or a (C-*,C-G) state, b) the selected 376 upstream neighbor address identifies a CE, and c) the PE has a direct 377 BGP session to the CE, on which C-MCAST SAFI is enabled, then the PE 378 router MUST originate a C-MCAST Join route from the given VRF. The 379 PE router finds the upstream neighbor address based on the procedures 380 of [RFC6513]. 382 The Route Type field of the NLRI is set to "Source Tree Join" if the 383 corresponding state is (S,G), and to "Shared Tree Join" if the 384 corresponding state is (*,G). 386 The Multicast Source field of the NLRI of a C-MCAST Source Tree Join 387 route MUST be set to the source address of the corresponding (S,G). 388 The multicast source address field of the NLRI of a C-MCAST Shared 389 Tree Join route MUST be set to the address of the RP that is mapped 390 to the corresponding (*,G) state. 392 The Multicast Group field of the NLRI of either kind of C-MCAST Join 393 route MUST be set to the multicast group address of the (S,G) or 394 (*,G) state. 396 The PE router must put its own IP address in the Next Hop field of 397 the C-MCAST Join route. 399 The PE router MUST attach a particular RT to the C-MCAST Join route. 400 This RT MUST be either an IP Address Specific RT or an IPv6 Address 401 Specific RT, depending upon whether the address of the upstream 402 neighbor is an IPv4 address or an IPv6 address. In either case, the 403 address of the upstream neighbor is placed in the Global 404 Administrator field of the RT, and the Local Administrator field is 405 set to 0. (Compare to the "C-multicast Import RT" described in 406 section 7 of [RFC6514].) The "address of the upstream neighbor" MUST 407 be the address that the upstream neighbor puts in the Next Hop field 408 of BGP UPDATEs that it sends to the PE router. 410 The PE MUST send the C-MCAST Join route on the BGP session to the CE 411 that it has selected as the upstream neighbor for the (*,G) or (S,G) 412 identified in the NLRI of the route. Although not required for 413 correctness, it is RECOMMENDED that the C-MCAST Join not be sent on 414 other BGP sessions. How this distribution constraint is met is a 415 local matter. Policy based filtering based on the RT is one possible 416 way to meet the constraint. Use of [RFC4684] is another. Of course, 417 a C-MCAST route originated by a particular PE is originated in the 418 context of a particular VRF, and MUST NOT be advertised to a 419 particular CE unless the interface between that PE and that CE is 420 associated with that VRF. 422 The C-MCAST Shared Tree Join is used to join the shared tree of an 423 "Any Source Multicast" (ASM) group. The C-MCAST Source Tree Join is 424 used in both ASM mode and in "Single Source Multicast" (SSM) mode to 425 join a source tree. The C-MCAST Shared Tree Join can be used to join 426 a BIDIR-PIM [RFC5015] multicast group, as long as the interface 427 between the PE and the CE is a point-to-point interface. 429 If a PE router deletes its (S,G) or a (*,G) entry in the context of a 430 particular VRF, and if there is a currently originated corresponding 431 C-MCAST Join route from that VRF, then that route MUST be withdrawn. 432 The C-MCAST route is withdrawn using the MP_UNREACH_NLRI attribute. 433 If the upstream neighbor of a (S,G) or (*,G) route changes, and if 434 there is a currently originated corresponding C-MCAST Join route, 435 then the RT MUST be changed to identify the new upstream neighbor. 437 3.4. Receiving a C-MCAST Join Route by the PE Router 439 When a PE router receives a C-MCAST Join route from a CE router, it 440 checks to see if the route carries an IP Address Specific Route 441 Target Extended Community whose Global Administrator field contains 442 the address that the PE puts in the Next Hop field of the BGP UPDATEs 443 it sends to the CE router. If there is no such Route Target, the 444 received route does not impact the PE's multicast state. Otherwise, 445 the received route is used to create or modify the corresponding 446 (S,G) or (*,G) state in the MVPN-TIB ([RFC6514]). The PE-to-CE 447 interface is stored in the outgoing interface list of the 448 corresponding (S,G) or a (*,G) state. If the C-MCAST route is 449 received with the Route Type of Shared Tree Join, then the CE router 450 attaches RP address to the corresponding (*,G) state. 452 If the PE router is connected to the multiple CE routers, it is 453 possible that it will receive C-MCAST routes with the same NLRI from 454 multiple CE routers. In this case, the PE router adds multiple PE- 455 to-CE interfaces to its outgoing interface list, one for each CE 456 router from which the given route was received. (Note that a 457 particular PE-to-CE interface is added only if the route from the 458 corresponding CE identifies the PE in its IP Address Specific RT.) 459 When the last C-MCAST route for a given (S,G) or a (*,G) is 460 withdrawn, resulting in a state where BGP C-MCAST SAFI has no route 461 for a given (S,G) or a (*,G) state, the withdrawal of the route has 462 the (S,G) or a (*,G) prune semantics. The corresponding MCAST-VPN 463 route is withdrawn using the MP_UNREACH_NLRI attribute. 465 4. Pruning Sources off the Shared Tree 467 Suppose a router, say R1, has originated a C-MCAST Source Tree Join 468 A-D route for (*,G), and has identified another router, say R2, in 469 that route's RT. Under certain conditions, R1 may need to prune a 470 particular source, say S1, off the (*,G) tree. To do so, R1 471 originates a C-MCAST Prune Source A-D route whose NLRI contains S1 in 472 the multicast source field and G in the multicast group field. This 473 route MUST have the same IP Address Specific RT (identifying R2), and 474 the same Next Hop field, as the corresponding C-MCAST Source Tree 475 Join A-D route. This route MUST be sent on the BGP session to R2. 476 It is RECOMMENDED that it not be sent on other BGP sessions. Note 477 that either R1 is a CE and R2 is a PE, or vice versa. The procedures 478 are the same in either case. When R1 no longer needs to prune S1 479 from the (*,G) tree, R1 MUST withdraw the (S1,G) Source Prune route. 480 If R1 changes the RT on the (*,G) Shared Tree Join route, it MUST 481 change the RT on all the corresponding (S,G) Source Prune routes. If 482 R1 withdraws the (*,G) Shared Tree Join route, it MUST also withdraw 483 all the corresponding (S,G) Source Prune routes. When a router 484 withdraws a Source Tree Join route for (*,G), it MUST withdraw all 485 its Source Prune (S,G) routes. A received Source Prune (S,G) route 486 does not impact a router's multicast state unless there is a the 487 router has also received a Shared Tree Join (*,G) route over the same 488 BGP session. However, a router should handle the case where one or 489 more Source Prune routes are received before the corresponding Shared 490 Tree Join route. Further details will be provided in future 491 revisions of this document. 493 5. IANA Considerations 495 This document define a new SAFI called "C-MCAST SAFI". IANA is 496 requested to allocate a code point for C-MCAST SAFI. 498 6. Security Considerations 500 This extension to BGP does not change the underlying security issues 501 inherent in the existing [RFC4271] and [RFC6514]. 503 7. References 505 7.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 513 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 514 DOI 10.17487/RFC4271, January 2006, 515 . 517 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 518 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 519 Protocol Specification (Revised)", RFC 4601, 520 DOI 10.17487/RFC4601, August 2006, 521 . 523 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 524 "Multiprotocol Extensions for BGP-4", RFC 4760, 525 DOI 10.17487/RFC4760, January 2007, 526 . 528 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 529 "Bidirectional Protocol Independent Multicast (BIDIR- 530 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 531 . 533 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 534 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 535 2009, . 537 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 538 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 539 2012, . 541 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 542 Encodings and Procedures for Multicast in MPLS/BGP IP 543 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 544 . 546 7.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, DOI 10.17487/RFC4684, 553 November 2006, . 555 Authors' Addresses 557 Keyur Patel 558 Cisco Systems 559 170 W. Tasman Drive 560 San Jose, CA 95134 561 USA 563 Email: keyupate@cisco.com 565 Eric C. Rosen 566 Juniper Networks 567 10 Technology Park Drive 568 Westford, MA 01886 569 USA 571 Email: erosen@juniper.net 573 Yakov Rekhter