idnits 2.17.1 draft-ietf-l3vpn-mvpn-wildcards-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 (February 9, 2012) is 4450 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 (ref. 'PIM') (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 L3VPN Working Group Eric C. Rosen (editor) 3 Internet Draft Cisco Systems, Inc. 4 Intended Status: Proposed Standard 5 Expires: August 9, 2012 Yakov Rekhter (editor) 6 Updates RFC 6514 Juniper Networks, Inc. 8 Wim Hendrickx 9 Alcatel-Lucent 11 Ray Qiu 12 Huawei 14 February 9, 2012 16 Wildcards in Multicast VPN Auto-Discovery Routes 18 draft-ietf-l3vpn-mvpn-wildcards-02.txt 20 Abstract 22 In "Multicast Virtual Private Networks" (MVPNs), customer multicast 23 flows are carried in "tunnels" through a service provider's network. 24 The base specifications for MVPN define BGP multicast VPN 25 "auto-discovery routes", and specify how to use an auto-discovery 26 route to advertise the fact that an individual customer multicast 27 flow is being carried in a particular tunnel. However, those 28 specifications do not provide a way to specify, in a single such 29 route, that multiple customer flows are being carried in a single 30 tunnel. Those specifications also do not provide a way to advertise 31 that a particular tunnel is to be used by default to carry all 32 customer flows, except in the case where that tunnel is joined by all 33 the provider edge routers of the MVPN. This document eliminates 34 these restrictions by specifying the use of "wildcard" elements in 35 the customer flow identifiers. With wildcard elements, a single 36 auto-discovery route can refer to multiple customer flows, or even to 37 all customer flows. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt. 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 Copyright and License Notice 62 Copyright (c) 2012 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1 Introduction .......................................... 3 78 1.1 Terminology ........................................... 3 79 1.2 Wildcards in S-PMSI A-D Routes ........................ 5 80 1.3 Use Cases ............................................. 6 81 2 Encoding of Wildcards ................................. 7 82 3 Finding the Matching S-PMSI A-D Route ................. 8 83 3.1 Finding the Match for Data Transmission ............... 9 84 3.2 Finding the Match for Data Receiving .................. 9 85 3.2.1 Finding the Match for (C-S,C-G) ....................... 10 86 3.2.2 Finding the Wildcard Match for (C-*,C-G) .............. 10 87 4 Procedures for S-PMSI A-D Routes with Wildcards ....... 11 88 4.1 Procedures for all Kinds of Wildcards ................. 11 89 4.2 Procedures for (C-*,C-G) S-PMSI A-D Routes ............ 12 90 4.3 Procedures for (C-S,C-*) S-PMSI A-D routes ............ 13 91 4.4 Procedures for (C-*,C-*) S-PMSI A-D Routes ............ 14 92 5 IANA Considerations ................................... 15 93 6 Security Considerations ............................... 15 94 7 Acknowledgments ....................................... 16 95 8 Authors' Addresses .................................... 16 96 9 Normative References .................................. 17 98 1. Introduction 100 1.1. Terminology 102 This document uses terminology from [MVPN], and in particular uses 103 the prefixes "C-" and "P-", as specified in section 3.1 of [MVPN], to 104 distinguish addresses in the "customer address space" from addresses 105 in the "provider address space". The following terminology and 106 acronyms are particularly important in this document: 108 - MVPN 110 Multicast Virtual Private Network, a VPN [L3VPN] in which 111 multicast service is offered. 113 - VRF 115 Virtual Routing and Forwarding table [L3VPN] 117 - SP 119 Service Provider 121 - P-tunnel 123 A tunnel through the network of one or more SPs. 125 - C-S 127 Multicast Source. A multicast source address, in the address 128 space of a customer network. 130 - C-G 132 Multicast Group. A multicast group address (destination 133 address), in the address space of a customer network. 135 - C-multicast flow or C-flow 137 A customer multicast flow. Each C-flow is identified by the 138 ordered pair (source address, group address), where each address 139 is in the customer's address space. The identifier of a 140 particular C-flow is usually written as: (C-S,C-G). 142 - RP 144 A "Rendezvous Point", as defined in [PIM]. 146 - C-RP 148 A rendezvous point whose address is in the customer's address 149 space. 151 - Selective P-tunnel 153 A P-tunnel that is joined only by Provider Edge (PE) routers that 154 need to receive one or more of the C-flows that are traveling 155 through that P-tunnel. 157 - Inclusive P-tunnel 159 A P-tunnel that is joined by all Provider Edge (PE) routers that 160 attach to sites of a given MVPN. 162 - S-PMSI A-D route 164 Selective Provider Multicast Service Interface Auto-Discovery 165 Route. Carried in BGP Update messages, these routes are used to 166 advertise the fact that particular C-flows are bound to (i.e., 167 are traveling through) particular P-tunnels. 169 Familiarity with multicast concepts and terminology [PIM] is also 170 presupposed. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 1.2. Wildcards in S-PMSI A-D Routes 178 As specified in [MVPN] and [MVPN-BGP], an S-PMSI A-D route advertises 179 that a particular C-flow is bound to a particular selective P-tunnel. 181 The identifier of the specified C-flow, e.g., (C-S,C-G), is encoded 182 into the Network Layer Reachability Information (NLRI) of the S-PMSI 183 A-D route. The identifier of the specified P-tunnel is encoded into 184 an attribute (the "PMSI Tunnel Attribute") of the S-PMSI A-D route. 185 Each S-PMSI A-D route thus specifies a single C-flow. To bind 186 multiple C-flows to a single P-tunnel, it is necessary to advertise 187 one S-PMSI A-D route for each C-flow, specifying the same P-tunnel in 188 each such route. 190 This document defines OPTIONAL extensions to the procedures and 191 encodings specified in [MVPN] and [MVPN-BGP]. These extensions enable 192 a single S-PMSI A-D route to advertise that multiple C-multicast 193 flows are bound to a single P-tunnel. 195 The extensions specified in this document are based on the notion of 196 allowing the NLRI of an S-PMSI A-D route to contain a "wildcard". In 197 the NLRI encoding, a wildcard can replace the C-S, the C-G, or both. 198 We use the notation "C-*" to denote a wildcard. The extensions allow 199 the NLRI to encode three kinds of wildcard: (C-*,C-*), (C-S,C-*), and 200 (C-*,C-G). 202 By using wildcards, a PE may be able to reduce the number of S-PMSI 203 A-D routes it originates, thereby improving the scalability of the 204 control plane. There is, however, no impact on data plane 205 scalability, as the number of P-tunnels is not reduced. 207 Encoding and detailed procedures are specified in subsequent sections 208 of this document. 210 1.3. Use Cases 212 There are a number of situations in which it can be useful to use 213 wildcards in the NLRI of an S-PMSI A-D route. 215 - Using a selective P-tunnel as the default tunnel. 217 There are procedures in [MVPN] and [MVPN-BGP] that allow a PE to 218 advertise that it is going to use an inclusive P-tunnel as the 219 P-tunnel on which it will transmit all C-flows by "default". 220 However, those documents do not provide any way for a PE to 221 advertise that it is going to use a selective P-tunnel as the 222 P-tunnel on which it will transmit all C-flows by "default". 223 Using the extensions defined in this document, a PE can advertise 224 that it is going to use a selective P-tunnel as its default 225 P-tunnel. It does so by advertising an S-PMSI A-D route whose 226 NLRI contains (C-*,C-*). 228 - Binding multiple C-flows traveling along a customer's PIM-SM 229 shared tree to a single P-tunnel. 231 A PE router may be connected to an MVPN site that contains a 232 customer RP (C-RP). The C-RP may be the root of one or more 233 shared trees. In multicast terminology, these are known as (*,G) 234 trees. By advertising a single S-PMSI A-D route whose NLRI 235 contains the (C-*,C-G) wildcard, the PE can bind all the C-flows 236 traveling along customer's (*,G) tree to a single P-tunnel. This 237 use case applies only when C-G is a non-bidirectional ASM ("Any 238 Source Multicast") group. 240 - Binding multiple C-flows with the same C-group address to a 241 single P-tunnel, even if each such C-flow is traveling along a 242 customer's PIM source tree. 244 A PE router may be connected to an MVPN site containing several 245 multicast sources that are all sending to a common multicast 246 group, along a customer's PIM source trees. Or the PE may be 247 connected to several sites, each containing at least one source 248 sending to the common multicast group. By advertising a single 249 S-PMSI A-D route whose NLRI contains (C-*,C-G), the PE can bind 250 these C-flows to a single P-tunnel. 252 This use case applies only when the C-group is a non- 253 bidirectional ASM group. 255 - Binding multiple C-flows with the same C-group address to a 256 single P-tunnel, when those C-flows are traveling along a 257 customer's BIDIR-PIM shared tree. 259 This use case applies only when the C-group is a BIDIR-PIM group. 261 - Binding multiple C-flows from a given C-source to a given 262 P-tunnel, irrespective of whether those C-flows all have the same 263 C-group address. 265 This can be useful when the C-group addresses are SSM ("single 266 source multicast") addresses. Suppose for example that a given 267 source transmits multiple "channels" of information, each with 268 its own C-group address. It may be desirable to bind all these 269 channels to a single P-tunnel, without having to advertise an 270 S-PMSI A-D route for each one. 272 Of course, a specific C-flow, (C-S,C-G), can always be assigned 273 individually to a particular P-tunnel by advertising an S-PMSI A-D 274 route whose NLRI contains (C-S,C-G). 276 In the following, we will sometimes speak of an S-PMSI A-D route 277 being "ignored". When we say the route is "ignored", we do not mean 278 that its normal BGP processing is not done, but that the route is not 279 considered when determining which P-tunnel to use when receiving 280 multicast data, and that the MPLS label values it conveys are not 281 used. We will generally use "ignore" in quotes to indicate this 282 meaning. 284 This document provides procedures only for the case where the 285 P-tunnels are "unidirectional", i.e., point-to-multipoint. The use 286 of "bidirectional" (multipoint-to-multipoint) P-tunnels is outside 287 the scope of this document. 289 2. Encoding of Wildcards 291 Per [MVPN-BGP] section 4.3, the MCAST-VPN NLRI in an S-PMSI A-D route 292 is encoded as follows: 294 +-----------------------------------+ 295 | RD (8 octets) | 296 +-----------------------------------+ 297 | Multicast Source Length (1 octet) | 298 +-----------------------------------+ 299 | Multicast Source (Variable) | 300 +-----------------------------------+ 301 | Multicast Group Length (1 octet) | 302 +-----------------------------------+ 303 | Multicast Group (Variable) | 304 +-----------------------------------+ 305 | Originating Router's IP Addr | 306 +-----------------------------------+ 308 where the "source length" and "group length" fields always have a 309 non-zero value. This document specifies that a "zero length" source 310 or group represents the corresponding wildcard. Specifically: 312 - A source wildcard is encoded as a zero-length source field. That 313 is, the "multicast source length" field contains the value 0x00, 314 and the "multicast source" field is omitted. 316 - A group wildcard is encoded as a zero-length group field. That 317 is, the "multicast group length" field contains the value 0x00, 318 and the "multicast group" field is omitted. 320 3. Finding the Matching S-PMSI A-D Route 322 This section gives the precise rules for determining the S-PMSI A-D 323 route that is "matched" by a given (C-S,C-G) or (C-*,C-G). The 324 procedures in section 4 will make use of the matching rules defined 325 in this section. 327 All matching rules assume the context of a given VRF at a given PE. 329 The rules that a PE applies to find the S-PMSI A-D route that matches 330 a (C-S,C-G) C-flow that it needs to transmit are slightly different 331 than the rules it applies to find the S-PMSI A-D route that matches a 332 (C-S,C-G) C-flow that it needs to receive. These rules are specified 333 in sections 3.1 and 3.2 respectively. 335 The S-PMSI A-D route that is matched by a given (C-S,C-G) may change 336 over time, as the result of S-PMSI A-D routes being withdrawn, or as 337 a result of new S-PMSI A-D routes being originated and/or advertised. 338 In particular, if (C-S,C-G) matches an S-PMSI A-D route whose NLRI 339 contains (C-*,C-*), the origination or reception of an S-PMSI A-D 340 route whose NLRI contains (C-S,C-G) may cause (C-S,C-G) to match the 341 latter route instead. Note also that the S-PMSI A-D route that 342 matches a given (C-S,C-G) is independent of the order in which the 343 routes were originated or received. 345 3.1. Finding the Match for Data Transmission 347 Consider a given PE, call it PE1. At any given time, for a given VRF 348 at PE1, there is a (possibly empty) set of S-PMSI A-D routes that PE1 349 has originated and advertised, but not withdrawn. We will refer to 350 these routes as "currently originated" by PE1. Suppose that PE1 351 needs to transmit a particular C-flow (C-S,C-G) to one or more other 352 PEs. We use the following algorithm to find the S-PMSI A-D route 353 that the C-flow "matches": 355 - If there is an S-PMSI A-D route currently originated by PE1, 356 whose NLRI contains (C-S,C-G), the (C-S,C-G) C-flow matches that 357 route. 359 - Otherwise, if there is an S-PMSI A-D route currently originated 360 by PE1, whose NLRI contains (C-S,C-*), AND if C-G is an SSM group 361 address, the (C-S,C-G) C-flow matches that route. 363 - Otherwise, if there is an S-PMSI A-D route currently originated 364 by PE1, whose NLRI contains (C-*,C-G), AND if C-G is an ASM group 365 address, the (C-S,C-G) C-flow matches that route. 367 - Otherwise, if there is an S-PMSI A-D route currently originated 368 by PE1, whose NLRI contains (C-*,C-*), the (C-S,C-G) C-flow 369 matches that route. 371 3.2. Finding the Match for Data Receiving 373 We refer to an S-PMSI A-D route as being "installed" (in a given VRF) 374 if it has been selected by the BGP decision process as the preferred 375 route for its NLRI. 377 An S-PMSI A-D route is considered to be "originated by a given PE" if 378 that PE's IP address is contained in the "Originating Router's IP 379 Address" field in the MCAST-VPN NLRI of the route. 381 3.2.1. Finding the Match for (C-S,C-G) 383 Suppose that a PE router, call it PE1, needs to receive (C-S,C-G), 384 and that PE1 has chosen another PE router, call it PE2, as the 385 "upstream PE" [MVPN] for that flow. 387 - If there is an installed S-PMSI A-D route originated by PE2, 388 whose NLRI contains (C-S,C-G), then (C-S,C-G) matches that route. 390 - Otherwise, if there is an installed S-PMSI A-D route originated 391 by PE2, whose NLRI contains (C-S,C-*), AND if C-G is an SSM 392 multicast group address, then (C-S,C-G) matches that route. 394 - Otherwise, if there is an installed S-PMSI A-D route originated 395 by PE2, whose NLRI contains (C-*,C-G), AND if C-G is an ASM 396 multicast group address, then (C-S,C-G) matches that route. 398 - Otherwise, if there is an installed S-PMSI A-D route originated 399 by PE2, whose NLRI contains (C-*,C-*), then (C-S,C-G) matches 400 that route. 402 3.2.2. Finding the Wildcard Match for (C-*,C-G) 404 Suppose that a PE router, call it PE1, needs to receive (C-*,C-G) 405 traffic. Note that even if (C-*,C-G) matches a non-wildcard S-PMSI A- 406 D route (as detailed in section 12.3 of [MVPN-BGP], it may also match 407 one or more wildcard S-PMSI A-D routes, as specified below. 409 If on PE1 there is an installed S-PMSI A-D route originated by PE2 410 whose NLRI contains (C-*,C-G), then (C-*,C-G) matches this route if 411 one of the following conditions holds: 413 - PE1 determines that PE2 is the "upstream" PE [MVPN] for C-RP of 414 C-G, or 416 - PE1 has installed one or more Source Active A-D routes for C-G 417 originated by PE2, and for at least one of these routes, PE1 does 418 not have a corresponding (C-S,C-G) state, or 420 - C-G is a BIDIR-PIM group, or 422 - Source Active A-D routes are not being used. 424 If (C-*,C-G) does not match a (C-*,C-G) S-PMSI A-D route from PE2, 425 but PE1 has an installed (C-*,C-*) S-PMSI A-D route from PE2, then 426 (C-*,C-G) matches the (C-*,C-*) route if one of the following 427 conditions holds: 429 - PE1 determines that PE2 is the "upstream" PE [MVPN] for C-RP of 430 C-G, or 432 - PE1 has installed one or more Source Active A-D routes for C-G 433 originated by PE2, and for at least one of these routes, PE1 does 434 not have a corresponding (C-S,C-G) state, or 436 - C-G is a BIDIR-PIM group, or 438 - Source Active A-D routes are not being used. 440 4. Procedures for S-PMSI A-D Routes with Wildcards 442 4.1. Procedures for all Kinds of Wildcards 444 This document defines procedures for the following uses of the 445 wildcard in the NLRI of an S-PMSI A-D route: 447 - (C-*,C-G): Source Wildcard, Group specified. 449 - (C-S,C-*): Source specified, Group Wildcard. 451 - (C-*,C-*): Source Wildcard, Group Wildcard. 453 All other wildcard functionality is outside the scope of this 454 document. 456 The ability to originate S-PMSI A-D routes with a particular kind of 457 wild card is OPTIONAL. However, if a PE has the ability to originate 458 S-PMSI A-D routes with a particular kind of wildcard, it MUST have 459 the ability to interpret and correctly process S-PMSI A-D routes with 460 that kind of wildcard, and it SHOULD have the ability to interpret 461 and correctly process all three kinds of wildcard. 463 For a given MVPN, A PE MUST NOT originate S-PMSI A-D routes with a 464 particular kind of wildcard unless it is known a priori that all PEs 465 attached to that MVPN have the ability to interpret and correctly 466 process that kind of wildcard. 468 The criteria for originating and withdrawing S-PMSI A-D routes with 469 wildcards are local to the originating PE. 471 As specified in [MVPN-BGP], an S-PMSI A-D route is carried in the 472 Network Layer Reachability Information (NLRI) field of an 473 MP_REACH_NLRI attribute (see [BGP-MP]). Every S-PMSI A-D route has a 474 particular address family (IPv4 or IPv6), as specified in the Address 475 Family Information AFI field of the MP_REACH_NLRI attribute. A 476 wildcard in a particular S-PMSI A-D route always refers only to 477 multicast flows of that same address family. 479 The procedures specified in this document apply only when the PMSI 480 Tunnel Attribute of an S-PMSI A-D route specifies a "unidirectional" 481 P-tunnel. The use of "bidirectional" P-tunnels (e.g., Multipoint-to- 482 Multipoint Label Switched Paths, BIDIR-PIM trees) is outside the 483 scope of this document. 485 In the following sections, an S-PMSI A-D route whose NLRI contains 486 (C-*,C-G), (C-S,C-*), or (C-*,C-*) will be referred to as a 487 "(C-*,C-G) route", a "(C-S,C-*) route", or a "(C-*,C-*)" route, 488 respectively. 490 4.2. Procedures for (C-*,C-G) S-PMSI A-D Routes 492 This document specifies the use of (C-*,C-G) S-PMSI A-D routes only 493 in the case where C-G is an ASM group address. Use of (C-*,C-G) 494 S-PMSI A-D routes where C-G is an SSM group address is outside the 495 scope of this document. If a PE receives a (C-*,C-G) S-PMSI A-D 496 route, and the PE can determine that C-G is an SSM group address, the 497 PE SHOULD "ignore" this S-PMSI A-D route. 499 By default, the set of Route Targets carried by a (C-*,C-G) S-PMSI A- 500 D route originated by a given VRF is the same as the set of Route 501 Targets carried in the (unicast) VPN-IP routes that originated from 502 that VRF. An implementation MUST allow the set of Route Targets 503 carried by the (C-*,C-G) S-PMSI A-D route to be specified by 504 configuration. In the absence of a configured set of Route Targets, 505 the route MUST carry the default set of Route Targets. 507 If a PE needs to transmit packets of a (C-S,C-G) C-flow, and if 508 (C-S,C-G) matches an (C-*,C-G) S-PMSI A-D route according to the 509 rules of section 3.1, then the PE MUST use the P-tunnel advertised in 510 this route for transmitting that C-flow. (Note that it is impossible 511 for a given (C-S,C-G) to match both a (C-*,C-G) wildcard and a 512 (C-S,C-*) wildcard.) 514 If PIM is being used as the PE-PE control protocol, then if the PE 515 has (C-*,C-G) and/or (C-S,C-G) state that matches (according to the 516 procedures of section 3.2) an S-PMSI A-D route, the PE MUST join the 517 P-tunnel specified in the PMSI Tunnel Attribute of this route. 519 If BGP is being used as the PE-PE control protocol, then: 521 - If a given PE has currently originated a C-multicast Shared Tree 522 Join for (C-*,C-G), and if (C-*,C-G) matches a (C-*,C-G) S-PMSI 523 A-D route, then the PE applies the procedures of section 12.3 524 ("Receiving S-PMSI A-D routes by PEs") of [MVPN-BGP] to that 525 S-PMSI A-D route. 527 - Otherwise (the given PE does not have a currently originated 528 C-multicast Shared Tree Join for (C-*,C-G)), if there are one or 529 more values of C-S for which the PE has a currently originated 530 Source Tree Join C-multicast route for (C-S,C-G), the PE MUST 531 join the tunnels advertised by the S-PMSI A-D routes that match 532 (according to section 3.2) each such (C-S,C-G). 534 - Otherwise the PE "ignores" the route. 536 4.3. Procedures for (C-S,C-*) S-PMSI A-D routes 538 This document covers the use of (C-S,C-*) S-PMSI A-D routes for only 539 the C-multicast flows where C-G is an SSM group address. Use of 540 (C-S,C-*) S-PMSI A-D routes for other C-multicast flows is outside 541 the scope of this document. Specifically, if a PE receives a 542 (C-S,C-*) S-PMSI A-D route, and the PE can determine that C-G is not 543 an SSM group address, the PE SHOULD "ignore" this S-PMSI A-D route. 545 By default the set of Route Targets carried by a (C-S,C-*) S-PMSI A-D 546 route originated by a given VRF is an intersection between the set of 547 Route Targets carried in the Intra-AS I-PMSI A-D route that 548 originated from that VRF, and the set of Route Targets carried by the 549 unicast VPN-IP route to C-S originated from that VRF. An 550 implementation MUST allow the set of Route Targets carried by the 551 (C-S,C-*) S-PMSI A-D route to be specified by configuration. In the 552 absence of a configured set of Route Targets, the route MUST carry 553 the default set of Route Targets. 555 If a PE needs to transmit packets of a (C-S,C-G) C-flow, and if 556 (C-S,C-G) matches a (C-S,C-*) S-PMSI A-D route according to the rules 557 of section 3.1, then the PE MUST use the P-tunnel advertised in this 558 route for transmitting that C-flow. (Note that it is impossible for 559 a given (C-S,C-G) to match both a (C-*,C-G) wildcard and a (C-S,C-*) 560 wildcard.) 562 If PIM is being used as the PE-PE control protocol for distributing 563 C-multicast routing, and if a given PE, needs to receive a (C-S,C-G) 564 flow, and if (C-S,C-G) matches the (C-S,C-*) S-PMSI A-D route 565 (according to the procedures of section 3.2), then the PE MUST join 566 the P-tunnel specified in the PMSI Tunnel Attribute of that route. 568 If BGP is being used as the PE-PE control protocol for distributing 569 C-multicast routing, and if there is some (C-S,C-G) such that (a) the 570 PE has a currently originated (C-S,C-G) Source Tree Join C-multicast 571 route, AND (b) the given (C-S,C-G) matches (according to the 572 procedures of section 3.2) a (C-S,C-*) S-PMSI A-D route, then PE1 573 applies the procedures of section 12.3 ("Receiving S-PMSI A-D routes 574 by PEs") of [MVPN-BGP] to the matching S-PMSI A-D route. 576 4.4. Procedures for (C-*,C-*) S-PMSI A-D Routes 578 (C-*,C-*) S-PMSI A-D routes are used when, for a given MVPN, a PE has 579 a policy not to use an I-PMSI for carrying multicast data traffic 580 originated in the MVPN's site(s) connected to that PE. When the 581 (C-*,C-*) wildcard is used together with BGP C-multicast routing, 582 this results in the "S-PMSI only" model, where no I-PMSIs are used at 583 all for the given MVPN. 585 A (C-*,C-*) S-PMSI A-D route is originated for a given MVPN by a 586 given PE only if that PE has been provisioned with the policy to do 587 so. 589 When so provisioned, the PE MAY originate the (C-*,C-*) S-PMSI A-D 590 route as soon as it is enabled to support the given MVPN. 591 Alternatively, the PE MAY delay originating the route until one of 592 the following conditions holds: 594 - The PE-PE protocol for distributing C-multicast routing is PIM, 595 and for the given MVPN, the PE has some (C-S,C-G) or (C-*,C-G) 596 state for which the upstream interface is one of the VRF 597 interfaces for the given MVPN. 599 - The PE-PE protocol for distributing C-multicast routing is BGP, 600 and the given PE has received and installed either: 602 * a Source Tree Join C-multicast route, with the C-S contained 603 in the route's NLRI being reachable via one of the given 604 MVPN's VRF interfaces, or 606 * a Shared Tree Join C-multicast route, with the C-RP carried 607 in that route being reachable via one of the given MVPN's VRF 608 interfaces. 610 By default, the set of Route Targets carried by a (C-*,C-*) S-PMSI 611 A-D route originated from a given VRF is the same as the set of Route 612 Targets carried in the VPN-IP unicast routes originated from that 613 VRF. An implementation MUST allow the set of Route Targets carried by 614 the (C-*,C-*) S-PMSI A-D route to be specified by configuration. In 615 the absence of a configured set of Route Targets, the route MUST 616 carry the default set of Route Targets, as specified above. 618 If a PE needs to transmit packets of a (C-S,C-G) C-flow, and if 619 (C-S,C-G) matches a (C-*,C-*) S-PMSI A-D route according to the rules 620 of section 3.1, then the PE MUST use the P-tunnel advertised in this 621 route for transmitting that C-flow. (Note that it is impossible for 622 a given (C-S,C-G) to match both a (C-*,C-*) wildcard and any other 623 wildcard.) 625 If PIM is being used as the PE-PE control protocol for distributing 626 C-multicast routing, and if a given PE, say PE1, needs to receive a 627 (C-S,C-G) flow, and if (C-S,C-G) matches the (C-*,C-*) S-PMSI A-D 628 route (according to the procedures of section 3.2), then PE1 MUST 629 join the P-tunnel specified in the PMSI Tunnel Attribute of that 630 route. 632 If BGP is being used as the PE-PE control protocol for distributing 633 C-multicast routing, then if (and only if) one of the following 634 conditions holds, the PE applies the procedures of section 12.3 635 ("Receiving S-PMSI A-D routes by PEs") of [MVPN-BGP] to the matching 636 S-PMSI A-D route. The conditions are: 638 - The PE has a currently originated C-multicast Source Tree Join 639 route for (C-S,C-G) that matches (according to the procedures of 640 section 3.2) the (C-*,C-*) S-PMSI A-D route, or 642 - The PE has a currently originated a C-multicast Shared Tree Join 643 route for (C-*,C-G) that matches (according to the procedures of 644 section 3.2) the (C-*,C-*) S-PMSI A-D route. 646 5. IANA Considerations 648 This document requires no actions of IANA. 650 6. Security Considerations 652 There are no additional security considerations beyond those of 653 [MVPN] and [MVPN-BGP]. 655 7. Acknowledgments 657 The authors wish to thank Arjen Boers, Dongling Duan, Apoorva Karan, 658 Thomas Morin, Keyur Patel, Karthik Subramanian, and Kurt Windisch for 659 many helpful discussions. 661 8. Authors' Addresses 663 Rahul Aggarwal 664 Juniper Networks 665 1194 North Mathilda Ave. 666 Sunnyvale, CA 94089 667 Email: raggarwa_1@yahoo.com 669 Yiqun Cai 670 Cisco Systems, Inc. 671 170 Tasman Drive 672 San Jose, CA, 95134 673 E-mail: ycai@cisco.com 675 Wim Henderickx 676 Alcatel-Lucent 677 e-mail: wim.henderickx@alcatel-lucent.be 679 Praveen Muley 680 Alcatel-Lucent 681 e-mail: Praveen.Muley@alcatel-lucent.com 683 Ray (Lei) Qiu 684 2330 Central Expressway 685 Santa Clara, CA 95050 686 USA 687 e-mail: rayq@huawei.com 688 Yakov Rekhter 689 Juniper Networks 690 1194 North Mathilda Ave. 691 Sunnyvale, CA 94089 692 Email: yakov@juniper.net 694 Eric C. Rosen 695 Cisco Systems, Inc. 696 1414 Massachusetts Avenue 697 Boxborough, MA, 01719 698 E-mail: erosen@cisco.com 700 IJsbrand Wijnands 701 Cisco Systems, Inc. 702 De kleetlaan 6a Diegem 1831 703 Belgium 704 E-mail: ice@cisco.com 706 9. Normative References 708 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra, 709 D. Katz, Y. Rekhter, RFC 4760, January 2007 711 [L3VPN] "BGP/MPLS IP Virtual Private Networks", E. Rosen, Y. Rekhter, 712 RFC 4364, February 2006 714 [MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al., RFC 715 6513, February 2012 717 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP 718 VPNs", Aggarwal, Rosen, Morin, Rekhter, Kodeboniya, RFC 6514, 719 February 2012 721 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 722 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 723 Kouvelas, RFC 4601, August 2006 725 [RFC2119] "Key words for use in RFCs to Indicate Requirement 726 Levels.", Bradner, March 1997