idnits 2.17.1 draft-rosen-l3vpn-mvpn-extranet-all-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6625, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC6513, updated by this document, for RFC5378 checks: 2005-06-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 12, 2012) is 4213 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 (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Yakov Rekhter (Editor) 3 Internet Draft Juniper Networks 4 Intended Status: Standards Track 5 Expires: April 12, 2013 Eric Rosen (Editor) 6 Updates: 6513,6514,6625 Cisco Systems 8 Rahul Aggarwal 9 Arktan 11 Yiqun Cai 12 Microsoft 14 Wim Henderickx 15 Alcatel-Lucent 17 Thomas Morin 18 France Telecom - Orange 20 Praveen Muley 21 Alcatel-Lucent 23 Ray Qiu 24 Huawei 26 IJsbrand Wijnands 27 Cisco Systems 29 October 12, 2012 31 Extranet Multicast in BGP/IP MPLS VPNs 33 draft-rosen-l3vpn-mvpn-extranet-all-00.txt 35 Abstract 37 Previous RFCs specify the procedures necessary to allow IP multicast 38 traffic to travel from one site to another within a BGP/MPLS IP VPN 39 (Virtual Private Network). However, it is sometimes desirable to 40 allow multicast traffic whose source is in one VPN to be received by 41 systems that are in another VPN. This is known as a "Multicast VPN 42 (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by 43 specifying the procedures that are necessary in order to provide MVPN 44 extranet service. 46 Status of this Memo 48 This Internet-Draft is submitted to IETF in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF), its areas, and its working groups. Note that 53 other groups may also distribute working documents as Internet- 54 Drafts. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 The list of current Internet-Drafts can be accessed at 62 http://www.ietf.org/ietf/1id-abstracts.txt. 64 The list of Internet-Draft Shadow Directories can be accessed at 65 http://www.ietf.org/shadow.html. 67 Copyright and License Notice 69 Copyright (c) 2012 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1 Introduction .......................................... 4 85 1.1 Terminology ........................................... 4 86 1.2 Scope ................................................. 7 87 1.2.1 Customer Multicast Control Protocols .................. 7 88 1.2.2 Provider Multicast Control Protocols .................. 7 89 1.3 Overview .............................................. 7 90 2 Extranets and Overlapping Address Spaces .............. 9 91 2.1 Ambiguity: P-tunnel with Extranet/Non-Extranet Flows .. 11 92 2.2 Ambiguity: P-tunnel with Multiple Extranet Flows ...... 13 93 3 Distribution of Routes that Match C-S/C-RP Addresses .. 16 94 3.1 UMH-Eligible Routes ................................... 16 95 3.2 When Unicast Routes to C-RPs Must be Distributed ...... 17 96 3.3 Other Unicast Routes that Must be Distributed ......... 18 97 3.4 Route Targets and Ambiguous UMH-Eligible Routes ....... 18 98 4 Extranet Transmission Models .......................... 20 99 4.1 Transmitting an Extranet C-flow on a Single PMSI ...... 20 100 4.1.1 Without Extranet Separation ........................... 20 101 4.1.2 With Extranet Separation .............................. 21 102 4.2 Transmitting an Extranet C-flow over Multiple PMSIs ... 21 103 5 Origination and Distribution of BGP A-D Routes ........ 22 104 5.1 Route Targets of UMH-eligible Routes and A-D Routes ... 22 105 5.2 Considerations for Particular Inclusive Tunnel Types .. 24 106 5.2.1 Inclusive P-tunnels Instantiated by RSVP-TE P2MP ...... 24 107 5.2.2 Inclusive P-tunnels and Ingress Replication ........... 25 108 6 When PIM is the PE-PE C-multicast Control Plane ....... 25 109 6.1 Provisioning VRFs with RTs ............................ 26 110 6.1.1 Incoming and Outgoing Extranet RTs .................... 26 111 6.1.2 UMH-eligible Routes and RTs ........................... 27 112 6.2 Single PMSI per C-flow Model .......................... 27 113 6.2.1 Forming the MI-PMSIs .................................. 28 114 6.2.2 S-PMSIs ............................................... 31 115 6.2.3 Sending PIM Control Packets ........................... 32 116 6.2.4 Receiving PIM Control Packets ......................... 32 117 6.2.5 Sending and Receiving Data Packets .................... 33 118 6.3 Multiple PMSIs per C-flow Model ....................... 33 119 6.3.1 Forming the MI-PMSIs .................................. 34 120 7 When BGP is the PE-PE C-multicast Control Plane ....... 35 121 7.1 Originating C-multicast Routes ........................ 36 122 7.2 Originating A-D Routes Without Extranet Separation .... 36 123 7.2.1 Intra-AS I-PMSI A-D Routes ............................ 36 124 7.2.2 S-PMSI A-D Routes ..................................... 37 125 7.2.3 Source Active A-D Routes .............................. 38 126 7.3 Originating A-D Routes With Extranet Separation ....... 38 127 7.3.1 Intra-AS I-PMSI A-D Routes ............................ 38 128 7.3.2 S-PMSI A-D Routes ..................................... 39 129 7.3.3 Source Active A-D Routes .............................. 40 130 7.4 Determining the Expected P-tunnel for a C-flow ........ 40 131 7.4.1 (C-S,C-G) S-PMSI A-D Routes ........................... 42 132 7.4.2 (C-S,C-*) S-PMSI A-D Routes ........................... 42 133 7.4.3 (C-*,C-G) S-PMSI A-D Routes ........................... 42 134 7.4.4 (C-*,C-*) S-PMSI A-D Routes ........................... 44 135 7.4.4.1 Without Extranet Separation ........................... 44 136 7.4.4.2 With Extranet Separation .............................. 44 137 7.4.5 I-PMSI A-D Routes ..................................... 44 138 7.4.5.1 Without Extranet Separation ........................... 44 139 7.4.5.2 With Extranet Separation .............................. 45 140 7.5 Packets Arriving from the Wrong P-tunnel .............. 45 141 8 Multiple Extranet VRFs on the same PE ................. 46 142 9 IANA Considerations ................................... 46 143 10 Security Considerations ............................... 46 144 11 Acknowledgments ....................................... 47 145 12 Authors' Addresses .................................... 48 146 13 References ............................................ 49 147 13.1 Normative References .................................. 49 148 13.2 Informative References ................................ 50 150 1. Introduction 152 Previous RFCs ([MVPN], [MVPN-BGP]) specify the procedures necessary 153 to allow IP multicast traffic to travel from one site to another 154 within a BGP/MPLS IP VPN (Virtual Private Network). However, it is 155 sometimes desirable to allow multicast traffic whose source is in one 156 VPN to be received by systems that are in another VPN. This is known 157 as an "extranet MVPN". This document specifies the procedures that 158 are necessary in order to provide Extranet MVPN functionality. 160 1.1. Terminology 162 This document uses terminology from [MVPN], and in particular uses 163 the prefixes "C-" and "P-" as specified in Section 3.1 of [MVPN], and 164 "A-D routes" for "auto-discovery routes". 166 The term "Upstream Multicast Hop" (UMH) is used as defined in [MVPN]. 168 The term "UMH-eligible route" is used to mean "route eligible for UMH 169 determination", as defined in Section 5.1.1 of [MVPN]. We will say 170 that a given UMH-eligible route or unicast route "matches" a given IP 171 address, in the context of a given VRF, if the address prefix of the 172 given route is the longest match in that VRF for the given IP 173 address. We will sometimes say that a route "matches" a particular 174 host if the route matches an IP address of the host. 176 We follow the terminology of section 3.2 of [MVPN-WILDCARDS] when 177 talking of an S-PMSI A-D route being "installed". That is, we say 178 that an S-PMSI A-D route is "installed" (in a given VRF) if it has 179 been selected by the BGP decision process as the preferred route for 180 its NLRI. We also follow the terminology of section 3.2 of [MVPN- 181 WILDCARDS] when saying that an S-PMSI A-D route has been "originated 182 by a given PE"; this means that the given PE's IP address is 183 contained in the "Originating Router's IP Address" field in the NLRI 184 of the route. 186 We use the following additional terminology and notation: 188 - Extranet C-source: a multicast source, in a given VPN, that is 189 allowed by policy to send multicast traffic to receivers that are 190 in other VPNs. 192 - Extranet C-receiver: a multicast receiver, in a given VPN, that 193 is allowed by policy to receive multicast traffic from extranet 194 C-sources that are in other VPNs. 196 - Extranet C-flow: a multicast flow (with a specified C-source 197 address and C-group address) whose source is an extranet 198 C-source, and which is allowed by policy to have extranet 199 C-receivers. 201 - Extranet C-group: a multicast group address that is in the "Any 202 Source Multicast" (ASM) group address range, and that is allowed 203 by policy to have Extranet C-sources and Extranet C-receivers 204 that are not all in the same VPN. Note that we will sometimes 205 refer to "SSM C-group addresses" (i.e., to C-group addresses in 206 the SSM group address range), but will never call them "extranet 207 C-groups". 209 - Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet 210 C-group; it is allowed by policy to receive PIM register messages 211 [PIM] from outside its VPN, and to send multicast data packets to 212 extranet C-receivers outside its VPN. 214 - Host(C-S,A): the host (or if C-S is an "anycast address", the set 215 of hosts) denoted by the address C-S in the context of VPN-A. 216 For example, if a particular C-source in VPN A has address C-S, 217 then Host(C-S,A) refers to that C-source. 219 Note that a given extranet C-source is not necessarily allowed to 220 transmit to every extranet C-receiver; policy determines which 221 extranet C-sources are allowed to transmit to which extranet 222 C-receivers. 224 We say that a given VRF "contains" or "has" a multicast C-source (or 225 that the C-source is "in" the VRF), if that C-source is in a site 226 connected to that VRF, and the VRF originates a UMH-eligible route 227 (see Section 3) that matches the address of the C-source. 229 We say that a given VRF "contains" or "has" a multicast C-receiver 230 (or that the C-receiver is "in" the VRF), if that C-receiver is in a 231 site connected to that VRF. 233 We say that a given VRF "contains" or "has" the C-RP for a given ASM 234 group (or that the C-RP is "in" the VRF) if that C-RP is in a site 235 connected to that VRF, and the VRF originates a unicast route and a 236 (possibly different, possibly the same) UMH-eligible route (see 237 Section 3) whose respective address prefixes match the C-RP address. 239 [MVPN] allows a set of "Provider tunnels" (P-tunnels) to be 240 aggregated together and transported via an outer P-tunnel, i.e., it 241 allows for the use of hierarchical Label Switched Paths (LSPs) as 242 P-tunnels. A two-level hierarchical LSP, for example, can be thought 243 of as a set of "inner tunnels" aggregated into an outer tunnel. In 244 this document, when we speak of a P-tunnel, we are always speaking of 245 the innermost P-tunnel, i.e., of a P-tunnel at the lowest level of 246 hierarchy. P-tunnels are identified in the Provider Multicast 247 Service Interface (PMSI) Tunnel Attributes (PTAs) [MVPN-BGP] of BGP 248 Auto-Discovery (A-D) routes. Two PTAs that have the same Tunnel Type 249 and Tunnel Identifier fields, but different MPLS label fields, are 250 thus considered to identify two different P-tunnels. (I.e., for the 251 purposes of this document, the MPLS label included in the PTA, if 252 any, is considered to be part of the tunnel identifier.) 254 We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D 255 route contains (C-S,C-G) if its "Multicast Source" field contains C-S 256 and its "Multicast Group" field contains C-G. If either or both of 257 these fields is encoded as a wildcard, we will say that the NLRI 258 contains (C-*,C-*) (both fields encoded as wildcard), or (C-*,C-G) 259 (multicast source field encoded as wildcard) or (C-S,C-*) (multicast 260 group field encoded as wildcard). 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 264 "OPTIONAL", when and only when appearing in all capital letters, are 265 to be interpreted as described in [RFC2119]. 267 1.2. Scope 269 1.2.1. Customer Multicast Control Protocols 271 This document presumes that the VPN customer is using "PIM Sparse 272 Mode", operating in either "Source-Specific Mode" (SSM) or "Any 273 Source Mode" (ASM), as the multicast control protocol at the customer 274 sites. Support for other customer IP multicast control protocols 275 (e.g., [BIDIR-PIM], PIM "Dense Mode") is outside the scope of this 276 document. Support for the customer use of MPLS multicast control 277 protocols (e.g., [mLDP], [RSVP-P2MP]) is also outside the scope of 278 this document. 280 1.2.2. Provider Multicast Control Protocols 282 [MVPN] allows either PIM or BGP to be used as the protocol for 283 distributing customer multicast routing information. Except where 284 otherwise specified, such as in Sections 6 and 7, the procedures of 285 this document cover both cases. 287 1.3. Overview 289 Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN 290 functionality as specified in [MVPN] and/or [MVPN-BGP]. In the 291 simplest configuration, VPN-S is a collection of VRFs, each of which 292 is configured with a particular Route Target (RT) value (call it 293 "RT-S") as its import RT and as its export RT. Similarly, VPN-R is a 294 collection of VRFs, each of which is configured with a particular RT 295 value (call it "RT-R") as its import RT and as its export RT. 297 In this configuration, multicast C-receivers contained in a VPN-R VRF 298 cannot receive multicast data traffic from multicast C-sources 299 contained in a VPN-S VRF. If it is desired to allow this, one needs 300 to create an MVPN "extranet". Creating an extranet requires 301 procedures in addition to those specified in [MVPN], [MVPN-BGP], and 302 [MVPN-WILDCARDS]; this document specifies these additional 303 procedures. 305 In the example above, the additional procedures will allow a selected 306 set of routes exported from the VPN-S VRFs (i.e., from the VRFs 307 containing extranet C-sources) to be imported into the VPN-R VRFs 308 (i.e., into the VRFs containing extranet C-receivers). These routes 309 include the routes that are to be eligible for use as UMH routes (see 310 Section 5.1 of [MVPN]) in the extranet, as well as a selected set of 311 BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, Source 312 Active A-D routes). Importing these routes into the VPN-R VRFs makes 313 it possible to determine, in the context of a VPN-R VRF, that a 314 particular C-multicast Join needs to be delivered to a particular 315 VPN-S VRF. It also makes it possible to determine, in the context of 316 a VPN-R VRF, the P-tunnel through which the aforementioned VPN-S VRF 317 sends a particular C-flow. 319 Depending on the type of P-tunnel used, it may also be necessary for 320 Leaf A-D routes to be exported by one or more VPN-R VRFs and imported 321 into a VPN-S VRF. 323 There are no extranet-specific procedures governing the use and 324 distribution of BGP C-Multicast routes. 326 If PIM is used as the PE-PE protocol for distributing C-multicast 327 routing information, additional BGP A-D routes must be exported from 328 the VPN-R VRFs and imported into the VPN-S VRFS, so that the VPN-S 329 VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM 330 control messages. Details can be found in Section 6. 332 The simple example above describes an extranet created from two 333 MVPNs, one of which contains extranet C-sources and one of which 334 contains extranet C-receivers. However, the procedures described in 335 this document allow for much more complicated scenarios. 337 For instance, an extranet may contain extranet C-sources and/or 338 extranet C-receivers from an arbitrary number of VPNs, not just from 339 two VPNs. An extranet C-receiver in VPN-R may be allowed to receive 340 multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C. 341 Similarly, extranet C-sources in VPN-S may be allowed to send 342 multicast traffic to multicast C-receivers that are in VPN-A, VPN-B, 343 VPN-C, etc. 345 A given VPN customer may desire that only some of its multicast 346 C-sources be treated as extranet C-sources. This can be accomplished 347 by appropriate provisioning of the import and export RTs of that 348 customer's VRFs (as well as the VRFs of other VPNs that contain 349 extranet C-receivers for extranet C-flows of the given customer.) 351 A given VPN customer may desire that some of its extranet C-sources 352 can transmit only to a certain set of VPNs, while other of its 353 extranet C-sources can transmit only to a different set of VPNs. This 354 can be accomplished by provisioning the VRFs to export different 355 routes with different RTs. 357 In all these cases, the VPN customers set the policies, and the 358 Service Provider (SP) implements the policies by the way it 359 provisions the import and export RTs of the VRFs. It is assumed that 360 the customer communicates to the SP the set of extranet C-source 361 addresses, and the set of VPNs to which each C-source can transmit. 362 This customer/SP communication is part of the service provisioning 363 process, and outside the scope of this document. 365 It is possible that an extranet C-source will transmit both extranet 366 C-flows and non-extranet C-flows. However, if extranet C-receiver 367 C-R can receive extranet C-flows from extranet C-source C-S, the 368 procedures of this document do not prevent C-R from requesting and 369 receiving the non-extranet flows that are transmitted by C-S. 370 Therefore it is NOT RECOMMENDED to allow an extranet C-source to 371 transmit non-extranet C-flows. However, the Service Provider (SP) 372 has no control over the set of C-flows transmitted by a given 373 C-source, and can do no more than communicate this recommendation to 374 its customers. (Alternatively, the customer and SP may coordinate on 375 setting up filters to prevent unauthorized flows from being sent to a 376 customer site; such a procedure is outside the scope of this 377 document.) See the "Security Considerations" section for additional 378 discussion of this issue. 380 2. Extranets and Overlapping Address Spaces 382 As specified in [L3VPN], the address space of one VPN may overlap 383 with the address space of another. A given address may be 384 "ambiguous", in that it denotes one system within VPN-A and a 385 different system within VPN-B. In the notation of section 1.1, if an 386 address C-S is ambiguous between VPNs A and B, then Host(C-S,A) != 387 Host(C-S,B). However, any given address C-S must be unambiguous 388 (i.e., denotes a single system) in the context of a given VPN. 390 When a set of VRFs belonging to different VPNs are combined into an 391 extranet, it is no longer sufficient for an address to be unambiguous 392 only within the context of a single VPN: 394 1. Suppose C-S is the address of a given extranet C-source 395 contained in VPN-A. Now consider the set of VPNs {VPN-B, VPN- 396 C, ...} containing extranet C-receivers that are allowed by 397 policy to receive extranet C-flows from VPN-A's C-S. The 398 address C-S MUST be unambiguous among this entire set of VPNs 399 (VPN-A, VPN-B, VPN-C, etc.); i.e., Host(C-S,A) == Host(C-S,B) 400 == Host(C-S,C). 402 The implication is that C-S in VPN-A is not necessarily an 403 extranet C-source for all VPNs that contain extranet C- 404 receivers; policy MUST be used to ensure that C-S is an 405 extranet C-source for a given VPN, say VPN-B, only if C-S is 406 unambiguous between VPN-A and VPN-B. 408 2. If a given VRF contains extranet C-receivers for a given 409 extranet C-source, then the address of this C-source MUST be 410 unambiguous among all the extranet C-sources for which there 411 are C-receivers in the VRF. This is true whether or not 412 C-sources are in VRFs that belong to the same or to different 413 VPNs. 415 The implication is that if C-S in VRF-X is ambiguous with C-S 416 in VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing 417 C-receivers that are allowed by policy to receive extranet C- 418 flows from both C-S in VRF-X and C-S in VRF-Y. 420 Note: A VPN customer may be using "anycast" addresses. An anycast 421 address is intentionally ambiguous, as it denotes a set of systems 422 rather than a single system. In this document, we will consider an 423 anycast address to be unambiguous in a given context as long as it 424 denotes the same set of systems whenever it occurs in that context. 426 A multicast C-group address, say C-G, may also be ambiguous, in that 427 it may be used for one multicast group in VPN-A and for an entirely 428 different multicast group in VPN-B. If a set of MVPNs are combined 429 into an extranet, and C-G is an extranet C-group, it is necessary to 430 ensure that C-G is unambiguous among the entire set of VPNs whose 431 VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers 432 for that C-group. This may require, as part of the provisioning 433 process, customer/SP communication that is outside the scope of this 434 document. 436 Subject to these restrictions, the SP has complete control over the 437 distribution of routes in an MVPN. This control is exerted either by 438 provisioning the export RTs on the VRFs that originate the routes 439 (i.e., on the VRFs that contain the extranet C-sources), or by 440 provisioning the the import RTs on the VRFs that receive the routes 441 (i.e., on the VRFs that contain the extranet C-receivers), or both. 443 Some of the rules and restrictions on provisioning the RTs are 444 applicable to all extranets; these are specified in Section 3. 445 Sections 6 and 7 add additional rules and restrictions that are 446 applicable only to particular extranet scenarios. 448 Sections 2.1 and 2.2 describe scenarios in which address ambiguity 449 can arise within an extranet. The procedures specified in this 450 document have been designed to ensure that the address ambiguity 451 described in those sections does not result in misdelivery of 452 traffic. 454 2.1. Ambiguity: P-tunnel with Extranet/Non-Extranet Flows 456 In the following, we will use the notation "VRF A-n" to mean "VRF n 457 of VPN-A". 459 If VPN-A and VPN-B have overlapping address spaces, and are part of 460 the same extranet, then the following problem may exist. Suppose: 462 - VRF A-1, on PE1, contains an extranet C-source, whose IP address 463 is C-S1, that is allowed to have receivers in VPN B. VRF A-1 464 thus exports to VPN B a UMH-eligible route matching C-S1. 466 - VRF A-1 also contains a non-extranet C-source, whose IP address 467 is C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 to 468 other VPN A VRFs, but NOT to VPN B. 470 - VRF B-1, also on PE1, contains a non-extranet C-source whose IP 471 address is C-S2. A UMH-eligible route matching C-S2 is thus 472 exported from VRF B-1 to other VRFs in VPN B. 474 - Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous 475 address in any extranet that contains both VPN-A VRFs and VPN-B 476 VRFs. 478 - VRF B-2, on some other PE, say PE2, requests to receive the 479 multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1 480 matches the route exported from VRF A-1. Thus B-2's request to 481 receive the (C-S1,C-G) flow is transmitted to VRF A-1. 483 - VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by 484 transmitting that traffic on P-tunnel P1. 486 - VRF B-2 joins P-tunnel P1, in order to receiver the (C-S1,C-G) 487 traffic. 489 - VRF A-2, on PE2, requests to receive the (non-extranet) multicast 490 flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the 491 route exported from VRF A-1. Thus A-2's request to receive the 492 (C-S2,C-G) traffic is transmitted to VRF A-1. 494 - VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by 495 transmitting that traffic on P-tunnel P1. 497 - VRF A-2 joins P-tunnel P1, in order to receive the (C-S2,C-G) 498 traffic. 500 - VRF B-2 requests to receive the (non-extranet) multicast flow 501 (C-S2,C-G). In the context of VRF B-2, C-S2 matches the route 502 exported from VRF B-1. Thus B-2's request to receive the 503 (C-S2,C-G) flow is transmitted to VRF B-1. 505 - VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by 506 transmitting that traffic on P-tunnel P2. 508 - VRF B-2 joins P-tunnel P2. 510 Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive 511 (C-S2,C-G) traffic on both P-tunnels. But the (C-S2,C-G) traffic 512 that VRF B-2 needs to receive is traveling on P-tunnel P2. The 513 (C-S2,C-G) traffic arriving on P2 must be forwarded by B-2 to any 514 attached customer sites that have C-receivers for it. But B-2 MUST 515 discard the (C-S2,C-G) traffic that it receives on P1, as this is not 516 the traffic that it has requested. If the (C-S2,C-G) traffic 517 arriving on P1 were forwarded to B-2's customer sites, the C- 518 receivers would not be able to distinguish the two flows, and the 519 result would be a corrupted data stream. 521 Note that the procedures of [MVPN] Section 9.1.1 ("Discarding Packets 522 from the Wrong PE") will not cause VRF B-2 to discard the (C-S2,C-G) 523 that arrives on tunnel P1, because P1 and P2 have the same upstream 524 PE. 526 Therefore, it is necessary EITHER to prevent the above scenario from 527 occurring, OR ELSE to ensure that multicast data packets will be 528 discarded if they arrive on the wrong P-tunnel (even if they arrive 529 from the expected PE). 531 Subsequent sections describe a set of procedures, which we call 532 "extranet separation", that can be used to prevent extranet C-flows 533 and non-extranet C-flows from being carried in the same P-tunnel, 534 thereby preventing the above scenario from occurring. 536 Subsequent sections also describe a set of procedures that allows 537 extranet and non-extranet C-flows to be carried in the same P-tunnel, 538 but ensures that the packets of a given C-flow will be discarded if 539 they arrive on the wrong P-tunnel (even if they arrive from the 540 expected PE). In our example, VRF B-2 will be expecting the 541 (C-S2,C-G) packets to arrive on P-tunnel P2. When VRF B-2 receives a 542 multicast packet over a P-tunnel, and the multicast packet has source 543 address C-S2 and destination address C-G, VRF B-2 will forward the 544 packet only if it arrived over P-tunnel P2, but will discard it if it 545 arrived over P-tunnel P1. Detailed procedures for associating a 546 given C-flow with a given P-tunnel are provided in Sections 6 and 7. 548 2.2. Ambiguity: P-tunnel with Multiple Extranet Flows 550 Here is another example in which overlapping address spaces may cause 551 a problem. Suppose: 553 - C-G is an SSM C-group address that is used in VPNs A, B, C, and 554 D. 556 - VRF A-1, on PE1, contains extranet an C-source whose IP address 557 is C-S1, and that is allowed by policy to have C-receivers in VPN 558 C (but not in VPN D). VRF A-1 thus exports a UMH-eligible route 559 matching C-S1 to VPN C. 561 - VRF A-1 also contains an extranet C-source whose IP address is 562 C-S2, and that is allowed by policy to have C-receivers in VPN D 563 (but not in VPN C). VRF A-1 thus exports a UMH-eligible route 564 matching C-S2 to VPN D. 566 - VRF B-1, also on PE1, contains an extranet C-source whose IP 567 address is C-S2, and that is allowed by policy to have 568 C-receivers in VPN C (but not in VPN D). VRF B-1 thus exports a 569 UMH-eligible route matching C-S2 to VPN C. 571 - Host(C-S2,A) != Host (C-S2,B). That is, C-S2 is an ambiguous 572 address in any extranet that contains both VPN-A VRFs and VPN-B 573 VRFs. 575 - VRF C-1, on some other PE, say PE2, requests to receive the 576 extranet multicast flow (C-S1,C-G). In the context of VRF C-1, 577 C-S1 matches the route exported from VRF A-1. Thus C-1's request 578 to receive the (C-S1,C-G) flow is transmitted to VRF A-1. 580 + VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by 581 transmitting that traffic on P-tunnel P1, 583 - VRF C-1 joins P-tunnel P1, in order to receive the (C-S1,C-G) 584 traffic. 586 - VRF C-1 requests to receive the extranet multicast flow 587 (C-S2,C-G). In the context of VRF C-1, C-S2 matches the route 588 exported from VRF B-1. Thus C-1's request to receive the 589 (C-S2,C-G) flow is transmitted to VRF B-1. 591 - VRF B-1 responds by transmitting its (C-S2,C-G) traffic on 592 P-tunnel P2. 594 - VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) 595 traffic. 597 - VRF D-1, on PE2, requests to receive the extranet multicast flow 598 (C-S2,C-G). In the context of VRF D-1, C-S2 matches the route 599 exported from VRF A-1. Thus D-1's request to receive the 600 (C-S2,C-G) flow is transmitted to VRF A-1. 602 - VRF A-1 responds by transmitting its (C-S2,C-G) traffic on 603 P-tunnel P1. 605 - VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G) 606 traffic. 608 In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to 609 carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic. VRF 610 C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic 611 from VRF A-1, which means that VRF C-1 will also receive the unwanted 612 (C-S2,C-G) traffic from P1. VRF C-1 is also expecting (C-S2,C-G) 613 traffic from VRF B-1; this traffic will be received from P2. Thus 614 VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both 615 C-flows arrive from the expected PE, PE1. 617 So again, a procedure is necessary that EITHER prevents this sort of 618 ambiguity from occuring, OR ELSE that ensures that VRF C-1 discards 619 any (C-S,C-G) traffic that arrives from "the wrong P-tunnel". 621 Note that extranet separation does not prevent this ambiguity from 622 occuring, as the ambiguity is between two C-flows that are both 623 extranet C-flows. 625 This ambiguity would not occur if C-G were an (ASM) extranet C-group, 626 as the scenario would then violate the rule given in section 2 627 requiring that all sources sending to a particular ASM extranet 628 C-group must have addresses that are unambiguous over all the MVPNs 629 receiving traffic for that C-group. 631 For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI 632 contains (C-S,C-G) or (C-S,C-*), the ambiguity described in this 633 section can be prevented by provisioning a policy that assigns, to 634 such P-tunnels, only flows from the same C-source. 636 However, it is not always possible to determine, through inspection 637 of the control messages, whether this policy has been deployed. For 638 instance, suppose a given VRF has imported a set of S-PMSI A-D 639 routes, that each route in the set has bound only a single 640 (C-S1,C-G1) to a single P-tunnel, and that each route in the set 641 identifies a different P-tunnel in its PTA than is identified by the 642 PTA of any other route in the set. One cannot infer from this that 643 there is no ambiguity, as the same P-tunnel may also have been 644 advertised in an S-PMSI A-D route that is not imported by the given 645 VRF, and that S-PMSI A-D route may have bound (C-S2,C-G2) to the 646 P-tunnel, where C-S1 != C-S2. 648 Therefore, in order to determine that a given P-tunnel (advertised in 649 a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from 650 a single C-source, one must have a priori knowledge (through 651 provisioning) that this policy has been deployed. In the remainder 652 of this document, we will refer to this policy as the "Single 653 C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy. Note that this 654 policy is only applicable to P-tunnels that are advertised only in 655 (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes. 657 Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route, or 658 (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an 659 S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always 660 possible for the P-tunnel to contain traffic from multiple C-sources; 661 there is no policy that can prevent that. 663 However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route 664 contains only traffic addressed to a single C-G, the address 665 uniqueness rules of section 2 prevent the C-source addresses from 666 being ambiguous; the set of C-sources transmitting to a particular 667 extranet C-group address must be unambiguous over the set of MVPNs 668 that have receivers for that C-group. So for P-tunnels that are 669 advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguity described in 670 this section can be prevented by provisioning a policy that assigns, 671 to such P-tunnels, only flows to the same extranet C-group. We will 672 refer to this policy as the "Single C-group per (C-*,C-G) P-tunnel" 673 policy. 675 Sections 6 and 7 describe procedures that cause a VRF with 676 C-receivers to discard any (C-S,C-G) traffic that arrives on "the 677 wrong P-tunnel". These procedures are needed unless all of the 678 following conditions hold: 680 - the "Single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy 681 is provisioned, and 683 - either the "Single C-group per (C-*,C-G) P-tunnel" policy is 684 provisioned, or else no P-tunnels are advertised in (C-*,C-G) 685 S-PMSI A-D routes, and 687 - no P-tunnels are advertised in I-PMSI A-D routes or (C-*,C-*) 688 S-PMSI A-D routes. 690 Note that the "Single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" 691 policy and the "Single C-group per (C-*,C-G) P-tunnel" policy both 692 imply extranet separation for tunnels advertised in the S-PMSI A-D 693 routes to which the policies apply. 695 3. Distribution of Routes that Match C-S/C-RP Addresses 697 3.1. UMH-Eligible Routes 699 As described in Section 5.1 of [MVPN], in order for a C-flow 700 (C-S,C-G) to be carried across the SP backbone, a VRF that has 701 multicast receivers for that C-flow MUST import a route that matches 702 C-S, and this route must be "eligible for UMH selection". In this 703 document, we will refer to these routes as "UMH-eligible extranet 704 C-source routes". 706 The UMH-eligible extranet C-source routes do not necessarily have to 707 be unicast routes. If one wants, e.g., a VPN-R C-receiver to be able 708 to receive extranet C-flows from C-sources in VPN-S, but one does not 709 want any VPN-R system to be able to send unicast traffic to those 710 C-sources, then the UMH-eligible routes exported from VPN-S and 711 imported by VPN-R MAY be SAFI 129 routes (see Section 5.1.1 of 712 [MVPN]). The SAFI 129 routes are used only for UMH determination, 713 but not for unicast routing. 715 If a customer is using PIM-SM in ASM mode, and one or more customer 716 sites have C-receivers that are allowed by policy to join a (C-*,C-G) 717 tree, where C-G is an extranet C-group, then any VRF with C-receivers 718 for that group MUST import a UMH-eligible route that matches C-RP, 719 where C-RP is the Rendezvous Point (RP) address for C-G. 721 The UMH-eligible extranet C-source and C-RP routes do not have to be 722 "host routes." That is, they can be routes whose IPv4 address 723 prefixes are not 32 bits in length, or whose IPv6 address prefixes 724 are not 128 bits in length. So it is possible for a UMH-eligible 725 extranet C-source route to match the address of an extranet C-source 726 and to also match the address of a non-extranet C-source. However, 727 if such a route is exported from a VPN-S VRF and imported by a VPN-R 728 VRF, VPN-R receivers will be able to receive C-flows from any non- 729 extranet C-sources whose addresses match that route. To prevent 730 this, the VPN-S VRF SHOULD be provisioned such that it will NOT 731 export a UMH-eligible route that matches (in the context of the VPN-R 732 VRF) both extranet C-sources and non-extranet C-sources. Failure to 733 follow this rule may result in a VPN security violation. (See Section 734 10.) 736 In general, one does not want ALL the routes from the VPN-S VRFs to 737 be exported to all the VPN-R VRFs, as only a subset of the routes in 738 the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route 739 distribution is, as always in a BGP/MPLS IP VPN [L3VPN], controlled 740 by Route Targets (RTs). A variety of route distribution policies can 741 be created by appropriately provisioning the import and export RTs of 742 the various VRFs. 744 For example, the VPN-S VRFs that contain extranet C-sources could be 745 configured to apply an export RT whose value is "RT-A-extranet" to 746 the routes that match the extranet C-sources. The VPN-R VRFs that 747 contain extranet C-receivers allowed to receive extranet C-flows from 748 VPN-S extranet C-sources could then be configured with 749 "RT-A-extranet" as an import RT. 751 Arbitrarily complex policies can be created by suitable manipulation 752 of the import and export RTs. 754 3.2. When Unicast Routes to C-RPs Must be Distributed 756 Suppose a VRF contains a C-source, C-S, that may transmit to a 757 particular extranet C-group C-G. Then the VRF must import a unicast 758 route matching that C-RP of that group. This allows the C-S's 759 Designated Router to unicast Register messages to the C-RP when C-S 760 begins to send traffic to C-G. The unicast route matching the C-RP 761 is needed whether or not the VRF has also imported a SAFI 129 route 762 matching the C-RP. If the VRF contains both transmitters and 763 receivers for a particular extranet C-group, and if the PEs are doing 764 UMH determination by means of SAFI 129 route, both a SAFI 129 route 765 and a unicast route matching the C-RP are needed. 767 If the customer is using "anycast-RP"([RFC3446], [RFC4610]), then all 768 the C-RPs that serve a particular extranet C-group need to send 769 unicast messages to each other. Thus any VRF that contains a C-RP 770 for a particular extranet C-group needs to import unicast routes 771 matching ALL the other C-RPs that serve that extranet C-group. 773 A sufficient condition for meeting these requirements of this sub- 774 section is that the C-sources and C-RPs for a given extranet C-group 775 are all in the same MVPN. While this is not a necessary condition, 776 it may be impractical to provision the MVPN properly if this 777 condition doesn't hold. 779 3.3. Other Unicast Routes that Must be Distributed 781 A C-RP for an extranet multicast C-group must be able to send PIM 782 Register-Stop messages to the "first hop Designated Router" of each 783 of that C-group's C-sources. This means that any VRF containing a 784 C-RP must import unicast routes to all of C-G's C-sources and to all 785 of the first hop Designated Routers of those C-sources. 787 There are several "dynamic RP discovery" protocols in common use by 788 VPN customers. Generally these protocols require that some amount of 789 unicast communication among the systems that are participating in the 790 discovery protocol. For example, in BSR [BSR], a "Bootstrap Router" 791 is elected dynamically from among a set of candidate-Bootstrap- 792 Routers, and "candidate-RP" systems send unicast messages to the 793 Bootstrap router. So any VRF containing a candidate-RP must import a 794 unicast route matching the address of any system that participates in 795 the Bootstrap Router election process. 797 A sufficient condition for meeting this requirement is that the all 798 candidate-RPs and all the candidate-Bootstrap-Routers be in the same 799 MVPN. 801 It is outside the scope of this document to specify the necessary 802 conditions under which various dynamic RP discovery procedures may 803 work. 805 3.4. Route Targets and Ambiguous UMH-Eligible Routes 807 This section imposes constraints on the way RTs are assigned to (a) 808 UMH-eligible routes and to (b) the BGP A-D routes that advertise 809 P-tunnels (i.e., to BGP A-D routes that contain a PTA). The 810 constraints specified here apply to any extranet for which the 811 ambiguity of Section 2.2 is possible. (The conditions under which 812 such ambiguity is possible are described in Section 2.2.) 814 We want to ensure that, in any given VRF, the UMH-eligible route 815 matching a given extranet C-source has an RT in common with every BGP 816 A-D route that advertises a P-tunnel that may be used to carry 817 extranet multicast traffic from that C-source. We also want to 818 ensure that the UMH-eligible route matching a given extranet C-source 819 does not have any RT in common with any BGP A-D route that advertises 820 a P-tunnel that may be used to carry any multicast traffic from a 821 different C-source that has the same IP address. This enables us to 822 determine whether traffic that appears to be from the given C-source 823 is really arriving on the "wrong tunnel", and hence is really from a 824 different C-source with the same IP address. 826 Suppose an IP address C-S is used in VPN-A as the address of one 827 system, and is used in VPN-B as the address of a different system. 828 In this case, one or more VPN-A VRFs may export a VPN-IP route whose 829 NLRI is , and one or more VPN-B VRFs may export a VPN-IP route 830 whose NLRI is , where RD1 != RD2. Consider two routes, R1 and 831 R2, for which the following conditions all hold: 833 - R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or 834 are unicast routes matching a C-RP 836 - R1 is exported from a VRF of VPN-A, while R2 is exported from a 837 VRF of a different VPN, say VPN-B 839 - R1's NLRI specifies IP address prefix S/n 841 - R2's NLRI specifies IP address prefix S/m 843 - m >= n, (S/m is either the same as or more specific than S/n) 845 - There is some host address H such that: 847 * H denotes a different system in VPN-A than in VPN-B, 849 * H/m == S/m (so either S/m or S/n might be a longest match for 850 H in some VRF). 852 We impose the following constraint: RTs MUST be assigned in such a 853 way that R1 and R2 do not have any RT in common. 855 (This constraint is not as onerous at it may seem. Typically R1 and 856 R2 would not have an RT in common, as that might result in their 857 being imported into the same VRF, making the address H ambiguous in 858 that VRF.) 860 Sections 6 and 7 specify procedures for determining if a received 861 C-flow has been received over the wrong P-tunnel. Those procedures 862 will not work if this constraint is violated. (The constraint 863 described in this section is necessary but not sufficient for the 864 procedures of those sections to work; additional constraints, 865 covering the assignment of RTs to BGP A-D routes, are given in 866 subsequent sections.) 868 4. Extranet Transmission Models 870 This document specifies several "extranet transmission models". A 871 given VRF, containing extranet C-sources or C-receivers, MUST use 872 only one of these models. Further if VRF S contains extranet 873 C-sources, VRF R contains extranet C-receivers, and it is allowed by 874 policy for an extranet C-receiver in VRF R to receive a C-flow from 875 an extranet C-source in VRF S, then VRFs S and R MUST use the same 876 extranet transmission model. The model used by a given VRF is 877 determined by provisioning. 879 4.1. Transmitting an Extranet C-flow on a Single PMSI 881 In one extranet transmission model, which we call the "transmitting 882 an extranet C-flow on a single PMSI" model, or more simply, the 883 "single PMSI per C-flow model", a PE transmitting a packet of an 884 extranet C-flow transmits it on only a single PMSI. If the PMSI is 885 instantiated by a multicast P-tunnel, this means that the PE 886 transmits the packet on a single P-tunnel. Of course, if the PE is a 887 replication point for that multicast P-tunnel, the packet is 888 transmitted more than once by the PE. Similarly, if the PMSI is 889 instantiated by a set of unicast tunnels (i.e., via Ingress 890 Replication), each packet may be transmitted multiple times. It is 891 still the case though that the packet is transmitted only on one 892 PMSI. 894 This document provides procedures for supporting this transmission 895 model using either BGP or PIM as the PE-PE C-multicast control 896 protocol. 898 There are two variants of this transmission model: "without extranet 899 separation" and "with extranet separation". 901 4.1.1. Without Extranet Separation 903 In this variant, multicast data traffic from extranet C-sources and 904 from non-extranet C-sources may be carried in the same P-tunnel. 906 This document provides procedures for supporting this variant using 907 either BGP or PIM as the PE-PE C-multicast control protocol. 909 4.1.2. With Extranet Separation 911 In this variant, multicast data traffic from extranet C-sources and 912 from non-extranet C-sources are never carried in the same P-tunnel. 913 Under certain circumstances, this can reduce the amount of multicast 914 data traffic that is delivered unnecessarily to certain PE routers. 915 It also eliminates the ambiguity discussed in Section 2.1.1. 917 By definition, when extranet separation is used, the following rule 918 MUST be applied: 920 Traffic from extranet C-sources MUST NOT be carried in the same 921 P-tunnel as traffic from non-extranet C-sources. 923 If VRF-S does not contain both extranet C-sources and non-extranet 924 C-sources, this condition holds automatically. Otherwise it is 925 necessary to advertise P-tunnels that are specifically used for 926 carrying only extranet C-flows. 928 Under certain circumstances, extranet separation can reduce the 929 amount of multicast data traffic that is delivered unnecessarily to 930 certain PE routers. 932 Note that while this prevents the ambiguity of Section 2.1 from 933 occurring, it does not prevent the ambiguity of Section 2.2 from 934 occurring. 936 This document provides procedures for supporting extranet separation 937 when BGP is used as the PE-PE C-multicast control protocol. Support 938 for extranet separation using PIM as the PE-PE C-multicast control 939 protocol is outside the scope of this document. 941 4.2. Transmitting an Extranet C-flow over Multiple PMSIs 943 The second extranet transmission model is called the "transmitting an 944 extranet C-flow over multiple PMSIs" model, or more simply, the 945 "multiple PMSIs per C-flow model". In this model, a PE may transmit 946 the packets of an extranet C-flow on several different PMSIs. 948 Support for extranet separation with this model is outside the scope 949 of this document. 951 This document provides procedures for supporting this transmission 952 model when PIM as the PE-PE C-multicast control protocol. Support for 953 this transmission model when BGP is used as the PE-PE C-multicast 954 control protocol is outside the scope of this document 956 5. Origination and Distribution of BGP A-D Routes 958 Except where otherwise specified, this section describes procedures 959 and restrictions that are independent of the PE-PE C-multicast 960 control protocol. 962 5.1. Route Targets of UMH-eligible Routes and A-D Routes 964 Suppose there is an extranet C-flow such that: 966 - The extranet C-source of that C-flow is in VRF A-1. 968 - One or more extranet C-receivers of that C-flow are in VRF B-1. 970 In this case VRF A-1 must export a UMH-eligible route that matches 971 the extranet C-source address, and VRF B-1 must import that route. 972 In addition, VRF A-1 must export an Intra-AS I-PMSI A-D route or an 973 S-PMSI A-D route specifying the P-tunnel through which it will send 974 the data traffic of the given extranet C-flow, and VRF B-1 must 975 import that route. If BGP is the PE-PE C-multicast control protocol, 976 then under certain conditions (as specified in [MVPN-BGP]), VRF A-1 977 may also need to export a Source Active A-D route specifying that it 978 contains a source of the given C-flow, and VRF B-1 must import that 979 Source Active A-D route. That is, in order for VRF B-1 to receive a 980 C-flow from, a given extranet C-source contained in VRF A-1, VRF A-1 981 must export a set of A-D routes that are "about" that source, and VRF 982 B-1 must import them. 984 One way to ensure this is to provision an RT that is carried by all 985 the routes exported from VRF A-1 that are "about" a given extranet 986 C-source, and to provision this RT as an import RT at any VRF (such 987 as VRF B-1) that is allowed to receive extranet flows from source. 989 If the "single PMSI per C-flow" transmission model is being used 990 (with or without extranet separation), there is a an additional 991 requirement, stated below, on the way RTs are provisioned, as the RTs 992 carried by a UMH-eligible route that matches a given extranet 993 C-source may need to be used to identify the A-D routes that are 994 "about" that source. 996 Consider the following scenario: 998 - IP address S is the address of one system in VPN-A, and of a 999 different system in VPN-B. 1001 - VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching 1002 route for S. 1004 - VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a 1005 P-tunnel through which VRF A-1 may send traffic whose C-source is 1006 S, where one of the following conditions holds: 1008 * P1 is an I-PMSI A-D route, OR 1010 * P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or 1011 (C-*,C-G), OR 1013 * P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or 1014 (C-S,C-*), BUT the "single C-source per (C-S,C-G) or 1015 (C-S,C-*) P-tunnel" policy is not provisioned. 1017 * P1 is a Source Active A-D route whose NLRI contains (C-S,C-G) 1019 - VRF B-1 on PE1 exports a UMH-eligible route R2, which is a 1020 matching route for S. 1022 - VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a 1023 P-tunnel on which VRF B-1 may send traffic whose C-source is S, 1024 where one of the following conditions holds: 1026 * P2 is an I-PMSI A-D route, OR 1028 * P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or 1029 (C-*,C-G), OR 1031 * P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or 1032 (C-S,C-*), BUT the "single C-source per (C-S,C-G) or 1033 (C-S,C-*) P-tunnel" policy is not provisioned. 1035 * P2 is a Source Active A-D route whose NLRI contains (C-S,C-G) 1037 As already specified in section 3.1, there MUST NOT be any RT that is 1038 common to both R1 and R2. In addition, the following set of rules 1039 for RT assignment MUST be followed when extranets are supported. 1040 This set of rules supports all the extranet transmission models 1041 described in this specification: 1043 - There MUST NOT be any RT that is carried by both P1 and P2. 1045 - The intersection of the set of RTs carried by P1 and the set of 1046 RTs carried by R1 MUST be non-null, and any VRF that imports both 1047 P1 and R1 MUST be configured with an import RT from this 1048 intersection. 1050 - The intersection of the set of RTs carried by P2 and the set of 1051 RTs carried by R2 MUST be non-null, and any VRF that imports both 1052 P2 and R2 MUST be configured with an import RT from this 1053 intersection. 1055 Suppose VRF C-1 on PE2 imports P1 and R1 from VRF A-1, while also 1056 importing P2 from VRF B-1. Since: 1058 - R1 is VRF C-1's route to S, and 1060 - R1 has an RT in common with P1, and 1062 - R1 has no RT in common with P2 1064 it can be concluded that VRF C-1 should expect that multicast traffic 1065 from S will arrive on the P-tunnel specified in P1. See Sections 6 1066 and 7 for more details on determining the expected P-tunnel for a 1067 given extranet C-flow. 1069 While the assignment of import and export RTs to routes is a 1070 deployment and provisioning issue rather than a protocol issue, it 1071 should be understood that failure to follow these rules is likely to 1072 result in VPN security violations. 1074 5.2. Considerations for Particular Inclusive Tunnel Types 1076 5.2.1. Inclusive P-tunnels Instantiated by RSVP-TE P2MP 1078 Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and 1079 that VRF-S advertises in its Intra-AS I-PMSI A-D route a P2MP RSVP-TE 1080 as the P-tunnel to carry (extranet multicast) traffic. Suppose VRF-R 1081 contains an extranet C-receiver that is allowed by policy to receive 1082 extranet flows from C-S. Then the RT(s) carried by the Intra-AS 1083 I-PMSI A-D routes originated by VRF-R must be such that those 1084 Intra-AS I-PMSI A-D routes will be imported into VRF-S. (I.e., In 1085 order for VRF-S to set up the P2MP RSVP-TE P-tunnel, it must know all 1086 the PEs that are leaf nodes of the P-tunnel, and to learn this it 1087 MUST import an Intra-AS I-PMSI A-D route from every VRF that needs to 1088 receive data through that tunnel.) 1090 5.2.2. Inclusive P-tunnels and Ingress Replication 1092 [MVPN] and [MVPN-BGP] specify procedures that allow I-PMSIs to be 1093 instantiated by point-to-point (unicast) LSPs. This is known as 1094 "ingress replication". In effect, the I-PMSI is instantiated by a 1095 set of P2P P-tunnels, one for each 1096 pair. However, when a PE receives a given packet on such an I-PMSI, 1097 those procedures do not enable the receiving PE to identify the 1098 particular P-tunnel over which the packet arrived. The receiving PE 1099 can identify the I-PMSI over which a given packet has arrived, but 1100 cannot identify the PE that transmitted the packet. 1102 When a packet is part of an extranet C-flow, the procedures specified 1103 in this document require a receiving PE to identify the P-tunnel over 1104 which the packet has arrived. As a result, when I-PMSIs are 1105 instantiated by Ingress Replication, the Ingress Replication 1106 procedures of [MVPN] and [MVPN-BGP] are insufficient to allow such 1107 I-PMSIs to be used for extranet support. 1109 Supporting extranet using inclusive P-tunnels instantiated by Ingress 1110 Replication is outside the scope of this document. 1112 However, much the same effect (in the data plane) can be obtained by 1113 using selective P-tunnels instantiated by Ingress Replication, if 1114 those P-tunnels are advertised in the PTA of (C-*,C-*) S-PMSI A-D 1115 routes as described in [MVPN-WILDCARDS] and Sections 7.2.2, 7.3.2, 1116 and 7.4.4 of this document. 1118 6. When PIM is the PE-PE C-multicast Control Plane 1120 As specified in [MVPN], when PIM is used as the PE-PE C-multicast 1121 control plane for a particular MVPN, there is an MI-PMSI for that 1122 MVPN, and all the PEs of that MVPN must be able to send and receive 1123 on that MI-PMSI. Associated with each VRF of the MVPN is a PIM 1124 C-instance, and the PIM C-instance treats the MI-PMSI as if it were a 1125 LAN interface. That is, the "ordinary" PIM procedures run over the 1126 MI-PMSI just as they would over a real LAN interface, except that the 1127 data plane and control plane "RPF checks" need to be modified. 1128 Section 5.2 of [MVPN] specifies the RPF check modifications for non- 1129 extranet MVPN service. 1131 For example, suppose that there are two VPNs, VPN-S and VPN-R. In 1132 the absence of extranet support, all the VRFs of VPN-S are connected 1133 via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of 1134 VPN-R are connected via another ("the VPN-R MI-PMSI"). If we want to 1135 provide extranet service in which the extranet C-sources are attached 1136 to some set of VPN-S VRFs, while the extranet C-receivers are 1137 attached to some set of VPN-R VRFs, then we have two choices: 1139 1. either the VPN-R VRFs need to join the VPN-S MI-PMSI, or 1141 2. the VPN-S VRFs need to join the VPN-R MI-PMSI. 1143 The first choice is used to support the "single PMSI per C-flow" 1144 transmission model. The second choice is used to support the 1145 "multiple PMSIs per C-flow" transmission model. 1147 Procedures for both models are described below. 1149 To support these models, it must be possible to determine which 1150 I-PMSI A-D routes are associated with the VPN-S I-PMSI, and which are 1151 associated with the VPN-R I-PMSI. Procedures are given for assigning 1152 RTs to these routes in a way that makes this determination possible. 1154 Both models allow the use of S-PMSIs to carry multicast data traffic. 1155 If a VRF containing receivers can receive from multiple MI-PMSIs, 1156 each S-PMSI must be uniquely associated with a particular MI-PMSI. 1157 Procedures are given for assigning RTs to these routes in a way that 1158 makes this determination possible. 1160 All the procedures specified in Sections 3-5 still apply. 1162 Note that there are no special extranet procedures for Inter-AS 1163 I-PMSI A-D routes or for Leaf A-D routes. Source Active A-D routes 1164 are not used when PIM is the PE-PE C-multicast protocol. 1166 6.1. Provisioning VRFs with RTs 1168 6.1.1. Incoming and Outgoing Extranet RTs 1170 In the absence of extranet service, suppose that each VRF of a given 1171 VPN, call it VPN-S, is configured with RT-S as its import and export 1172 RT, and that each VRF of a second VPN, call it VPN-R, is configured 1173 with RT-R as its import and export RT. We will refer to RT-S and 1174 RT-R as "non-extranet RTs". 1176 Now suppose that VPN-S contains some extranet C-sources, and VPN-R 1177 contains some extranet C-receivers that are allowed by policy to 1178 receive extranet C-flows from the VPN-S extranet C-sources. 1180 To set up this S-to-R extranet, it is necessary to provision an 1181 additional RT, call it RT-S-to-R, whose value is, in general, 1182 distinct from RT-S and RT-R. 1184 A VPN-S VRF that contains extranet C-sources allowed to transmit to 1185 VPN-R must be configured with RT-S-to-R as an "Outgoing Extranet RT". 1187 A VPN-R VRF that contains extranet C-receivers allowed to received 1188 from VPN-S must be configured with RT-S-to-R as an "Incoming Extranet 1189 RT" 1191 The Incoming Extranet RTs and Outgoing Extranet RTs that are 1192 configured for a given VRF serve as import RTs for that VRF. They 1193 also serve as export RTs, but only for specific routes as specified 1194 in section 6.1.2 below. 1196 Note that any VRF that contains both extranet C-sources and extranet 1197 C-receivers MUST be configured with both Outgoing and Incoming 1198 Extranet RTs. 1200 A VRF may be configured with more than one Incoming and/or Outgoing 1201 Extranet RT. 1203 If it happens to be the case that all C-sources in VPN-S are extranet 1204 C-sources allowed to transmit to VPN-R, then VPN-S VRFs may be 1205 configured such that RT-S is both a non-extranet RT and an Outgoing 1206 Extranet RT, and VPN-R VRFs may be configured such that RT-S is an 1207 Incoming Extranet RT. 1209 6.1.2. UMH-eligible Routes and RTs 1211 Suppose R1 is a route, exported from a VPN-S VRF, matching an 1212 extranet C-source that is allowed by policy to transmit to VPN-R. 1213 Then R1 MUST carry the Outgoing Extranet RT used for the S-to-R 1214 extranet. This will cause the route to be imported into the VPN-R 1215 VRFs that have extranet C-receivers that are allowed by policy to 1216 receive from VPN-S. 1218 The rules of Section 3 regarding route targets and ambiguous 1219 addresses still apply. 1221 6.2. Single PMSI per C-flow Model 1223 In this model, if a VPN-S VRF has extranet multicast C-sources, and a 1224 VPN-R VRF has extranet multicast C-receivers allowed by policy to 1225 receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins 1226 the MI-PMSI that VPN-S uses for its non-extranet traffic. 1228 6.2.1. Forming the MI-PMSIs 1230 Consider a VPN-S VRF that has extranet C-sources. Per [MVPN], each 1231 VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing a 1232 PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as 1233 part of the VPN-S MI-PMSI. In the absence of extranet service, this 1234 route carries the VRF's non-extranet RT, RT-S. When extranet service 1235 is provided (using the "single PMSI per C-flow" model), this route 1236 MUST also carry EACH of the VRF's Outgoing Extranet RTs. 1238 Consider a VPN-R VRF that has extranet C-receivers. Per [MVPN], each 1239 VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing a 1240 PTA specifying the P-tunnel to be used as part of the VPN-R MI-PMSI. 1241 This route carries the VRF's non-extranet RT RT-R. When extranet 1242 service is provided (using the "single PMSI per C-flow" model), the 1243 VPN-R VRF MUST also originate one or more additional Intra-AS I-PMSI 1244 A-D routes. It MUST originate one additional Intra-AS I-PMSI A-D 1245 route for each Incoming Extranet RT with which it has been 1246 configured; each such route will carry exactly one of the configured 1247 Incoming Extranet RTs. 1249 Note that when a VRF originates more than one Intra-AS I-PMSI A-D 1250 route, each of them MUST contain a different RD in its NLRI. In 1251 addition, we add the requirement that any pair of such routes MUST 1252 NOT contain an RT in common. 1254 A VRF with extranet C-sources MUST join the P-tunnels advertised in 1255 the imported I-PMSI A-D routes that carry its non-extranet RT or any 1256 of its Outgoing Extranet RTs. This set of P-tunnels will be treated 1257 as instantiating a single MI-PMSI, and the associated PIM C-instance 1258 will treat that MI-PMSI as a single LAN, and will run PIM procedures 1259 on that LAN, as specified in [MVPN]. The fact that the MI-PMSI 1260 attaches to VRFs of different VPNs is not known to the PIM C-instance 1261 of the VRF containing the sources. 1263 A VRF with extranet C-receivers MUST join the P-tunnels advertised in 1264 all the imported I-PMSI A-D routes. The set of P-tunnels advertised 1265 in the I-PMSI A-D routes that carry a particular Incoming Extranet RT 1266 are treated as instantiating a particular MI-PMSI. So a VRF with 1267 C-receivers will "see" several MI-PMSIs, one corresponding to the 1268 non-extranet, and as many as one for each configured Incoming 1269 Extranet RT. The PIM C-instance associated with the VRF will treat 1270 each of these MI-PMSIs as a separate LAN interface. 1272 As an example, suppose: 1274 - All VPN-R VRFs are configured with RT-R as a non-extranet import 1275 and export RT, 1277 - VPN-R VRFs with extranet receivers are configured with RT-S-to-R 1278 as an Incoming Extranet RT, 1280 - VPN-S VRFs with extranet transmitters are configured: 1282 * with RT-S as a non-extranet import and export RT 1284 * with a list of IP addresses that are the addresses of the 1285 extranet sources 1287 * with RT-S-to-R as an Outgoing Extranet RT 1289 Then VPN-S VRFs will export UMH-eligible routes matching extranet 1290 C-sources, and these routes will carry both RT-S and RT-S-to-R. Each 1291 VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries 1292 both RT-S and RT-S-to-R. 1294 VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes: 1295 one carrying RT-R, and one carrying RT-S-to-R. The Intra-AS I-PMSI 1296 A-D route with RT-S-to-R will be imported into the VPN-S VRFs. 1298 VPN-R will regard all the I-PMSI A-D routes it has exported or 1299 imported with RT-S-to-R as part of a single MI-PMSI. VPN-R will 1300 regard all the I-PMSI A-D routes it has exported or imported with 1301 RT-R as part of a second MI-PMSI. The PIM C-instance associated with 1302 a VPN-R VRF will treat the two MI-PMSIs as two separate LAN 1303 interfaces. However, the VPN-S VRFs will regard all the I-PMSI A-D 1304 routes imported with RT-S or RT-S-to-R as establishing only a single 1305 MI-PMSI. One can think of this as follows: the VPN-R VRFs have joined 1306 the VPN-S MI-PMSI, as well as the VPN-R MI-PMSI. 1308 Extranets consisting of more than two VPNs are easily supported as 1309 follows. Suppose there are three VPNs, VPN-A, VPN-B, and VPN-C. 1310 VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers 1311 for both VPN-A extranet C-sources and VPN-B extranet C-sources. In 1312 this case, the VPN-C VRFs that have receivers for both VPN-A and 1313 VPN-B sources may be provisioned as follows. These VPN-C VRFs may be 1314 provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and 1315 RT-B-to-C as Incoming Extranet RTs. In this case, the VPN-C VRFs 1316 that are so provisioned will originate three Intra-AS I-PMSI A-D 1317 routes (each with a different RD in its NLRI), each of which carries 1318 exactly one of the three RTs just mentioned. The VPN-B VRFs with 1319 extranet C-sources will be provisioned with RT-B-to-C as an Outgoing 1320 Extranet RT, and the VPN-A VRFs are provisioned with RT-A-to-C as an 1321 Outgoing Extranet RT. The result will be that the PIM C-instance 1322 associated with a VPN-C VRF will see three LAN interfaces: one for 1323 the non-extranet, one for each of the two extranets. This 1324 generalizes easily to the case where there are VPN-C receivers in n 1325 different extranets (i.e., receiving extranet flows whose sources are 1326 in n different VPNs). 1328 Suppose again that there are there are three VPNs, VPN-A, VPN-B, and 1329 VPN-C. But in this example, VPN-A is the only one with extranet 1330 sources, while VPN-B and VPN-C both have receivers for the VPN-A 1331 extranet sources. This can be provisioned as either one extranet or 1332 as two. 1334 To provision it as one extranet, the VPN-A VRFs are configured with 1335 one Outgoing Extranet RT, call it "RT-A-extranet". The VPN-B and 1336 VPN-C VRFs with extranet receivers will be provisioned with 1337 RT-A-extranet as Incoming Extranet RT. Thus the VPN-B and VPN-C VRFs 1338 will each originate two Intra-AS I-PMSI A-D routes, one for non- 1339 extranet, and one for the extranet. The Intra-AS I-PMSI A-D route, 1340 from a given VRF, for the extranet will carry RT-A-extranet, but will 1341 not share any RT with the non-extranet A-D routes exported from the 1342 same VRF. 1344 The result is that the VPN-B and VPN-C VRFs each belong to two 1345 MI-PMSIs, one for the extranet and one for the intranet. The MI-PMSI 1346 for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs. 1348 Alternatively, one could provision the VPN-A VRFs so that some 1349 UMH-eligible extranet source routes carry an RT which we will call 1350 "RT-A-to-B", and some carry an RT which we will call "RT-A-to-C". 1351 The VPN-A VRFs would be configured with both of these as Outgoing 1352 Extranet RTs. To allow an extranet flow from a VPN-A source to have 1353 both VPN-B and VPN-C receivers, the UMH-eligible route for that 1354 source would carry both RTs. VPN-B VRFs (but not VPN-C VRFs) would 1355 be provisioned with RT-A-to-B as an Incoming Extranet RT. VPN-C VRFs 1356 (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an an 1357 Incoming Extranet RT. 1359 Following the rules above, if any VPN-A extranet source is to have 1360 both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each 1361 originate two I-PMSI A-D routes, one for extranet and one for non- 1362 extranet. The single Intra-AS I-PMSI A-D route originated by the 1363 VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as 1364 well as VPN-A's non-extranet RT). The extranet I-PMSI A-D route 1365 originated from a VPN-B VRF would have RT-A-to-B, and the extranet 1366 I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C. 1368 If a given VRF contains both extranet C-receivers and extranet 1369 C-sources, the procedures described above still work, as the VRF will 1370 be configured with both Incoming Extranet RTs and Outgoing Extranet 1371 RTs; the VRF functions both as a VPN-S VRF and as a VPN-R VRF. 1373 6.2.2. S-PMSIs 1375 When PIM is used as the PE-PE C-multicast control plane, every S-PMSI 1376 is considered to be part of the "emulated LAN" that "corresponds" to 1377 a particular MI-PMSI. 1379 When the bindings of C-flows to particular S-PMSIs are announced via 1380 S-PMSI Join Messages ([MVPN], Section 7) sent on the MI-PMSI, the 1381 S-PMSI is considered to be part of the same LAN interface as the 1382 corresponding MI-PMSI. 1384 When the bindings of C-flows to particular S-PMSIs are announced via 1385 S-PMSI A-D routes, then any S-PMSI A-D route exported from that VRF 1386 MUST have an RT in common with exactly one of the Intra-AS A-D routes 1387 exported from that VRF, and this MUST be one of the VRF's Outgoing 1388 Extranet RTs. Further, the S-PMSI A-D route MUST NOT have an RT in 1389 common with any other Intra-AS A-D route exported from a VRF on the 1390 same PE. A given S-PMSI A-D route will be considered to "correspond" 1391 to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the 1392 same PE) with which it shares an RT. 1394 The MI-PMSI that corresponds to a given S-PMSI is determined as 1395 follows: 1397 - If there is an Intra-AS I-PMSI A-D route originated by the same 1398 PE that originated the S-PMSI A-D route, and if the those two 1399 routes have an RT in common, and if that RT is one of the VRF's 1400 Incoming Extranet RTs, then the S-PMSI corresponds to the I-PMSI 1401 associated with that Intra-AS I-PMSI A-D route. 1403 - Otherwise, if there is an Inter-AS I-PMSI A-D route originated in 1404 the same AS as the S-PMSI A-D route, and if the those two routes 1405 have an RT in common, and if that RT is one of the VRF's Incoming 1406 Extranet RTs, then the S-PMSI corresponds to the I-PMSI 1407 associated with that Inter-AS I-PMSI A-D route. 1409 - Otherwise, there must be a configuration error (a violation of 1410 the requirements of Sections 3-5 of this document). 1412 When wildcard S-PMSIs are used, the rules given in [MVPN-WILDCARDS] 1413 for determining whether a given S-PMSI A-D route is a "match for 1414 reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows: 1416 A given S-PMSI A-D route MUST NOT be considered to be a "match 1417 for reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS 1418 that S-PMSI A-D route "corresponds" (as defined above) to the 1419 MI-PMSI that is the incoming interface for the given state. 1421 The rules given in [MVPN-WILDCARDS] for determining whether a given 1422 S-PMSI A-D route is a "match for transmission" are unchanged. 1424 6.2.3. Sending PIM Control Packets 1426 Suppose a PE, say PE1, receives a PIM Join(S,G) from a CE, over a VRF 1427 interface that is associated with a VPN-R VRF. The PE does the RPF 1428 check for S by looking up S in the VPN-R VRF. The PIM C-instance 1429 associated with that VRF must determine the correct P-tunnel over 1430 which to send a PIM Join(S,G) to other PEs. 1432 To do this, PE1 finds, in the VRF associated with the interface over 1433 which the Join was received, the selected UMH route for S, following 1434 the procedures of section 5.1 of [MVPN]. PE1 determines the set of 1435 RTs carried by that route. PE1 then checks to see if there is an 1436 Intra-AS I-PMSI A-D route, currently originated by PE1, that has an 1437 RT in common with the selected UMH route for S. 1439 If the rules of Sections 3-5 have been followed, each of PE1's 1440 selected UMH routes will share an RT with a single one of PE1's 1441 currently originated Intra-AS I-PMSI A-D routes. If this is so, the 1442 Join is sent on the P-tunnel advertised in the PTA of that route. 1443 Otherwise, the Join MUST NOT be sent. 1445 In essence, this procedure makes the RPF check for C-S resolve to the 1446 MI-PMSI that is serving as the next hop "interface" to C-S. 1448 If a PE receives a PIM Join(*,G) from a CE, the procedure for doing 1449 the RPF check is the same, except that the selected UMH route will be 1450 a route to the C-RP associated with the C-G group. 1452 6.2.4. Receiving PIM Control Packets 1454 When a PIM C-instance receives a PIM control message from a P-tunnel, 1455 it needs to identify the message's "incoming interface". This 1456 incoming interface is the MI-PMSI of which the P-tunnel is a part. 1458 6.2.5. Sending and Receiving Data Packets 1460 The rules for choosing the PMSI on which to send a multicast data 1461 packet are as specified in [MVPN] and [MVPN-WILDCARDS], with one new 1462 restriction: a VPN-S VRF always transmits a multicast data packet 1463 either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the 1464 VPN-S MI-PMSI. From the perspective of the PIM C-instance, there is 1465 only one outgoing interface. 1467 When a PIM C-instance receives a multicast data packet from a given 1468 P-tunnel, and that P-tunnel is being used to instantiate an MI-PMSI, 1469 the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and 1470 6.2.2) is considered to be the packet's "incoming interface". If the 1471 packet is received on a P-tunnel that was advertised in an S-PMSI A-D 1472 route, the packet's "incoming interface" is the MI-PMSI to which that 1473 S-PMSI route corresponds, as defined in Section 6.2.2. Ordinary PIM 1474 rules for data plane RPF check apply. 1476 Following ordinary PIM procedures, packets arriving from an 1477 unexpected incoming interface are discarded. This eliminates any 1478 problems due to the ambiguities described in Sections 2.1 and 2.2. 1480 6.3. Multiple PMSIs per C-flow Model 1482 In this model, if a VPN-S VRF has extranet multicast C-sources, and a 1483 VPN-R VRF has extranet multicast C-receivers allowed by policy to 1484 receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins 1485 the MI-PMSI that VPN-R uses for its non-extranet traffic. 1487 In the "single PMSI per C-flow" transmission model (as described in 1488 Section 6.2), a PE that needs to transmit a multicast data packet to 1489 a set of other PEs transmits the packet on a single PMSI. This means 1490 that if a packet needs to be transmitted from a VPN-A VRF and 1491 received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel 1492 from which the VPN-B and VPN-C VRFs can both receive packets. 1494 In the "multiple PMSIs per C-flow" transmission model, a PE that 1495 needs to transmit a multicast data packet to a set of other PEs may 1496 transmit the packet on several different PMSIs. (Of course, any 1497 given packet is transmitted only once on a given P-tunnel.) For 1498 example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B 1499 receiver, and a VPN-C receiver, there could be one PMSI that the 1500 VPN-A VRF uses to transmit the packet to the VPN-B VRFs, and another 1501 PMSI that the VPN-A VRF uses to transmit the packet to the VPN-C 1502 VRFs. 1504 6.3.1. Forming the MI-PMSIs 1506 Consider a VPN-R VRF that has extranet C-receivers. Per [MVPN], each 1507 VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing a 1508 PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as 1509 part of the VPN-R MI-PMSI. In the absence of extranet service, this 1510 route carries the VRF's non-extranet RT, RT-R. When extranet service 1511 is provided (using the "single PMSI per C-flow" model), this route 1512 MUST also carry each of the VRF's Incoming Extranet RTs. 1514 Consider a VPN-S VRF that has extranet C-sources. Per [MVPN], each 1515 VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing a 1516 PTA specifying the P-tunnel to be used as part of the VPN-S MI-PMSI. 1517 This route carries the VRF's non-extranet RT RT-S. When extranet 1518 service is provided using the "multiple PMSI per C-flow" model, the 1519 VPN-S VRF MUST also originate one or more additional Intra-AS I-PMSI 1520 A-D routes. It MUST originate one additional Intra-AS I-PMSI A-D 1521 route for each outgiong extranet RT with which it has been 1522 configured; each such route will have a distinct RD, and will carry 1523 exactly one of the configured Outgoing Extranet RTs. 1525 As with the "single PMSI per C-flow" transmission model, VRFs 1526 containing extranet C-receivers need to import UMH-eligible extranet 1527 C-source routes from VRFs containing C-sources. This is ensured by 1528 the rules of Sections 3-5. 1530 However, in the "multiple PMSIs per C-flow model", a VRF containing 1531 only C-receivers originates only a single Intra-AS I-PMSI A-D route, 1532 carrying the non-extranet RT and all the Incoming Extranet RTs. 1534 When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes 1535 that carry the non-extranet RT or one of the Incoming Extranet RTs, 1536 the P-tunnels specified in the PTA of all such routes are considered 1537 to be part of the same MI-PMSI. I.e., the associated PIM C-instance 1538 will treat them as part of a single interface. 1540 In this model, it is the VRF containing extranet C-sources that must 1541 originate multiple Intra-AS I-PMSI A-D routes. Each such route must 1542 have a distinct RD, and the set of RTs carried by any one of these 1543 routes must be disjoint from the set carried by any other. There 1544 must be one such route for each of the VRF's Outgoing Extranet RTs, 1545 and Each such route must carry exactly one of the VRF's Outgoing 1546 Extranet RTs. The VRFs containing extranet C-sources MUST also 1547 import all the A-D routes originated by the VRFs containing extranet 1548 C-receivers. If a set of originated and/or imported Intra-AS I-PMSI 1549 A-D routes have an RT in common, and that RT is one of the VRF's 1550 Outgoing Export RTs, then those routes are considered to be "about" 1551 the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI 1552 as a LAN Interface. 1554 In effect, if VPN-S has only extranet C-sources and VPN-R has only 1555 extranet C-receivers, this model has the VPN-S VRFs join the VPN-R 1556 MI-PMSI. The VPN-S VRFs will thus be attached to multiple MI-PMSIs, 1557 while the VPN-R VRFs are attached to only one. The fact that the 1558 VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM 1559 C-instance at the VPN-R VRFs. 1561 If a VPN-A VRF has extranet C-sources allowed to send to C-receivers 1562 in a VPN-B VRF, and the VPN-B VRF has C-sources allowed to send to 1563 C-receivers in the VPN-A VRF, the above procedures still work as 1564 specified. 1566 Following normal PIM procedures, when the PIM C-instance at a VRF 1567 with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G) 1568 over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the 1569 MI-PMSI over which the Join was received may be added to the set of 1570 outgoing interfaces for that multicast state. If n MI-PMSIs are 1571 added to the outgoing interface list for a particular multicast 1572 state, a multicast data packet may need to be replicated n times, and 1573 transmitted once on each of the n MI-PMSIs. 1575 Since the all multicast data packets received from another PE are 1576 received over a single emulated LAN, it is not necessary to have any 1577 special procedures to determine a packet's "incoming interface". The 1578 ambiguities described in Section 2.1 and 2.2 do not occur, because a 1579 VPN-R VRF can only receive multicast data traffic that has been 1580 requested by a VPN-R VRF. 1582 7. When BGP is the PE-PE C-multicast Control Plane 1584 This document assumes that if BGP is used as the PE-PE C-multicast 1585 control plane, the "Single PMSI per C-flow" model is used. 1586 Procedures for providing the "Multiple PMSIs per C-flow" model with 1587 BGP C-multicast are outside the scope of this document. 1589 When BGP is used as the C-multicast control plane, the Single PMSI 1590 per C-flow model may be used either with or without "extranet 1591 separation". (Recall that "extranet separation" means that no 1592 P-tunnel can carry both traffic from extranet sources and traffic 1593 from non-extranet sources.) In either case, the data traffic may be 1594 carried on inclusive tunnels only, or on selective tunnels only 1595 (known as the "S-PMSI only" model), or on a combination of inclusive 1596 and selective tunnels. This is determined by provisioning. The 1597 procedures specified below support all three choices. 1599 Note that there are no special extranet procedures for Inter-AS 1600 I-PMSI A-D routes or for Leaf A-D routes. 1602 7.1. Originating C-multicast Routes 1604 This section applies whether extranet separation is used or not. 1606 Procedures specified in Section 11.1.3 ("Constructing the rest of the 1607 C-multicast route") of [MVPN-BGP] are modified as follows. If the 1608 local and the upstream PEs are in different ASes, then the local PE 1609 has to find in its VRF not just an Inter-AS I-PMSI A-D route whose 1610 Source AS field carries the autonomous system number of the upstream 1611 PE (as specified in Section 11.1.3 of [MVPN-BGP]), but an Inter-AS 1612 I-PMSI A-D route whose Source AS field carries the autonomous system 1613 number of the upstream PE, and whose RTs form a non-empty 1614 intersection with the RTs carried by the selected UMH route for the 1615 address carried in the Multicast Source field of MCAST-VPN NLRI. 1617 7.2. Originating A-D Routes Without Extranet Separation 1619 7.2.1. Intra-AS I-PMSI A-D Routes 1621 Consider a VRF, call it VRF-S, that contains extranet C-sources, and 1622 that exports UMH-eligible routes matching those C-sources. The VRF 1623 may also originate and export an Intra-AS I-PMSI A-D route. 1625 As specified in [MVPN-BGP], if exactly one Intra-AS I-PMSI A-D route 1626 is originated by and exported from VRF-S, the RTs carried by that 1627 route MUST be chosen such that every VRF that imports a UMH-eligible 1628 route from VRF-S also imports this Intra-AS I-PMSI A-D route. 1630 If inclusive P-tunnels are being used to carry extranet C-flows, 1631 there are additional requirements on the way the RTs carried by the 1632 Intra-AS I-PMSI A-D routes must be chosen, as specified in the 1633 following paragraph. 1635 If VRF-S is using Inclusive P-tunnels, but is not using extranet 1636 separation, there is one inclusive P-tunnel rooted at VRF-S, and this 1637 tunnel carries both extranet and non-extranet C-flows. This 1638 inclusive tunnel is identified in the PMSI Tunnel Attribute (PTA) of 1639 the Intra-AS I-PMSI A-D route originated from VRF-S. The set of RTs 1640 carried by this Intra-AS I-PMSI A-D route MUST be chosen so as to 1641 ensure that every VRF that imports a UMH-eligible route from this 1642 VRF-S also imports this Intra-AS I-PMSI A-D route. Further, the set 1643 of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen such 1644 that it has at least one RT in common with every UMH-eligible route 1645 that is exported from the VRF. 1647 7.2.2. S-PMSI A-D Routes 1649 Suppose that a given S-PMSI A-D route, exported from VRF-S, is used 1650 to bind some or all of the extranet C-flows from a given extranet 1651 C-source to a given selective P-tunnel. (This includes S-PMSI A-D 1652 routes that use wildcards [MVPN-WILDCARDS]). That S-PMSI A-D route 1653 MUST have at least one RT in common with each of the UMH-eligible 1654 routes that is exported from VRF-S and that matches the given 1655 extranet C-source. Further, the RTs MUST be such that every VRF that 1656 imports one of these UMH-eligible routes also imports the S-PMSI A-D 1657 route. 1659 An implementation MUST allow the set of RTs carried by the S-PMSI A-D 1660 routes to be specified by configuration. In the absence of such 1661 configuration, an S-PMSI A-D route originated by a given VRF X MUST 1662 carry a default set of RTs, as specified by the following rules: 1664 1. By default an S-PMSI A-D route originated by VRF X for a given 1665 (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the 1666 UMH-eligible route originated by VRF X that matches C-S. 1668 2. By default an S-PMSI A-D route originated by VRF X for a given 1669 (C-*,C-G) carries as its RTs a set union of all RT(s) of the 1670 UMH-eligible route(s) matching the multicast C-sources 1671 contained in VRF X that could originate traffic for that C-G. 1672 Moreover, if the VRF contains (as defined in section 1.1) the 1673 C-RP of C-G, then this set union also includes the RT(s) of the 1674 UMH-eligible route matching C-RP, and of the unicast VPN-IP 1675 route matching C-RP. 1677 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF X 1678 is to be used for both extranet and non-extranet traffic, it 1679 carries the same RTs that would be carried (as specified in 1680 section 7.2.1) by an I-PMSI A-D route originated by VRF X if 1681 that I-PMSI A-D route were advertising an inclusive P-tunnel 1682 for carrying both extranet and non-extranet traffic. In 1683 general, a given VRF would not originate both (a) an S-PMSI A-D 1684 route advertising a (C-*,C-*) selective P-tunnel for both 1685 extranet and non-extranet traffic and (b) an I-PMSI A-D route 1686 advertising an inclusive P-tunnel for both extranet and non- 1687 extranet traffic, as the inclusive P-tunnel would not get used 1688 in that case. 1690 7.2.3. Source Active A-D Routes 1692 If VRF-S exports a Source Active A-D route that contains C-S in the 1693 Multicast Source field of its NLRI, and if that VRF also exports a 1694 UMH-eligible route matching C-S, the Source Active A-D route MUST 1695 carry at least one RT in common with the UMH-eligible route. The RT 1696 must be chosen such that the following condition holds: if VRF-R 1697 contains an extranet C-receiver allowed by policy to receive extranet 1698 traffic from C-S, then VRF-R imports both the UMH-eligible route and 1699 the Source Active A-D route. 1701 By default, a Source Active A-D route for a given (C,S,C-G), exported 1702 by a given VRF, carries the same set of RTs as the UMH-eligible route 1703 matching C-S that is exported from that VRF. 1705 7.3. Originating A-D Routes With Extranet Separation 1707 7.3.1. Intra-AS I-PMSI A-D Routes 1709 This section applies when VRF-S is using extranet separation, AND 1710 when VRF-S is using an Inclusive P-tunnel to carry some or all of the 1711 extranet C-flows that it needs to transmit to other VRFs. 1713 If VRF-S contains both extranet C-sources and non-extranet C-sources, 1714 and if inclusive P-tunnels are used to carry both extranet C-flows 1715 and non-extranet C-flows, then there MUST be two inclusive tunnels 1716 from VRF-S, one of which is to be used only to carry extranet C-flows 1717 (the "extranet inclusive P-tunnel"), and one of which is to be used 1718 only to carry non-extranet C-flows (the "non-extranet inclusive 1719 P-tunnel"). In this case, the VRF MUST originate two Intra-AS I-PMSI 1720 A-D routes. Their respective NLRIs must of course have different 1721 RDs. One of the Intra-AS I-PMSI A-D routes identifies the extranet 1722 inclusive P-tunnel in its PTA, the other identifiers the non-extranet 1723 Inclusive P-tunnel in its PTA. 1725 If VRF-S uses an Inclusive P-tunnel for carrying extranet traffic, 1726 but does not use an Inclusive P-tunnel for carrying non-extranet 1727 traffic, then of course only a single Intra-AS I-PMSI A-D route need 1728 be originated. The PTA of this route identifies the "extranet 1729 inclusive P-tunnel". 1731 The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies 1732 the "extranet inclusive P-tunnel" MUST be chosen such that the 1733 following conditions hold: 1735 * If a VRF (call it VRF-R) imports a UMH-eligible route from VRF-S, 1736 and if that route matches an extranet C-source, then VRF-R also 1737 imports that Intra-AS I-PMSI A-D route. 1739 * The Intra-AS I-PMSI A-D route from VRF-S whose PTA identifies the 1740 extranet inclusive P-tunnel MUST carry ALL the RTs that are 1741 carried by any route exported from VRF-S that is a UMH-eligible 1742 route matching a non-extranet C-source. 1744 These procedures generalize easily to the case where there are n 1745 inclusive P-tunnels from VRF-S. One such P-tunnel is used to carry 1746 flows from non-extranet C-sources. The other n-1 inclusive P-tunnels 1747 are used as follows. The set of extranet C-sources is partitioned 1748 into n-1 non-intersecting sets. Each such set is associated (by 1749 provisioning) to one such P-tunnel. A particular inclusive P-tunnel 1750 is then used to carry only those extranet C-flows whose C-sources (or 1751 C-RPs) are in the corresponding set. 1753 In this case, a given Intra-AS I-PMSI A-D route MUST carry ALL the 1754 RTs that are carried by any of the UMH-eligible routes in the 1755 corresponding set. 1757 Note that when extranet separation is used, it is possible to use an 1758 inclusive P-tunnel for non-extranet traffic while using only 1759 selective P-tunnels for extranet traffic. It is also possible to use 1760 an inclusive P-tunnel for extranet traffic while using only selective 1761 P-tunnels for non-extranet traffic. 1763 7.3.2. S-PMSI A-D Routes 1765 Suppose that a given S-PMSI A-D route, exported from VRF-S, is used 1766 to bind some or all of the extranet C-flows from a given extranet 1767 C-source to a given selective P-tunnel. (This includes S-PMSI A-D 1768 routes that use wildcards [MVPN-WILDCARDS]). That S-PMSI A-D route 1769 MUST have at least one RT in common with each of the UMH-eligible 1770 routes, exported from VRF-S, that matches the given extranet 1771 C-source. Further, the RTs MUST be such that every VRF that imports 1772 one of these UMH-eligible routes also imports the S-PMSI A-D route. 1774 The following rules, specific to the use of extranet separation, 1775 apply: 1777 - A selective P-tunnel MUST NOT carry C-flows from both extranet 1778 and non-extranet C-sources, 1780 - If it is desired to use a (C-*,C-*) S-PMSI to carry extranet 1781 traffic and also to use a (C-*,C-*) S-PMSI to carry non-extranet 1782 traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated. 1783 These two routes MUST have different RDs in their respective NLRI 1784 fields, and their respective PTAs MUST identify different 1785 P-tunnels. 1787 An implementation MUST allow the set of RTs carried by the S-PMSI A-D 1788 routes to be specified by configuration. In the absence of such 1789 configuration, an S-PMSI A-D route originated by a given VRF X MUST 1790 carry a default set of RTs, as specified by the following rules: 1792 1. Rule 1 of section 7.2.2 applies. 1794 2. By default, if C-G is an extranet C-group, rule 2 of section 1795 7.2.2 applies. 1797 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF X 1798 is to be used for extranet traffic, it carries the same RTs 1799 that would be carried (as specified in section 7.3.1) by an 1800 I-PMSI A-D route originated by VRF X if that I-PMSI A-D route 1801 were advertising an inclusive P-tunnel for carrying extranet 1802 traffic. In general, a given VRF would not originate both an 1803 S-PMSI A-D route advertising a (C-*,C-*) selective P-tunnel for 1804 extranet traffic and an I-PMSI A-D route advertising an 1805 inclusive P-tunnel for extranet traffic, as the inclusive 1806 P-tunnel would not get used in that case. 1808 7.3.3. Source Active A-D Routes 1810 The procedures of Section 7.2.3 apply. 1812 7.4. Determining the Expected P-tunnel for a C-flow 1814 This section applies whether extranet separation is used or not. 1816 In the context of a VRF with receivers for a particular C-flow, a PE 1817 must determine the P-tunnel over which packets of that C-flow are 1818 expected to arrive. This is done by finding an I-PMSI or S-PMSI A-D 1819 route that "matches" the flow. The matching A-D route will contain a 1820 PTA that specifies the P-tunnel being used to carry the traffic of 1821 that C-flow. We will refer to this P-tunnel as the "expected 1822 P-tunnel" for the C-flow. 1824 A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST 1825 join the expected P-tunnel for that C-flow, and the PE MUST remain 1826 joined to the P-tunnel as long as the PE continues to need to receive 1827 the given C-flow, and the P-tunnel continues to remain the expected 1828 P-tunnel for that C-flow. 1830 If a PTA specifies a non-zero MPLS label, then the PE originating the 1831 A-D route containing that PTA is advertising an aggregate P-tunnel. 1832 The aggregate P-tunnel can be thought of as an outer P-tunnel 1833 multiplexing some number of inner P-tunnels. The inner P-tunnels are 1834 demultiplexed by means of the MPLS label in the PTA. In this 1835 document, when we talk of the "expected P-tunnel" in the context of 1836 an aggregate P-tunnel, we refer to a particular inner P-tunnel, not 1837 to the outer P-tunnel. It is this "inner P-tunnel" that is the 1838 expected P-tunnel for a given C-flow. 1840 In order to find the expected P-tunnel for a given C-flow, the 1841 upstream PE of the C-flow is first determined. Then the S-PMSI A-D 1842 routes originated by that PE are examined, and their NLRIs compared 1843 to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for 1844 reception". (If there is no S-PMSI A-D route that matches a given C- 1845 flow, the expected P-tunnel for that C-flow may have been advertised 1846 in an I-PMSI A-D route; see section 7.4.5.) 1848 The rules for determining, in non-extranet cases, whether a given 1849 C-flow is a "match for reception" for a given S-PMSI A-D route are 1850 given in [MVPN-WILDCARDS] Section 3.2. Note that we use the terms 1851 "installed" and "originated" as they are defined in [MVPN-WILDCARDS] 1852 Section 3.2. (See also Section 1.1 of this document.) 1854 This specification adds additional rules for determining whether a 1855 given S-PMSI A-D route is a "match for reception" for a given 1856 (C-S/C-RP,C-G). Note that these rules all assume the context of a 1857 particular VRF into which the A-D route has been imported. 1859 The rules given in [MVPN-WILDCARDS] for determining whether a given 1860 S-PMSI A-D route is a "match for transmission" remain unchanged. 1862 Under certain conditions, the upstream PE for a given (C-S,C-G) flow 1863 is determined by examining the Source Active A-D routes that have 1864 (C-S,C-G) encoded in their NLRI fields. When extranet functionality 1865 is being provided, an SA A-D route is considered to "match" a 1866 (C-S,C-G) flow, in the context of a given VRF with receivers for that 1867 flow, only if the selected UMH route to C-S has at least one RT in 1868 common with the SA A-D route, and at least one of the RTs in common 1869 is an import RT of the VRF. Once the upstream PE is selected, the 1870 P-tunnel over which the flow is expected is determined according to 1871 the procedures already described in this section. 1873 7.4.1. (C-S,C-G) S-PMSI A-D Routes 1875 When extranet functionality is being provided, an S-PMSI A-D route 1876 whose NLRI contains (C-S,C-G) is NOT considered to be a "match for 1877 reception" for a given C-flow (C-S,C-G) unless one of the following 1878 conditions holds (in addition to the conditions specified in 1879 [MVPN-WILDCARDS]): 1881 - the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is 1882 provisioned, or 1884 - the selected UMH route for C-S has at least one RT in common with 1885 the S-PMSI A-D route, and at least one of the common RTs is an 1886 import RT of the VRF. 1888 7.4.2. (C-S,C-*) S-PMSI A-D Routes 1890 When extranet functionality is being provided, an S-PMSI A-D route 1891 whose NLRI contains (C-S,C-*) is NOT considered to be a "match for 1892 reception" for a given C-flow (C-S,C-G) unless one of the following 1893 conditions holds, in addition to the conditions specified in 1894 [MVPN-WILDCARDS]: 1896 - the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is 1897 provisioned, or 1899 - the selected UMH route for C-S has at least one RT in common with 1900 the S-PMSI A-D route, and at least one of the common RTs is an 1901 import RT of the VRF. 1903 7.4.3. (C-*,C-G) S-PMSI A-D Routes 1905 When extranet functionality is being provided, an S-PMSI A-D route 1906 whose NLRI contains (C-*,C-G) is NOT considered to be a "match for 1907 reception" for a given C-flow (C-S,C-G) in a given VRF unless either 1908 condition 1 or condition 2 below holds, in addition to the conditions 1909 specified in [MVPN-WILDCARDS]: 1911 1. The given VRF has currently originated a C-multicast Shared 1912 Tree Join route for (C-*,C-G), and 1914 a) (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route 1915 (according to [MVPN-WILDCARDS]) in the given VRF, and 1917 b) either 1919 i) the "Single C-group per (C-*,C-G) P-tunnel" 1920 policy has been provisioned, or 1922 ii) the RTs of that S-PMSI A-D route form a non-empty 1923 intersection with the RTs carried in the VRF's 1924 selected UMH route for C-RP of that C-G, or 1926 iii) there are one or more Source Active A-D routes 1927 for (C-S,C-G) installed in the VRF, where these 1928 routes have been originated by the same PE as the 1929 (C-*,C-G) S-PMSI A-D route, and the RTs of the 1930 (C-*,C-G) S-PMSI A-D route form a non-empty 1931 intersection with the RTs of one or more of the 1932 selected UMH-eligible routes for C-S. 1934 2. The given VRF does not have a currently originated C-multicast 1935 Shared Tree Join for (C-*,C-G), but 1937 a) there are one or more values for C-S for which the VRF 1938 has a currently originated Source Tree Join C-multicast 1939 route for (C-S,C-G), and 1941 b) the (C-* C-G) S-PMSI A-D route matches (according to 1942 [MVPN-WILDCARDS]) each such (C-S,C-G), and 1944 c) either 1946 i) the "Single C-group per (C-*,C-G) P-tunnel" 1947 policy has been provisioned, or 1949 ii) the RTs of that S-PMSI A-D route form a non-empty 1950 intersection with the RTs carried in the VRF's 1951 selected UMH routes for each such C-S 1953 If a VRF has an installed (C-*,C-G) S-PMSI A-D route, but does 1954 not have a (C-S,C-G) or (C-*,C-G) multicast state that matches 1955 that route for reception, the procedures of section 12.3 1956 ("Receiving S-PMSI A-D Routes by PEs") of [MVPN-BGP] are not 1957 invoked for that route. If those multicast states are created 1958 at some later time when the route is still installed, the 1959 procedures of section 12.3 of [MVPN-BGP] are invoked at that 1960 time. 1962 7.4.4. (C-*,C-*) S-PMSI A-D Routes 1964 7.4.4.1. Without Extranet Separation 1966 A (C-*,C-*) S-PMSI A-D Route is NOT considered to be a match for 1967 reception for a given C-flow (C-S,C-G) or (C-*,C-G) unless the 1968 following condition holds (in addition to the conditions specified in 1969 [MVPN-WILDCARDS)]: 1971 - the selected UMH route for C-S or for C-G's C-RP respectively has 1972 at least one RT in common with the S-PMSI A-D route, and at least 1973 one of the common RTs is an import RT of the VRF. 1975 7.4.4.2. With Extranet Separation 1977 A (C-*,C-*) S-PMSI A-D Route is NOT considered to be a match for 1978 reception for a given C-flow (C-S,C-G) or (C-*,C-G) unless the 1979 following condition holds (in addition to the conditions specified in 1980 [MVPN-WILDCARDS)]: 1982 - all of the RTs carried by the selected UMH route for C-S or for 1983 C-G's C-RP respectively are also carried by the S-PMSI A-D route, 1984 and at least one of the common RTs is an import RT of the VRF. 1986 7.4.5. I-PMSI A-D Routes 1988 If the VRF contains no matching S-PMSI A-D routes for a C-flow, then 1989 the C-flow is expected to arrive on an Inclusive P-tunnel. 1991 Let R be the selected UMH route for the given C-flow. That is, if 1992 the C-flow is (C-S,C-G), R is the selected UMH route for C-S, while 1993 if the C-flow is (C-*,C-G), R is the selected UMH route for C-RP. 1994 The selected upstream PE for the flow is determined from the VRF 1995 Route Import RT of R. The "selected upstream AS" for the flow is 1996 determined from the Source AS Extended Community of R. 1998 7.4.5.1. Without Extranet Separation 2000 The inclusive P-tunnel that is expected to be carrying a particular 2001 C-flow is found as follows: 2003 - If the selected upstream AS is the local AS, then look in the VRF 2004 for an installed Intra-AS I-PMSI A-D route that is (a) originated 2005 by the selected upstream PE, (b) has at least one an RT in common 2006 with R, and (c) at least one of the common RTs is an import RT of 2007 the local VRF. The PTA of that Intra-AS I-PMSI A-D route 2008 specifies the P-tunnel over which traffic of the given C-flow is 2009 expected. 2011 - If the selected upstream AS is not the local AS, then look in the 2012 VRF for an installed Inter-AS I-PMSI A-D route such that (a) the 2013 Source AS field of its NLRI contains the AS number of the 2014 selected upstream AS, (b) it has at least one RT in common with 2015 R, and (c) at least one of the common RTs is an import RT of the 2016 local VRF. The PTA of that Inter-AS I-PMSI A-D route specifies 2017 the P-tunnel over which traffic of the given C-flow is expected. 2019 7.4.5.2. With Extranet Separation 2021 The inclusive P-tunnel that is expected to be carrying a particular 2022 C-flow is found as follows: 2024 - If the selected upstream AS is the local AS, then look in the VRF 2025 for an installed Intra-AS I-PMSI A-D route that is (a) originated 2026 by the selected upstream PE, (b) carries ALL of the RTs that are 2027 carried by R, and (c) at least one of the common RTs is an import 2028 RT of the local VRF. The PTA of that Intra-AS I-PMSI A-D route 2029 specifies the P-tunnel over which traffic of the given C-flow is 2030 expected. 2032 - If the selected upstream AS is not the local AS, then look in the 2033 VRF for an installed Inter-AS I-PMSI A-D route such that (a) the 2034 Source AS field of its NLRI contains the AS number of the 2035 selected upstream AS, (b) it carries all of the RTs that are 2036 carried by R, and (c) at least one of the common RTs is an import 2037 RT of the local VRF. The PTA of that Inter-AS I-PMSI A-D route 2038 specifies the P-tunnel over which traffic of the given C-flow is 2039 expected. 2041 7.5. Packets Arriving from the Wrong P-tunnel 2043 Any packets that arrive on P-tunnel other than the expected P-tunnel 2044 (as defined in Section 7.4) MUST be discarded. Note that packets 2045 arriving on the wrong P-tunnel are to be discarded even if they are 2046 arriving from the expected PE. 2048 8. Multiple Extranet VRFs on the same PE 2050 When multiple VRFs that contain extranet receivers for a given 2051 extranet source are present on the same PE, this PE becomes a single 2052 leaf of the P-tunnel used for sending (multicast) traffic from that 2053 source to these extranet receivers. The PE MUST be able to replicate 2054 this traffic to the multiple VRFs. Specific procedures for doing so 2055 are local to the PE, and outside the scope of this document. 2057 For a given extranet the site(s) that contain the extranet source(s) 2058 and the site(s) that contain the extranet receiver(s) may be 2059 connected to the same PE. In this scenario, the procedures by which 2060 (multicast) traffic from these sources is delivered to these 2061 receivers is a local matter to the PE, and outside the scope of this 2062 document. 2064 An implementation MUST support multiple extranet VRFs on a PE. 2066 9. IANA Considerations 2068 This document does not specify any actions for IANA. 2070 10. Security Considerations 2072 The security considerations of [MVPN] and [MVPN-BGP] are applicable. 2074 In general, different VPNs are allowed to have overlapping IP address 2075 spaces, i.e., a host in one VPN may have the same IP address as a 2076 host in another. This is safe because the customer routes from a 2077 given VPN do not pass into other VPNs. Even if there is overlapping 2078 address space among VPNs, the routes that are known at any given VPN 2079 site are unambiguous, as long as the address space of that VPN is 2080 unambiguous. However, this is not necessarily true when extranet 2081 service is provided. If an extranet C-receiver in VPN-R is to be 2082 able to receive multicast traffic from an extranet C-source in VPN-S, 2083 then the address of the VPN-S extranet C-source must be imported into 2084 one or more VPN-R VRFs. If that address is also the address of a 2085 VPN-R non-extranet C-source, then a system attempting to receive an 2086 extranet C-flow from the VPN-R extranet C-source may instead receive 2087 a non-extranet C-flow from the VPN-S C-source. This would result in 2088 a VPN security violation. 2090 To avoid this, this document specifies that if a route is imported 2091 into a given VRF, all addresses that are match that route must be 2092 unambiguous in the context of that VRF. Improper provisioning of the 2093 RTs may cause this rule to be violated, and hence result in a VPN 2094 security violation. 2096 It is possible that a given multicast C-source is the source of 2097 multiple flows, some of which are intended to be extranet C-flows, 2098 and some of which are intended to be non-extranet flows. However, 2099 the procedures of this document will allow any C-receiver that is 2100 able to receive the extranet C-flows from a given C-source to also 2101 receive the non-extranet C-flows from that source. As a result, VPN 2102 security violations may result if any system is a C-source for both 2103 extranet and non-extranet C-flows. However, the set of C-flows 2104 transmitted by a given C-source is not under the control of the SP. 2105 SPs who offer the extranet MVPN service must make sure that this 2106 potential for VPN security violations is clearly understood by the 2107 customers who administer the C-sources. 2109 This specification does not require that UMH-eligible routes be "host 2110 routes"; they may be less specific routes. So it is possible for the 2111 NLRI of a UMH-eligible route to contain an address prefix that 2112 matches the address of both an extranet C-source and a non-extranet 2113 C-source. If such a route is exported from a VPN-S VRF and imported 2114 by a VPN-R VRF, C-receivers contained in VPN-R will be able to 2115 receive C-flows from the non-extranet C-sources whose addresses match 2116 that route. This may result in VPN security violations. Service 2117 providers who offer the extranet MVPN service must make sure that 2118 this is clearly understood by the customers who administer the 2119 distribution of routes from CE to PE routers. 2121 If the address ambiguities described in Sections 2.1 and 2.2 are not 2122 prohibited by policy, VRFs MUST be able to discard traffic that 2123 arrives on the wrong P-tunnel; otherwise VPN security violations may 2124 occur. 2126 11. Acknowledgments 2128 The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini 2129 Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, Kurt 2130 Windisch, and Jeffrey (Zhaohui) Zhang. 2132 12. Authors' Addresses 2134 Rahul Aggarwal 2135 Juniper Networks 2136 1194 North Mathilda Ave. 2137 Sunnyvale, CA 94089 2138 Email: raggarwa_1@yahoo.com 2140 Yiqun Cai 2141 Microsoft 2142 1065 La Avenida 2143 Mountain View, CA 94043 2144 Email: yiqunc@microsoft.com 2146 Wim Henderickx 2147 Alcatel-Lucent 2148 Email: wim.henderickx@alcatel-lucent.com 2150 Thomas Morin 2151 France Telecom - Orange 2152 2, avenue Pierre-Marzin 2153 22307 Lannion Cedex 2154 France 2155 EMail: thomas.morin@orange.com 2157 Praveen Muley 2158 Alcatel-Lucent 2159 Email: Praveen.Muley@alcatel-lucent.com 2161 Ray (Lei) Qiu 2162 2330 Central Expressway 2163 Santa Clara, CA 95050 2164 USA 2165 Email: rayq@huawei.com 2166 Yakov Rekhter 2167 Juniper Networks 2168 1194 North Mathilda Ave. 2169 Sunnyvale, CA 94089 2170 Email: yakov@juniper.net 2172 Eric C. Rosen 2173 Cisco Systems, Inc. 2174 1414 Massachusetts Avenue 2175 Boxborough, MA, 01719 2176 Email: erosen@cisco.com 2178 IJsbrand Wijnands 2179 Cisco Systems, Inc. 2180 De kleetlaan 6a Diegem 1831 2181 Belgium 2182 Email: ice@cisco.com 2184 13. References 2186 13.1. Normative References 2188 [MVPN] "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. Aggarwal, et. 2189 al., RFC 6513, February 2012 2191 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP 2192 IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, RFC 6514, 2193 February 2012 2195 [MVPN-WILDCARDS] "Wildcards in Multicast VPN Auto-Discovery Routes", 2196 Rosen, Rekhter, Henderickx, Qiu, RFC 6625, May 2012 2198 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM): 2199 Protocol Specification (Revised)", Fenner, Handley, Holbrook, 2200 Kouvelas, RFC 4601, August 2006 2202 [RFC2119] "Key words for use in RFCs to Indicate Requirement 2203 Levels.", Bradner, March 1997 2205 [L3VPN] "BGP/MPLS IP VPNs", E. Rosen, Y. Rekhter, et. al., RFC 4364, 2206 February 2006 2208 13.2. Informative References 2210 [BIDIR-PIM] "Bidirectional Protocol Independent Multicast", Handley, 2211 Kouvelas, Speakman, Vicisano, RFC 5015, October 2007 2213 [BSR] "Bootstrap Router (BSR) Mechanism for Protocol Independent 2214 Multicast (PIM)", N. Bhaskar, A. Gall, J. Lingard, S. Venaas, RFC 2215 5059, January 2008 2217 [mLDP] "Label Distribution Protocol Extensions for Point-to- 2218 Multipoint and Multipoint-to-Multipoint Label Switched Paths", IJ. 2219 Wijnands, I. Minei, K. Kompella, B. Thomas, RFC 6388, November 2011. 2221 [RFC3446] "Anycast Rendevous Point (RP) mechanism using Protocol 2222 Independent Multicast (PIM) and Multicast Source Discovery Protocol 2223 (MSDP)", D. Kim, D. Meyer, H. Kilmer, D. Farinacci, January 2003 2225 [RFC4610] "Anycast-RP Using Protocol Independent Multicast (PIM)", D. 2226 Farinacci, Y. Cai, August 2006 2228 [RSVP-P2MP] "Extensions to Resource Reservation Protocol - Traffic 2229 Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths 2230 (LSPs)", R. Aggarwal, D. Papadimitriou, S. Yasukawa, RFC 4875, May 2231 2007