idnits 2.17.1 draft-ietf-bess-mvpn-extranet-07.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 (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 (April 12, 2016) is 2934 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) == Outdated reference: A later version (-05) exists of draft-ietf-bess-ir-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group Y. Rekhter, Ed. 3 Internet-Draft E. Rosen, Ed. 4 Updates: 6513,6514,6625 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track R. Aggarwal 6 Expires: October 14, 2016 Arktan 7 Y. Cai 8 Microsoft 9 T. Morin 10 Orange 11 April 12, 2016 13 Extranet Multicast in BGP/IP MPLS VPNs 14 draft-ietf-bess-mvpn-extranet-07 16 Abstract 18 Previous RFCs specify the procedures necessary to allow IP multicast 19 traffic to travel from one site to another within a BGP/MPLS IP VPN 20 (Virtual Private Network). However, it is sometimes desirable to 21 allow multicast traffic whose source is in one VPN to be received by 22 systems that are in another VPN. This is known as a "Multicast VPN 23 (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by 24 specifying the procedures that are necessary in order to provide MVPN 25 extranet service. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 14, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1.2.1. Customer Multicast Control 65 Protocols . . . . . . . . . . . . . . . . . . . . . . 7 66 1.2.2. Provider Multicast Control 67 Protocols . . . . . . . . . . . . . . . . . . . . . . 7 68 1.3. Clarification on Use of Route 69 Distinguishers . . . . . . . . . . . . . . . . . . . . . 7 70 1.4. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 71 2. Extranets and Overlapping Address 72 Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.1. Ambiguity: P-tunnel with 74 Extranet/Non-Extranet Flows . . . . . . . . . . . . . . . 13 75 2.2. Ambiguity: P-tunnel with Multiple 76 Extranet Flows . . . . . . . . . . . . . . . . . . . . . 15 77 2.3. Preventing Misdelivery in These 78 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 17 79 2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel . . 17 80 2.3.2. Policies to Prevent Ambiguity on a P-tunnel . . . . . 19 81 3. Extranet Transmission Models . . . . . . . . . . . . . . . . 20 82 3.1. Transmitting an Extranet C-flow on a Single PMSI . . . . 21 83 3.1.1. Without Extranet Separation . . . . . . . . . . . . . 21 84 3.1.2. With Extranet Separation . . . . . . . . . . . . . . 21 85 3.2. Transmitting an Extranet C-flow over Multiple PMSIs . . . 22 86 4. Distribution of Routes that Match 87 C-S/C-RP Addresses . . . . . . . . . . . . . . . . . . . . . 22 88 4.1. UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 22 89 4.1.1. Extranet Separation . . . . . . . . . . . . . . . . . 23 90 4.2. Distribution of Unicast Routes 91 Matching C-RPs and DRs . . . . . . . . . . . . . . . . . 24 92 4.3. Route Targets and Ambiguous 93 UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 25 94 4.4. Dynamically Marking Extranet 95 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 4.4.1. The Extranet Source Extended 97 Community . . . . . . . . . . . . . . . . . . . . . . 26 98 4.4.2. Distribution of Extranet Source Extended 99 Community . . . . . . . . . . . . . . . . . . . . . . 28 100 4.5. The 'Extranet Separation' Extended Community . . . . . . 29 101 5. Origination and Distribution of BGP A-D Routes . . . . . . . 29 102 5.1. Route Targets of UMH-eligible Routes and A-D 103 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 29 104 5.2. Considerations for Particular Inclusive Tunnel 105 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 5.2.1. RSVP-TE P2MP or Ingress 107 Replication . . . . . . . . . . . . . . . . . . . . . 32 108 5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 32 109 6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 34 110 6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 35 111 6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 35 112 6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 36 113 6.1.3. PIM C-Instance Reverse Path Forwarding 114 Determination . . . . . . . . . . . . . . . . . . . . 36 115 6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 36 116 6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 36 117 6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 39 118 6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 41 119 6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 41 120 6.2.5. Sending and Receiving Data Packets . . . . . . . . . 41 121 6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 42 122 6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 42 123 7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 44 124 7.1. Originating C-multicast Routes . . . . . . . . . . . . . 44 125 7.2. Originating A-D Routes Without Extranet 126 Separation . . . . . . . . . . . . . . . . . . . . . . . 45 127 7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 45 128 7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 46 129 7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 46 130 7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 46 131 7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 47 132 7.3. Originating A-D Routes With Extranet Separation . . . . . 47 133 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 47 134 7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 48 135 7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 50 136 7.4. Determining the Expected P-tunnel for a C-flow . . . . . 50 137 7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52 138 7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52 139 7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 52 140 7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 54 141 7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 54 142 7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 55 143 8. Multiple Extranet VRFs on the same 144 PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 146 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 147 10. Security Considerations . . . . . . . . . . . . . . . . . . . 56 148 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 149 12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 58 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 151 13.1. Normative References . . . . . . . . . . . . . . . . . . 59 152 13.2. Informative References . . . . . . . . . . . . . . . . . 60 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 155 1. Introduction 157 Previous RFCs ([RFC6513], [RFC6514]) specify the procedures necessary 158 to allow IP multicast traffic to travel from one site to another 159 within a BGP/MPLS IP VPN (Virtual Private Network). However, it is 160 sometimes desirable to allow multicast traffic whose source is in one 161 VPN to be received by systems that are in another VPN. This is known 162 as an "extranet MVPN". This document specifies the procedures that 163 are necessary in order to provide Extranet MVPN functionality. 165 1.1. Terminology 167 This document uses terminology from [RFC6513], and in particular uses 168 the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513], 169 and "A-D routes" for "auto-discovery routes". 171 The term "Upstream Multicast Hop" (UMH) is used as defined in 172 [RFC6513]. 174 The term "UMH-eligible route" is used to mean "route eligible for UMH 175 determination", as defined in Section 5.1.1 of [RFC6513]. We will 176 say that a given UMH-eligible route or unicast route "matches" a 177 given IP address, in the context of a given Virtual Routing and 178 Forwarding Table (VRF), if the address prefix of the given route is 179 the longest match in that VRF for the given IP address. We will 180 sometimes say that a route "matches" a particular host if the route 181 matches an IP address of the host. 183 We follow the terminology of Section 3.2 of [RFC6625] when talking of 184 a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route 185 being "installed". That is, we say that an S-PMSI A-D route is 186 "installed" (in a given VRF) if it has been selected by the BGP 187 decision process as the preferred route for its NLRI. We also follow 188 the terminology of Section 3.2 of [RFC6625] when saying that an 189 S-PMSI A-D route has been "originated by a given PE"; this means that 190 the given PE's IP address is contained in the "Originating Router's 191 IP Address" field in the NLRI of the route. 193 We use the following additional terminology and notation: 195 o Extranet C-source: a multicast source, in a given VPN, that is 196 allowed by policy to send multicast traffic to receivers that are 197 in other VPNs. 199 o Extranet C-receiver: a multicast receiver, in a given VPN, that is 200 allowed by policy to receive multicast traffic from extranet 201 C-sources that are in other VPNs. 203 o Extranet C-flow: a multicast flow (with a specified C-source 204 address and C-group address) whose source is an extranet C-source, 205 and which is allowed by policy to have extranet C-receivers. 207 o Extranet C-group: a multicast group address that is in the "Any 208 Source Multicast" (ASM) group address range, and that is allowed 209 by policy to have Extranet C-sources and Extranet C-receivers that 210 are not all in the same VPN. Note that we will sometimes refer to 211 "Source-Specific Multicast" (SSM) C-group addresses" (i.e., to 212 C-group addresses in the SSM group address range), but will never 213 call them "extranet C-groups". 215 N.B.: Any source of traffic for an extranet C-group is considered 216 to be an extranet C-source, and any receiver of traffic addressed 217 to an extranet C-group is considered to be an extranet C-receiver. 219 o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet 220 C-group; it is allowed by policy to receive PIM register messages 221 [RFC7761] from outside its VPN, and to send multicast data packets 222 to extranet C-receivers outside its VPN. 224 o Host(C-S,A): the host (or if C-S is an "anycast address", the set 225 of hosts) denoted by the address C-S in the context of VPN-A. For 226 example, if a particular C-source in VPN A has address C-S, then 227 Host(C-S,A) refers to that C-source. 229 o SAFI-n route: a BGP route whose Address Family Identifier (AFI) is 230 either 1 (IPv4) or 2 (IPv6), and whose Subsequent Address Family 231 Identifier (SAFI) is "n". 233 o PTA: PMSI Tunnel attribute [RFC6514]. 235 Note that a given extranet C-source is not necessarily allowed to 236 transmit to every extranet C-receiver; policy determines which 237 extranet C-sources are allowed to transmit to which extranet 238 C-receivers. However, in the case of an extranet (ASM) C-group, all 239 transmitters to the group are allowed to transmit to all the 240 receivers of the group, and all the receivers of the group are 241 allowed to receive from all transmitters to the group. 243 We say that a given VRF "contains" or "has" a multicast C-source (or 244 that the C-source is "in" the VRF), if that C-source is in a site 245 connected to that VRF, and the VRF originates a UMH-eligible route 246 (see Section 4) that matches the address of the C-source. 248 We say that a given VRF "contains" or "has" a multicast C-receiver 249 (or that the C-receiver is "in" the VRF), if that C-receiver is in a 250 site connected to that VRF. 252 We say that a given VRF "contains" or "has" the C-RP for a given ASM 253 group (or that the C-RP is "in" the VRF) if that C-RP is in a site 254 connected to that VRF, and the VRF originates a unicast route and a 255 (possibly different, possibly the same) UMH-eligible route (see 256 Section 4) whose respective address prefixes match the C-RP address. 258 [RFC6513] allows a set of "Provider tunnels" (P-tunnels) to be 259 aggregated together and transported via an outer P-tunnel, i.e., it 260 allows for the use of hierarchical Label Switched Paths (LSPs) as 261 P-tunnels. A two-level hierarchical LSP, for example, can be thought 262 of as a set of "inner tunnels" aggregated into an outer tunnel. In 263 this document, when we speak of a P-tunnel, we are always speaking of 264 the innermost P-tunnel, i.e., of a P-tunnel at the lowest level of 265 hierarchy. P-tunnels are identified in the Provider Multicast 266 Service Interface (PMSI) Tunnel Attributes (PTAs) [RFC6514] of BGP 267 Auto-Discovery (A-D) routes. Two PTAs that have the same Tunnel Type 268 and Tunnel Identifier fields, but different MPLS label fields, are 269 thus considered to identify two different P-tunnels. (I.e., for the 270 purposes of this document, the MPLS label included in the PTA, if 271 any, is considered to be part of the tunnel identifier.) 273 We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D 274 route contains (C-S,C-G) if its "Multicast Source" field contains C-S 275 and its "Multicast Group" field contains C-G. If either or both of 276 these fields is encoded as a wildcard, we will say that the NLRI 277 contains (C-*,C-*) (both fields encoded as wildcard), or (C-*,C-G) 278 (multicast source field encoded as wildcard) or (C-S,C-*) (multicast 279 group field encoded as wildcard). 281 We use the term "VPN security violation" to refer to any situation in 282 which a packet is delivered to a particular VPN, even though, by 283 policy, it should not be delivered to that VPN. 285 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 286 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 287 "OPTIONAL" in this document are to be interpreted as described in 288 [RFC2119]. 290 1.2. Scope 292 1.2.1. Customer Multicast Control Protocols 294 This document presumes that the VPN customer is using "PIM Sparse 295 Mode", operating in either "Source-Specific Mode" (SSM) or "Any 296 Source Mode" (ASM), as the multicast control protocol at the customer 297 sites. Support for other customer IP multicast control protocols 298 (e.g., [RFC5015], PIM "Dense Mode") is outside the scope of this 299 document. Support for the customer use of MPLS multicast control 300 protocols (e.g., [RFC6388], [RFC4875]) is also outside the scope of 301 this document. 303 When a VPN customer uses ASM, the customer routers need to be able to 304 map from a C-group address to a C-RP address. These mappings can be 305 provisioned in each router, or can be discovered dynamically through 306 protocols such as BSR [RFC5059]. However, it cannot be assumed that 307 such protocols will automatically work in the context of an extranet. 308 Discussion of the use of such protocols in an extranet is outside the 309 scope of this document. 311 1.2.2. Provider Multicast Control Protocols 313 [RFC6513] allows either PIM or BGP to be used as the protocol for 314 distributing customer multicast routing information. Except where 315 otherwise specified, such as in Sections 6 and 7, the procedures of 316 this document cover both cases. 318 1.3. Clarification on Use of Route Distinguishers 320 [RFC4364] requires that every VRF be associated with one or more 321 Route Distinguishers (RD). Each VPN-IPv4 or VPN-IPv6 route that is 322 exported from a particular VRF contains, in its NLRI, an RD that is 323 associated with that VRF. 325 [RFC4364] allows a given RD to be associated with more than one VRF, 326 as long as all the VRFs associated with that RD belong to the same 327 VPN. However, in the most common deployment model, each RD is 328 associated with one and only one VRF. [RFC6513] and [RFC6514] 329 presuppose this deployment model. That is, [RFC6513] and [RFC6514] 330 presuppose that every RD is associated with one and only one VRF. We 331 will call this the "unique VRF per RD" condition. 333 [RFC6514] defines the MCAST-VPN address family, which has a number of 334 route types. Each Intra-AS "Inclusive Provider Multicast Service 335 Interface" (I-PMSI) A-D route, S-PMSI A-D route, and Source Active 336 A-D route, when exported from a given VRF, contains, in its NLRI, an 337 RD that is associated with the VRF. [RFC6513] and [RFC6514] also 338 discuss a class of routes known as "UMH-eligible" routes; when a UMH- 339 eligible route is exported from a given VRF, its NLRI contains an RD 340 of the VRF. 342 [RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an 343 RD of the VRF from which they are exported: the C-multicast Join 344 routes and the Leaf A-D routes. 346 Those route types that, when exported from a given VRF, contain (in 347 their NLRIs) an RD of the VRF, will be known in this document as 348 "local-RD routes". 350 Given the "unique VRF per RD condition", if one sees that two local- 351 RD routes have the same RD, one can infer that the two routes 352 originated from the same VRF. This inference can be drawn even if 353 the two routes do not have the same SAFI, as long as the two routes 354 are both local-RD routes. 356 This document builds upon [RFC6513] and [RFC6514]; therefore the 357 "unique VRF per RD" condition is REQUIRED. 359 [RFC6514] presupposes a further requirement on the use of RDs in the 360 local-RD routes exported from a given VRF. Suppose a given VRF 361 exports a Source Active A-D route containing (C-S,C-G). That VRF 362 will also export a UMH-eligible route matching C-S. [RFC6514] 363 presupposes that the UMH-eligible route and the Source Active A-D 364 route have the same RD. 366 In most cases, not only is a given RD associated with only a single 367 VRF, but a given VRF is associated with only a single RD. We will 368 call this the "unique RD per VRF" condition. When this condition 369 holds, all the local-RD routes exported from a given VRF will have 370 the same RD. This ensures that the presupposition of the previous 371 paragraph will hold, i.e., that the RD in a Source Active A-D route 372 exported from a given VRF will have the same RD as the corresponding 373 UMH-eligible route exported from the same VRF. 375 Section 7.3 of this document describes a procedure known as "Extranet 376 Separation". When Extranet Separation is NOT being used, it is 377 REQUIRED by this document that the "unique RD per VRF" condition 378 hold. This ensures that all the local-RD routes exported from a 379 given VRF will have the same RD. 381 When Extranet Separation is used, a VRF that contains both extranet 382 sources and non-extranet sources MUST be configured with two RDs. 383 One of these RDs is known as the "default RD", and the other is known 384 as the "extranet RD". It MUST be known by configuration which RD is 385 the default RD and which is the extranet RD. 387 When a VRF is configured with only one RD, we will refer to that RD 388 as the "default RD". 390 In general, local-RD routes exported from a given VRF will contain 391 the default RD. However, when Extranet Separation is used, some of 392 the local-RD routes exported from the VRF will contain the extranet 393 RD. Details concerning the exported routes that contain the extranet 394 RD can be found in Sections 4.1 and 7.3. 396 Note that the "unique VRF per RD" condition applies to the extranet 397 RD as well as to the default RD. That is, a given extranet RD is 398 associated with a unique VRF. 400 1.4. Overview 402 Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN 403 functionality as specified in [RFC6513] and/or [RFC6514]. In the 404 simplest configuration, VPN-S is a collection of VRFs, each of which 405 is configured with a particular Route Target (RT) value (call it "RT- 406 S") as its import RT and as its export RT. Similarly, VPN-R is a 407 collection of VRFs, each of which is configured with a particular RT 408 value (call it "RT-R") as its import RT and as its export RT. 410 In this configuration, multicast C-receivers contained in a VPN-R VRF 411 cannot receive multicast data traffic from multicast C-sources 412 contained in a VPN-S VRF. If it is desired to allow this, one needs 413 to create an MVPN "extranet". Creating an extranet requires 414 procedures in addition to those specified in [RFC6513], [RFC6514], 415 and [RFC6625]; this document specifies these additional procedures. 417 In the example above, the additional procedures will allow a selected 418 set of routes exported from the VPN-S VRFs (i.e., from the VRFs 419 containing extranet C-sources) to be imported into the VPN-R VRFs 420 (i.e., into the VRFs containing extranet C-receivers). These routes 421 include the routes that are to be eligible for use as UMH routes (see 422 Section 5.1 of [RFC6513]) in the extranet, as well as a selected set 423 of BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, 424 Source Active A-D routes). Importing these routes into the VPN-R 425 VRFs makes it possible to determine, in the context of a VPN-R VRF, 426 that a particular C-multicast Join needs to be delivered to a 427 particular VPN-S VRF. It also makes it possible to determine, in the 428 context of a VPN-R VRF, the P-tunnel through which the aforementioned 429 VPN-S VRF sends a particular C-flow. 431 Depending on the type of P-tunnel used, it may also be necessary for 432 Leaf A-D routes to be exported by one or more VPN-R VRFs and imported 433 into a VPN-S VRF. 435 There are no extranet-specific procedures governing the use and 436 distribution of BGP C-Multicast routes. 438 If PIM is used as the PE-PE protocol for distributing C-multicast 439 routing information, additional BGP A-D routes must be exported from 440 the VPN-R VRFs and imported into the VPN-S VRFs, so that the VPN-S 441 VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM 442 control messages. Details can be found in Section 6. 444 The simple example above describes an extranet created from two 445 MVPNs, one of which contains extranet C-sources and one of which 446 contains extranet C-receivers. However, the procedures described in 447 this document allow for much more complicated scenarios. 449 For instance, an extranet may contain extranet C-sources and/or 450 extranet C-receivers from an arbitrary number of VPNs, not just from 451 two VPNs. An extranet C-receiver in VPN-R may be allowed to receive 452 multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C. 453 Similarly, extranet C-sources in VPN-S may be allowed to send 454 multicast traffic to multicast C-receivers that are in VPN-A, VPN-B, 455 VPN-C, etc. 457 A given VPN customer may desire that only some of its multicast 458 C-sources be treated as extranet C-sources. This can be accomplished 459 by appropriate provisioning of the import and export RTs of that 460 customer's VRFs (as well as the VRFs of other VPNs that contain 461 extranet C-receivers for extranet C-flows of the given customer.) 463 A given VPN customer may desire that some of its extranet C-sources 464 can transmit only to a certain set of VPNs, while other of its 465 extranet C-sources can transmit only to a different set of VPNs. 466 This can be accomplished by provisioning the VRFs to export different 467 routes with different RTs. 469 In all these cases, the VPN customers set the policies, and the 470 Service Provider (SP) implements the policies by the way it 471 provisions the import and export RTs of the VRFs. It is assumed that 472 the customer communicates to the SP the set of extranet C-source 473 addresses, and the set of VPNs to which each C-source can transmit. 474 (Recall that every C-source that can transmit to an extranet C-group 475 is an extranet C-source, and must be able transmit to any VPN that 476 has receivers for that group. This must be taken into account when 477 the provisioning is done.) This customer/SP communication is part of 478 the service provisioning process, and outside the scope of this 479 document. 481 It is possible that an extranet C-source will transmit both extranet 482 C-flows and non-extranet C-flows. However, if extranet C-receiver 483 C-R can receive extranet C-flows from extranet C-source C-S, the 484 procedures of this document do not prevent C-R from requesting and 485 receiving the non-extranet flows that are transmitted by C-S. 486 Therefore it is NOT RECOMMENDED to allow an extranet C-source to 487 transmit non-extranet C-flows. However, the Service Provider (SP) 488 has no control over the set of C-flows transmitted by a given 489 C-source, and can do no more than communicate this recommendation to 490 its customers. (Alternatively, the customer and SP may coordinate on 491 setting up filters to prevent unauthorized flows from being sent to a 492 customer site; such a procedure is outside the scope of this 493 document.) See the "Security Considerations" section (Section 10) 494 for additional discussion of this issue. 496 Whenever a VPN is provisioned, there is a risk that errors in 497 provisioning may result in an unintended cross-connection of VPNs. 498 This would create a security problem for the customers. When 499 provisioning an extranet, attention to detail is particularly 500 important, as extranet intentionally cross-connects VPNs. Care must 501 always be taken to ensure that the cross-connections are according to 502 the policy agreed upon by the SP and its customers. 504 Additionally, if one is connecting two VPNs that have overlapping 505 address spaces, one has to be sure that the inter-VPN traffic neither 506 originates from nor is destined to the part of the address space that 507 is in the overlap. Other problems that can arise due to overlapping 508 address spaces are discussed in Section 2. 510 2. Extranets and Overlapping Address Spaces 512 As specified in [RFC4364], the address space of one VPN may overlap 513 with the address space of another. A given address may be 514 "ambiguous", in that it denotes one system within VPN-A and a 515 different system within VPN-B. In the notation of Section 1.1, if an 516 address C-S is ambiguous between VPNs A and B, then Host(C-S,A) != 517 Host(C-S,B). However, any given address C-S MUST be unambiguous 518 (i.e., MUST denote a single system) in the context of a given VPN. 520 When a set of VRFs belonging to different VPNs are combined into an 521 extranet, it is no longer sufficient for an address to be unambiguous 522 only within the context of a single VPN: 524 1. Suppose C-S is the address of a given extranet C-source contained 525 in VPN-A. Now consider the set of VPNs {VPN-B, VPN-C, ...} 526 containing extranet C-receivers that are allowed by policy to 527 receive extranet C-flows from VPN-A's C-S. The address C-S MUST 528 be unambiguous among this entire set of VPNs (VPN-A, VPN-B, VPN- 529 C, etc.); i.e., Host(C-S,A) == Host(C-S,B) == Host(C-S,C). 531 The implication is that C-S in VPN-A is not necessarily an 532 extranet C-source for all VPNs that contain extranet C-receivers; 533 policy MUST be used to ensure that C-S is an extranet C-source 534 for a given VPN, say VPN-B, only if C-S is unambiguous between 535 VPN-A and VPN-B. 537 2. If a given VRF contains extranet C-receivers for a given extranet 538 C-source, then the address of this C-source MUST be unambiguous 539 among all the extranet C-sources for which there are C-receivers 540 in the VRF. This is true whether or not C-sources are in VRFs 541 that belong to the same or to different VPNs. 543 The implication is that if C-S in VRF-X is ambiguous with C-S in 544 VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing 545 C-receivers that are allowed by policy to receive extranet 546 C-flows from both C-S in VRF-X and C-S in VRF-Y. 548 Note: A VPN customer may be using "anycast" addresses. An anycast 549 address is intentionally ambiguous, as it denotes a set of systems 550 rather than a single system. In this document, we will consider an 551 anycast address to be unambiguous in a given context as long as it 552 denotes the same set of systems whenever it occurs in that context. 554 A multicast C-group address, say C-G, may also be ambiguous, in that 555 it may be used for one multicast group in VPN-A and for an entirely 556 different multicast group in VPN-B. If a set of MVPNs are combined 557 into an extranet, and C-G is an extranet C-group, it is necessary to 558 ensure that C-G is unambiguous among the entire set of VPNs whose 559 VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers 560 for that C-group. This may require, as part of the provisioning 561 process, customer/SP communication that is outside the scope of this 562 document. 564 Subject to these restrictions, the SP has complete control over the 565 distribution of routes in an MVPN. This control is exerted either by 566 provisioning the export RTs on the VRFs that originate the routes 567 (i.e., on the VRFs that contain the extranet C-sources), or by 568 provisioning the import RTs on the VRFs that receive the routes 569 (i.e., on the VRFs that contain the extranet C-receivers), or both. 571 Some of the rules and restrictions on provisioning the RTs are 572 applicable to all extranets; these are specified in Section 4. 573 Sections 6 and 7 add additional rules and restrictions that are 574 applicable only to particular extranet scenarios. 576 Even if all the RTs are provisioned according to the above rules and 577 restrictions, it is still possible for a single P-tunnel to contain 578 multicast data packets whose source and/or group addresses are 579 ambiguous in the context of the set of PEs that receive data from the 580 P-tunnel. That is, the above rules and restrictions are necessary, 581 but not sufficient, to prevent address ambiguity from causing 582 misdelivery of traffic. To prevent such misdelivery, additional 583 procedures or policies must be used. 585 Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may 586 carry data packets with ambiguous addresses. The additional 587 procedures and policies needed to prevent misdelivery of data in 588 those scenarios are outlined in Section 2.3. (The detailed 589 procedures described in Sections 6 and 7 incorporate the 590 considerations of Section 2.3.) 592 2.1. Ambiguity: P-tunnel with Extranet/Non-Extranet Flows 594 In the following, we will use the notation "VRF A-n" to mean "VRF n 595 of VPN-A". 597 If VPN-A and VPN-B have overlapping address spaces, and are part of 598 the same extranet, then the following problem may exist, as 599 illustrated in Figure 1. 601 C-S2(A) C-S1 Join(C-S2(A),G) 602 \ / / 603 \ / / 604 +-------+---+ P1: (C-S1,G), (C-S2(A),G) +---+--------+ 605 |VRF A-1| |---------------------------------| |VRF A-2 | 606 +-------+PE1| |PE2+--------+ 607 |VRF B-1| |---------------------------------| |VRF B-2 | 608 +-------+---+ P2: (C-S2(B),G) +---+--------+ 609 / / \ 610 / / \ 611 C-S2(B) Join(C-S2(B),G) Join(C-S1,G) 613 Figure 1: Ambiguity of Extranet and Non-Extranet Source Address 615 Suppose: 617 o C-G is an SSM C-group used in VPNs A and B. 619 o VRF A-1, on PE1, contains an extranet C-source, whose IP address 620 is C-S1, that is allowed to have receivers in VPN B. VRF A-1 thus 621 exports to VPN B a UMH-eligible route matching C-S1. 623 o VRF A-1 also contains a non-extranet C-source, whose IP address is 624 C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 to other 625 VPN A VRFs, but NOT to VPN B. 627 o VRF B-1, also on PE1, contains a non-extranet C-source whose IP 628 address is C-S2. A UMH-eligible route matching C-S2 is thus 629 exported from VRF B-1 to other VRFs in VPN B. 631 o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous 632 address in any extranet that contains both VPN-A VRFs and VPN-B 633 VRFs. 635 o VRF B-2, on some other PE, say PE2, requests to receive the 636 multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1 637 matches the route exported from VRF A-1. Thus B-2's request to 638 receive the (C-S1,C-G) flow is transmitted to VRF A-1. 640 o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by 641 transmitting that traffic on P-tunnel P1. 643 o VRF B-2 joins P-tunnel P1, in order to receive the (C-S1,C-G) 644 traffic. 646 o VRF A-2, on PE2, requests to receive the (non-extranet) multicast 647 flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the 648 route exported from VRF A-1. Thus A-2's request to receive the 649 (C-S2,C-G) traffic is transmitted to VRF A-1. 651 o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by 652 transmitting that traffic on P-tunnel P1. 654 o VRF A-2 joins P-tunnel P1, in order to receive the (C-S2,C-G) 655 traffic. 657 o VRF B-2 requests to receive the (non-extranet) multicast flow 658 (C-S2,C-G). In the context of VRF B-2, C-S2 matches the route 659 exported from VRF B-1. Thus B-2's request to receive the 660 (C-S2,C-G) flow is transmitted to VRF B-1. 662 o VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by 663 transmitting that traffic on P-tunnel P2. 665 o VRF B-2 joins P-tunnel P2. 667 Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive 668 (C-S2,C-G) traffic on both P-tunnels. The (C-S2,C-G) traffic that 669 VRF B-2 needs to receive is traveling on P-tunnel P2; this (C-S2,C-G) 670 traffic must be forwarded by B-2 to any attached customer sites that 671 have C-receivers for it. But B-2 MUST discard the (C-S2,C-G) traffic 672 that it receives on P1, as this is not the traffic that it has 673 requested. If the (C-S2,C-G) traffic arriving on P1 were forwarded 674 to B-2's customer sites, the C-receivers would not be able to 675 distinguish the two flows, and the result would be a corrupted data 676 stream. 678 Note that the procedures of [RFC6513] Section 9.1.1 ("Discarding 679 Packets from the Wrong PE") will not cause VRF B-2 to discard the 680 (C-S2,C-G) that arrives on tunnel P1, because P1 and P2 have the same 681 upstream PE. 683 Therefore, it is necessary EITHER to prevent the above scenario from 684 occurring, OR ELSE to ensure that multicast data packets will be 685 discarded if they arrive on the "wrong" P-tunnel (even if they arrive 686 from the expected PE). See Section 2.3 for further discussion of 687 this issue. 689 2.2. Ambiguity: P-tunnel with Multiple Extranet Flows 691 Here is another example in which overlapping address spaces may cause 692 a problem. This example is illustrated in Figure 2. 694 C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G) 695 \ / / 696 \ / / 697 +-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+ 698 |VRF A-1| |---------------------------------| |VRF D-1 | 699 +-------+PE1| |PE2+--------+ 700 |VRF B-1| |---------------------------------| |VRF C-1 | 701 +-------+---+ P2: (C-S2(B2C),G) +---+--------+ 702 / / \ 703 / / \ 704 C-S2(B2C) / \ 705 Join Join 706 (C-S2(B2C),G) (C-S1(A2C),G) 708 Figure 2: Ambiguity of Extranet Source Addresses 710 Suppose: 712 o C-G is an SSM C-group address that is used in VPNs A, B, C, and D. 714 o VRF A-1, on PE1, contains an extranet C-source whose IP address is 715 C-S1, and that is allowed by policy to have C-receivers in VPN C 716 (but not in VPN D). VRF A-1 thus exports a UMH-eligible route 717 matching C-S1 to VPN C. 719 o VRF A-1 also contains an extranet C-source whose IP address is 720 C-S2, and that is allowed by policy to have C-receivers in VPN D 721 (but not in VPN C). VRF A-1 thus exports a UMH-eligible route 722 matching C-S2 to VPN D. 724 o VRF B-1, also on PE1, contains an extranet C-source whose IP 725 address is C-S2, and that is allowed by policy to have C-receivers 726 in VPN C (but not in VPN D). VRF B-1 thus exports a UMH-eligible 727 route matching C-S2 to VPN C. 729 o Host(C-S2,A) != Host (C-S2,B). That is, C-S2 is an ambiguous 730 address in any extranet that contains both VPN-A VRFs and VPN-B 731 VRFs. 733 o VRF C-1, on some other PE, say PE2, requests to receive the 734 extranet multicast flow (C-S1,C-G). In the context of VRF C-1, 735 C-S1 matches the route exported from VRF A-1. Thus C-1's request 736 to receive the (C-S1,C-G) flow is transmitted to VRF A-1. 738 o VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by 739 transmitting that traffic on P-tunnel P1, 741 o VRF C-1 joins P-tunnel P1, in order to receive the (C-S1,C-G) 742 traffic. 744 o VRF C-1 requests to receive the extranet multicast flow 745 (C-S2,C-G). In the context of VRF C-1, C-S2 matches the route 746 exported from VRF B-1. Thus C-1's request to receive the 747 (C-S2,C-G) flow is transmitted to VRF B-1. 749 o VRF B-1 responds by transmitting its (C-S2,C-G) traffic on 750 P-tunnel P2. 752 o VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) 753 traffic. 755 o VRF D-1, on PE2, requests to receive the extranet multicast flow 756 (C-S2,C-G). In the context of VRF D-1, C-S2 matches the route 757 exported from VRF A-1. Thus D-1's request to receive the 758 (C-S2,C-G) flow is transmitted to VRF A-1. 760 o VRF A-1 responds by transmitting its (C-S2,C-G) traffic on 761 P-tunnel P1. 763 o VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G) 764 traffic. 766 In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to 767 carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic. VRF 768 C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic 769 from VRF A-1, which means that VRF C-1 will also receive the unwanted 770 (C-S2,C-G) traffic from P1. VRF C-1 is also expecting (C-S2,C-G) 771 traffic from VRF B-1; this traffic will be received from P2. Thus 772 VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both 773 C-flows arrive from the expected PE, PE1. 775 Therefore, it is necessary EITHER to prevent the above scenario from 776 occurring, OR ELSE to ensure that VRF C-1 discards any (C-S,C-G) 777 traffic that arrives from the "wrong" P-tunnel. See Section 2.3 for 778 further discussion of this issue. 780 Note that the ambiguity described in this section (Section 2.2) would 781 not occur if C-G were an (ASM) extranet C-group. In that case, the 782 scenario would violate the rule, given previously in Section 2, 783 requiring that all sources sending to a particular ASM extranet 784 C-group must have addresses that are unambiguous over all the MVPNs 785 receiving traffic for that C-group. 787 2.3. Preventing Misdelivery in These Scenarios 789 There are two ways to prevent the scenarios of Section 2.1 and 790 Section 2.2 from resulting in misdelivery of data. These two ways 791 are discussed respectively in Section 2.3.1 and Section 2.3.2. 793 2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel 795 Consider a particular C-flow that has receivers in a particular VRF. 796 Sections 6 and 7 describe a set of procedures that enable an egress 797 PE to determine the "expected P-tunnel" for that C-flow in the 798 context of that VRF. If a PE receives packets of the C-flow (as 799 determined by the IP source and/or destination address of the 800 packet), it checks to see if the packet was received on the expected 801 P-tunnel for that VRF. If so, the packet is delivered to the VRF 802 (and thus to the C-flow's receivers in that VRF). If not, the packet 803 is not delivered to the VRF. 805 Note that at a given egress PE, the "wrong" P-tunnel for one VRF may 806 be the right P-tunnel for another. 808 These procedures, if applied at every PE that joins a given P-tunnel, 809 are sufficient to prevent misdelivery of traffic in the scenarios of 810 Sections 2.1 and 2.2. 812 IF these procedures cannot be applied by every PE that is attached to 813 a given extranet, then the policies of Section 2.3.2 MUST be applied 814 at every VRF containing C-sources for that extranet. 816 In some cases, however, it may be safe to deliver packets that arrive 817 from other than the expected P-tunnel. Suppose it is known that 818 every packet gets transmitted on only a single P-tunnel. (This will 819 be the case if the "single PMSI per C-flow" transmission model, 820 discussed in Section 3.1, is being used.) Suppose further that it is 821 known that T1 and T2 carry only packets that arrived at the same 822 ingress PE, over one or more VRF interfaces that are associated with 823 the same VRF. (I.e., that there is a particular VRF that is the 824 ingress VRF for ALL the packets carried by T1 or T2.) In this case, 825 if T1 is the expected P-tunnel for a given (C-S,C-G) , it is NOT 826 necessary to discard (S,G) packets that arrive over T2. 828 It is not always possible to determine whether two P-tunnels are 829 carrying packets from the same ingress VRF. However, in some cases, 830 this can be determined by examination of the A-D routes in which the 831 tunnels have been advertised. 833 Consider the following example: 835 o Tunnel T1 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an 836 Intra-AS I-PMSI A-D route, call it R1. 838 o Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an 839 S-PMSI A-D route, call it R2. 841 o The respective NLRIs of R1 and R2 contain the same RD value. 843 o The MPLS Label field of R1's PMSI Tunnel attribute is zero, and 844 the MPLS label value of R2's PMSI Tunnel attribute is zero. 846 In this example, it can be concluded that T1 and T2 are carrying 847 packets from the same ingress VRF. Thus if T1 is the expected 848 P-tunnel for a (C-S,C-G) flow, (S,G) packets from T2 can be safely 849 delivered to the egress VRF; they do not need to be discarded. 850 Similarly, if T2 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) 851 packets from T1 can be safely delivered to the egress VRF. 853 Another example is the following: 855 o Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a 856 (C-*,C-*) S-PMSI A-D route, call it R3. 858 o Tunnel T4 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a 859 (C-S,C-G) S-PMSI A-D route, call it R4. 861 o The respective NLRIs of R3 and R4 contain the same RD value. 863 o The MPLS Label field of R3's PMSI Tunnel attribute is zero, and 864 the MPLS label value of R4's PMSI Tunnel attribute is zero. 866 In this example, it can be concluded that T3 and T4 are carrying 867 packets from the same ingress VRF. Thus if T3 is the expected 868 P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely 869 delivered to the egress VRF; they do not need to be discarded. 870 Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) 871 packets from T3 can be safely delivered to the egress VRF. 873 When Ingress Replication (IR) P-tunnels are being used, please see 874 [MVPN-IR], especially Section 6 ("The PTA's MPLS Label Field") for a 875 discussion of how to determine when packets from other than the 876 expected P-tunnel must be discarded. 878 2.3.2. Policies to Prevent Ambiguity on a P-tunnel 880 For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI 881 contains (C-S,C-G) or (C-S,C-*), the ambiguities described in 882 Sections 2.1 and 2.2 can be prevented by provisioning a policy that 883 assigns, to such P-tunnels, only flows from the same C-source. 885 However, it is not always possible to determine, through inspection 886 of the control messages, whether this policy has been deployed. For 887 instance, suppose a given VRF has imported a set of S-PMSI A-D 888 routes, that each route in the set has bound only a single 889 (C-S1,C-G1) to a single P-tunnel, and that each route in the set 890 identifies a different P-tunnel in its PTA than is identified by the 891 PTA of any other route in the set. One cannot infer from this that 892 there is no ambiguity, as the same P-tunnel may also have been 893 advertised in an S-PMSI A-D route that is not imported by the given 894 VRF, and that S-PMSI A-D route may have bound (C-S2,C-G2) to the 895 P-tunnel, where C-S1 != C-S2. 897 Therefore, in order to determine that a given P-tunnel (advertised in 898 a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from 899 a single C-source, a PE must have a priori knowledge (through 900 provisioning) that this policy has been deployed. In the remainder 901 of this document, we will refer to this policy as the "Single 902 C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy. Note that this 903 policy is only applicable to P-tunnels that are advertised only in 904 (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes. 906 Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route, or 907 (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an 908 S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always 909 possible for the P-tunnel to contain traffic from multiple C-sources; 910 there is no policy that can prevent that. 912 However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route 913 contains only traffic addressed to a single C-G, the address 914 uniqueness rules of Section 2 prevent the C-source addresses from 915 being ambiguous; the set of C-sources transmitting to a particular 916 extranet C-group address must be unambiguous over the set of MVPNs 917 that have receivers for that C-group. So for P-tunnels that are 918 advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguities described 919 Section 2.1 and Section 2.2 can be prevented by provisioning a policy 920 that assigns, to such P-tunnels, only flows to the same extranet 921 C-group. We will refer to this policy as the "Single C-group per 922 (C-*,C-G) P-tunnel" policy. 924 These considerations can be summarized as follows. IF the procedures 925 referenced in Section 2.3.1 cannot be applied, then the PEs MUST be 926 provisioned so that the all of the following conditions hold true of 927 the VRFs that contain extranet C-sources: 929 o the "Single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy 930 is provisioned, and 932 o either no (C-*,C-G) S-PMSI A-D routes are advertised, or else the 933 "Single C-group per (C-*,C-G) P-tunnel" policy is provisioned, and 935 o no P-tunnels are advertised in I-PMSI A-D routes, and 937 o no (C-*,C-*) S-PMSI A-D routes are advertised. 939 Section 3 of this document describes a procedure known as "extranet 940 separation". When extranet separation is used, the ambiguity of 941 Section 2.1 is prevented. However, the ambiguity of Section 2.2 is 942 not prevented by extranet separation. Therefore, the use of extranet 943 separation is not a sufficient condition for avoiding the procedures 944 referenced in Section 2.3.1. Extranet separation is, however, 945 implied by the policies discussed in this section (Section 2.3.2). 947 3. Extranet Transmission Models 949 This document specifies several "extranet transmission models". A 950 given VRF, containing extranet C-sources or C-receivers, MUST use 951 only one of these models. Further if VRF S contains extranet 952 C-sources, VRF R contains extranet C-receivers, and it is allowed by 953 policy for an extranet C-receiver in VRF R to receive a C-flow from 954 an extranet C-source in VRF S, then VRFs S and R MUST use the same 955 extranet transmission model. The model used by a given VRF is 956 determined by provisioning. 958 3.1. Transmitting an Extranet C-flow on a Single PMSI 960 In one extranet transmission model, which we call the "transmitting 961 an extranet C-flow on a single PMSI" model, or more simply, the 962 "single PMSI per C-flow model", a PE transmitting a packet of an 963 extranet C-flow transmits it on only a single PMSI. If the PMSI is 964 instantiated by a multicast P-tunnel, this means that the PE 965 transmits the packet on a single P-tunnel. Of course, if the PE is a 966 replication point for that multicast P-tunnel, the packet is 967 transmitted more than once by the PE. Similarly, if the PMSI is 968 instantiated by a set of unicast tunnels (i.e., via Ingress 969 Replication), each packet may be transmitted multiple times. It is 970 still the case though that the packet is transmitted only on one 971 PMSI. 973 This document provides procedures for supporting this transmission 974 model using either BGP or PIM as the PE-PE C-multicast control 975 protocol. 977 There are two variants of this transmission model: "without extranet 978 separation" and "with extranet separation". 980 3.1.1. Without Extranet Separation 982 In this variant, multicast data traffic from extranet C-sources and 983 from non-extranet C-sources may be carried in the same P-tunnel. 985 This document provides procedures for supporting this variant using 986 either BGP or PIM as the PE-PE C-multicast control protocol. 988 3.1.2. With Extranet Separation 990 In this variant, multicast data traffic from extranet C-sources and 991 from non-extranet C-sources are never carried in the same P-tunnel. 992 Under certain circumstances, this can reduce the amount of multicast 993 data traffic that is delivered unnecessarily to certain PE routers. 994 It also eliminates the ambiguity discussed in Section 2.1. 996 By definition, when extranet separation is used, the following rule 997 MUST be applied: 999 Traffic from extranet C-sources MUST NOT be carried in the same 1000 P-tunnel as traffic from non-extranet C-sources. 1002 This rule does not impact those VRFs that contain only non-extranet 1003 C-sources, nor does it impact those VRFs that contain only extranet 1004 C-sources. However, if a particular VRF contains both kinds of 1005 C-source, it will need to advertise some P-tunnels that are used for 1006 carrying only extranet C-flows, and some that are used only for 1007 carrying non-extranet C-flows. 1009 This document provides procedures for supporting extranet separation 1010 when BGP is used as the PE-PE C-multicast control protocol. Support 1011 for extranet separation using PIM as the PE-PE C-multicast control 1012 protocol is outside the scope of this document. 1014 3.2. Transmitting an Extranet C-flow over Multiple PMSIs 1016 The second extranet transmission model is called the "transmitting an 1017 extranet C-flow over multiple PMSIs" model, or more simply, the 1018 "multiple PMSIs per C-flow model". In this model, a PE may transmit 1019 the packets of an extranet C-flow on several different PMSIs. 1021 Support for extranet separation with this model is outside the scope 1022 of this document. 1024 This document provides procedures for supporting this transmission 1025 model when PIM as the PE-PE C-multicast control protocol. Support 1026 for this transmission model when BGP is used as the PE-PE C-multicast 1027 control protocol is outside the scope of this document. 1029 4. Distribution of Routes that Match C-S/C-RP Addresses 1031 4.1. UMH-Eligible Routes 1033 As described in Section 5.1 of [RFC6513], in order for a C-flow 1034 (C-S,C-G) to be carried across the SP backbone, a VRF that has 1035 multicast receivers for that C-flow must import a route that matches 1036 C-S, and this route must be "eligible for UMH selection". In this 1037 document, we will refer to these routes as "UMH-eligible extranet 1038 C-source routes". 1040 The UMH-eligible extranet C-source routes do not necessarily have to 1041 be unicast routes; they MAY be SAFI-129 routes (see Section 5.1.1 of 1042 [RFC6513]). For example, suppose one wants a VPN-R C-receiver to be 1043 able to receive extranet C-flows from C-sources in VPN-S, but one 1044 does not want any VPN-R system to be able to send unicast traffic to 1045 those C-sources. One can achieve this by using SAFI-129 routes as 1046 the UMH-eligible routes exported from VPN-S and imported by VPN-R. 1047 Since SAFI-129 routes are used only for UMH determination, but not 1048 for unicast routing, this allows the multicast traffic to be 1049 forwarded properly, but does not create unicast routes to the 1050 C-sources. 1052 If a customer is using PIM-SM in ASM mode, and one or more customer 1053 sites have C-receivers that are allowed by policy to join a (C-*,C-G) 1054 tree, where C-G is an extranet C-group, then any VRF with C-receivers 1055 for that group MUST import a UMH-eligible route that matches C-RP, 1056 where C-RP is the Rendezvous Point (RP) address for C-G. 1058 The UMH-eligible extranet C-source and C-RP routes do not have to be 1059 "host routes." That is, they can be routes whose IPv4 address 1060 prefixes are not 32 bits in length, or whose IPv6 address prefixes 1061 are not 128 bits in length. So it is possible for a UMH-eligible 1062 extranet C-source route to match the address of an extranet C-source 1063 and to also match the address of a non-extranet C-source. However, 1064 if such a route is exported from a VPN-S VRF and imported by a VPN-R 1065 VRF, VPN-R receivers will be able to receive C-flows from any non- 1066 extranet C-sources whose addresses match that route. To prevent 1067 this, the VPN-S VRF SHOULD be provisioned such that it will NOT 1068 export a UMH-eligible route that matches (in the context of the VPN-R 1069 VRF) both extranet C-sources and non-extranet C-sources. Failure to 1070 follow this rule may result in a VPN security violation. (See 1071 Section 10.) 1073 In general, one does not want ALL the routes from the VPN-S VRFs to 1074 be exported to all the VPN-R VRFs, as only a subset of the routes in 1075 the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route 1076 distribution is, as always in a BGP/MPLS IP VPN [RFC4364], controlled 1077 by Route Targets (RTs). A variety of route distribution policies can 1078 be created by appropriately provisioning the import and export RTs of 1079 the various VRFs. 1081 For example, the VPN-S VRFs that contain extranet C-sources could be 1082 configured to apply an export RT whose value is "RT-A-extranet" to 1083 the routes that match the extranet C-sources. The VPN-R VRFs that 1084 contain extranet C-receivers allowed to receive extranet C-flows from 1085 VPN-S extranet C-sources could then be configured with "RT- 1086 A-extranet" as an import RT. 1088 Arbitrarily complex policies can be created by suitable manipulation 1089 of the import and export RTs. 1091 4.1.1. Extranet Separation 1093 If Extranet Separation is being used, and if a given VRF is exporting 1094 UMH-eligible routes both for extranet C-sources for non-extranet 1095 C-sources, then the VRF MUST be configured not only with its "default 1096 RD", but also with an "extranet RD". The exported UMH-eligible 1097 routes MUST contain the extranet RD in their NLRIs. 1099 4.2. Distribution of Unicast Routes Matching C-RPs and DRs 1101 Consider a C-source, C-S, that may transmit to a particular extranet 1102 C-group, C-G. 1104 In order to follow the procedures of [RFC7761], 1106 o the "first hop designated router" (DR) of C-S needs to be able to 1107 unicast "PIM Register Messages" to a C-RP that services C-G; 1109 o the C-RPs servicing C-G need to be able to unicast "PIM Register- 1110 Stop Messages" to the DR of C-S. 1112 It follows that if a VRF contains C-S, but does not contain a C-RP 1113 for C-G, then the VRF MUST import a unicast route matching a C-RP for 1114 C-G. Note that the unicast route matching the C-RP is needed whether 1115 or not the VRF has also imported a SAFI-129 route matching the C-RP. 1116 (If the VRF also contains receivers for C-G, and if UMH determination 1117 is being done using SAFI-129 routes, both a unicast route and a 1118 SAFI-129 matching C-RP route are needed.) 1120 Similarly, if a VRF contains a C-RP for C-G, but does not contain 1121 C-S, the VRF MUST import a unicast route matching the DR for C-S. 1122 Note that the unicast route matching the DR for C-S is needed even if 1123 UMH determination is being done using SAFI-129 routes; in that case, 1124 if the VRF also contains receivers for C-G, it needs to import a 1125 SAFI-129 route matching C-S and a unicast route matching the DR for 1126 C-S. 1128 If, for a particular extranet C-group, C-G, the customer is using 1129 "anycast-RP"([RFC3446], [RFC4610]) or MSDP [RFC3618], then all the 1130 C-RPs serving C-G need to send unicast messages to each other. Thus 1131 any VRF that contains a C-RP for C-G needs to import unicast routes 1132 matching ALL the other C-RPs that serve C-G. 1134 The need to distribute these unicast routes is usually not a problem 1135 as long as all the C-sources and C-RPs for C-G are in the same MVPN. 1136 If, however, the C-sources are not all in the same MVPN, great care 1137 must be taken to ensure that the unicast routes mentioned above are 1138 properly distributed. 1140 There may be scenarios in which all the C-sources for C-G are in the 1141 same MVPN, but there are receivers in different VPNs, and some or all 1142 of the VPNs with receivers have their own C-RPs for C-G. In this 1143 case, care must be taken to ensure that the C-RPs can all unicast to 1144 each other. 1146 4.3. Route Targets and Ambiguous UMH-Eligible Routes 1148 This section imposes constraints on the way RTs are assigned to (a) 1149 UMH-eligible routes and to (b) the BGP A-D routes that advertise 1150 P-tunnels (i.e., to BGP A-D routes that contain a PTA). The 1151 constraints specified here apply to any extranet for which the 1152 ambiguity of Section 2.2 is possible. (The conditions under which 1153 such ambiguity is possible are described in Section 2.2.) 1155 We want to ensure that, in any given VRF, the UMH-eligible route 1156 matching a given extranet C-source has an RT in common with every BGP 1157 A-D route that advertises a P-tunnel that may be used to carry 1158 extranet multicast traffic from that C-source. We also want to 1159 ensure that the UMH-eligible route matching a given extranet C-source 1160 does not have any RT in common with any BGP A-D route that advertises 1161 a P-tunnel that may be used to carry any multicast traffic from a 1162 different C-source that has the same IP address. This enables us to 1163 determine whether traffic that appears to be from the given C-source 1164 is really arriving on the "wrong tunnel", and hence is really from a 1165 different C-source with the same IP address. 1167 Suppose an IP address C-S is used in VPN-A as the address of one 1168 system, and is used in VPN-B as the address of a different system. 1169 In this case, one or more VPN-A VRFs may export a VPN-IP route whose 1170 NLRI is , and one or more VPN-B VRFs may export a VPN-IP route 1171 whose NLRI is , where RD1 != RD2. Consider two routes, R1 and 1172 R2, for which the following conditions all hold: 1174 o R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or 1175 are unicast routes matching a C-RP 1177 o R1 is exported from a VRF of VPN-A, while R2 is exported from a 1178 VRF of a different VPN, say VPN-B 1180 o R1's NLRI specifies IP address prefix S/n 1182 o R2's NLRI specifies IP address prefix S/m 1184 o m >= n, (S/m is either the same as or more specific than S/n) 1186 o There is some host address H such that: 1188 * H denotes a different system in VPN-A than in VPN-B, 1190 * H/m == S/m (so either S/m or S/n might be a longest match for H 1191 in some VRF). 1193 We impose the following constraint: RTs MUST be assigned in such a 1194 way that R1 and R2 do not have any RT in common. 1196 (This constraint is not as onerous at it may seem. Typically R1 and 1197 R2 would not have an RT in common, as that might result in their 1198 being imported into the same VRF, making the address H ambiguous in 1199 that VRF.) 1201 Sections 6 and 7 specify procedures for determining if a received 1202 C-flow has been received over the expected P-tunnel. Those 1203 procedures will not work if this constraint is violated. (The 1204 constraint described in this section is necessary but not sufficient 1205 for the procedures of those sections to work; additional constraints, 1206 covering the assignment of RTs to BGP A-D routes, are given in 1207 subsequent sections.) 1209 4.4. Dynamically Marking Extranet Routes 1211 4.4.1. The Extranet Source Extended Community 1213 Sections 4.1, 4.2, and 4.3 place specific requirements on the way in 1214 which certain VPN-IP routes are distributed. In order to ensure that 1215 these requirements are met, a VPN customer must tell its SP which 1216 routes are the matching routes for extranet C-sources and C-RPs. 1217 This may be done as part of the provisioning process. Note that this 1218 does not necessarily require customer/provider interaction every time 1219 the customer adds a new extranet C-source or C-RP, but only when the 1220 IP address of the new C-source or C-RP does not match an existing 1221 route that is already being distributed as a VPN-IP extranet route. 1222 Nevertheless, it seems worthwhile to support an OPTIONAL mechanism 1223 that allows a customer to dynamically mark certain routes as being 1224 extranet routes. 1226 To facilitate this, we define a new Transitive Opaque Extended 1227 Community (see [RFC4360], [RFC7153], and Section 9 of this document) 1228 the "Extranet Source" Extended Community. When a CE router 1229 advertises (via BGP) a route to a PE router, and the AFI/SAFI of the 1230 route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source 1231 Extended Community MAY be attached to the route. The value field of 1232 the Extended Community MUST be set to zero. By placing this Extended 1233 Community on a particular route, a CE router indicates to a PE router 1234 that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied 1235 to that route. That is, the CE router may use this Extended 1236 Community to indicate to the PE router that a particular route is to 1237 be treated as a route that matches the address of an extranet source, 1238 and exported accordingly to other VPNs. A PE router that interprets 1239 this Extended Community MUST ignore the contents of the value field. 1241 Whether a CE router uses the Extranet Source Extended Community is 1242 determined by the configuration of the CE router. If used, the set 1243 of routes to which the Extended Community is attached is also 1244 determined by configuration of the CE. Note that a particular PE 1245 router may or may not support the use of the Extranet Source Extended 1246 Community by a particular CE router; this is determined by the 1247 service agreement between the SP and its customer. 1249 If a CE is advertising SAFI-2 routes to the PE as the UMH-eligible 1250 extranet C-source and C-RP routes, and if the CE is using the 1251 Extranet Source Extended Community, it is important that the CE 1252 attach that Extended Community to the SAFI-2 routes, rather than just 1253 to the corresponding SAFI-1 routes. Otherwise extranet receivers may 1254 not be able to join the (C-S,C-G) or (C-*,C-G) multicast trees. 1256 However, if the C-sources and the C-RPs for a given extranet C-group 1257 are not all in the same VPN, the Extended Community would also have 1258 to be attached to the SAFI-1 routes that match the C-RP addresses and 1259 to the SAFI-1 routes that match the addresses of the first hop 1260 designated routers for all the C-sources. Otherwise, the first hop 1261 routers might not be able to send PIM Register messages to the C-RPs, 1262 and the C-RPs might not be able to send PIM Register-Stop messages to 1263 the first hop routers. 1265 While this Extended Community allows a customer to inform the SP 1266 dynamically that certain routes are "extranet routes", it does not 1267 allow a customer to control the set of RTs that the route will carry 1268 when it is redistributed as a VPN-IP route. Thus it is only useful 1269 when all the extranet routes from a given VRF are exported with 1270 exactly the same set of RTs. (Cf. Section 4.3.1 of [RFC4364], which 1271 does provide a mechanism that, if properly supported by the SP, 1272 allows the customer to determine the set of RTs carried by a VPN-IP 1273 route.) A CE SHOULD NOT attach the Extranet Source Extended 1274 Community to any route for which it uses another method of specifying 1275 the RTs to be carried by that route. A CE SHOULD NOT attach the 1276 Extranet Source Extended Community to a route unless all the extranet 1277 routes from the CE's VPN are intended to carry the same set of RTs. 1279 A PE SHOULD ignore the Extranet Source Extended Community if it 1280 appears on a route that the CE should not have put it on. A PE that 1281 ignores the Extranet Source Extended Community SHOULD NOT follow the 1282 procedures of Section 4.4.2. 1284 Note that misconfiguration on the CE router can result in the 1285 Extranet Source Extended Community being mistakenly attached to a 1286 route that is not intended to be exported as an extranet route. This 1287 could result in a VPN security violation. 1289 4.4.2. Distribution of Extranet Source Extended Community 1291 Suppose a PE receives from a CE a route, call it R, with the Extranet 1292 Source Extended Community. The PE must determine (via the 1293 considerations of Section 4.4.1) whether it should ignore that 1294 Extended Community on route R. If so, the procedures of the current 1295 Section are not followed. 1297 Otherwise, when the PE originates a VPN-IP route corresponding to 1298 route R, the PE MUST attach this Extended Community to that route. 1300 A Route Reflector MUST NOT add or remove the Extranet Source Extended 1301 Community from the VPN-IP routes reflected by the Route Reflector, 1302 including the case where VPN-IP routes received via IBGP are 1303 reflected to EBGP peers (inter-AS option (c), see [RFC6513] 1304 Section 10). The value of the Extended Community MUST NOT be changed 1305 by the route reflector. 1307 When re-advertising VPN-IP routes, ASBRs MUST NOT add/remove the 1308 Extranet Source Extended Community from these routes. This includes 1309 inter-AS options (b) and (c) (see [RFC6513] Section 10). The value 1310 of the Extended Community MUST NOT be changed by the ASBRs. 1312 When a PE advertises (via BGP) IP routes to a CE, these routes MUST 1313 NOT carry the Extranet Source Extended Community, unless the PE-CE 1314 connection is actually an inter-AS Option (a) connection (see 1315 [RFC6513] Section 10). When the PE-CE connection is not an inter-AS 1316 Option (a) connection, a CE that receives an IP route with the 1317 Extranet Source Extended Community MUST remove it from the route 1318 before readvertising the route. 1320 The rules for attaching the Extranet Source Extended Community to a 1321 VPN-IP route, and the rules for propagating that Extended Community, 1322 are needed in order to support the scenario in which a VPN contains 1323 an Option (a) interconnect (see Section 10 of [RFC4364]). At the 1324 Option (a) interconnect, the VPN-IP route gets translated back to an 1325 IP route, and the RTs are stripped off before the IP route is 1326 propagated. If the Extranet Source EC has also been stripped off, 1327 there is no way for the router at the other end of the Option (a) 1328 interconnect to know that the route represents an extranet source. 1329 Thus the technique of using the Extranet Source EC to dynamically 1330 signal that a particular route represents an extranet source will not 1331 work correctly across an Option (a) interconnect unless the rules 1332 this section are followed. 1334 4.5. The 'Extranet Separation' Extended Community 1336 We define a new Transitive Opaque Extended Community, the "Extranet 1337 Separation" Extended Community (see [RFC4360], [RFC7153], and 1338 Section 9 of this document). This Extended Community is used only 1339 when extranet separation is being used. Its value field MUST be set 1340 to zero upon origination, MUST be ignored upon reception, and MUST be 1341 passed unchanged by intermediate routers. A Route Reflector MUST NOT 1342 add or remove the Extranet Separation Extended Community from the 1343 routes it reflects, including the case where routes received via IBGP 1344 are reflected to EBGP peers (inter-AS option (c), see [RFC6513] 1345 Section 10). 1347 If a VRF has been provisioned to use extranet separation, and if that 1348 VRF has been provisioned to transmit any extranet C-flows on a 1349 P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*) 1350 S-PMSI A-D route, then any UMH-eligible routes that are exported from 1351 that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST 1352 carry the Extranet Separation Extended Community. In addition, if an 1353 I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route, exported from 1354 that VRF, is used to carry extranet traffic, that A-D route MUST also 1355 carry the Extranet Separation Extended Community. Further details 1356 may be found in Sections 7.3, 7.4.4, and 7.4.5. 1358 5. Origination and Distribution of BGP A-D Routes 1360 Except where otherwise specified, this section describes procedures 1361 and restrictions that are independent of the PE-PE C-multicast 1362 control protocol. 1364 5.1. Route Targets of UMH-eligible Routes and A-D Routes 1366 Suppose there is an extranet C-flow such that: 1368 o The extranet C-source of that C-flow is in VRF A-1. 1370 o One or more extranet C-receivers of that C-flow are in VRF B-1. 1372 In this case VRF A-1 MUST export a UMH-eligible route that matches 1373 the extranet C-source address, and VRF B-1 MUST import that route. 1374 In addition, VRF A-1 MUST export an Intra-AS I-PMSI A-D route or an 1375 S-PMSI A-D route specifying the P-tunnel through which it will send 1376 the data traffic of the given extranet C-flow, and VRF B-1 MUST 1377 import that route. If BGP is the PE-PE C-multicast control protocol, 1378 then under certain conditions (as specified in [RFC6514]), VRF A-1 1379 may also need to export a Source Active A-D route specifying that it 1380 contains a source of the given C-flow, and VRF B-1 must import that 1381 Source Active A-D route. That is, in order for VRF B-1 to receive a 1382 C-flow from, a given extranet C-source contained in VRF A-1, VRF A-1 1383 MUST export a set of A-D routes that are "about" that source, and VRF 1384 B-1 MUST import them. 1386 One way to ensure this is to provision an RT that is carried by all 1387 the routes exported from VRF A-1 that are "about" a given extranet 1388 C-source, and to provision this RT as an import RT at any VRF (such 1389 as VRF B-1) that is allowed to receive extranet flows from source. 1391 If the "single PMSI per C-flow" transmission model is being used 1392 (with or without extranet separation), there is a an additional 1393 requirement, stated below, on the way RTs are provisioned, as the RTs 1394 carried by a UMH-eligible route that matches a given extranet 1395 C-source may need to be used to identify the A-D routes that are 1396 "about" that source. 1398 Consider the following scenario: 1400 o IP address S is the address of one system in VPN-A, and of a 1401 different system in VPN-B. 1403 o VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching 1404 route for S. 1406 o VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a 1407 P-tunnel through which VRF A-1 may send traffic whose C-source is 1408 S, where one of the following conditions holds: 1410 * P1 is an I-PMSI A-D route, OR 1412 * P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or 1413 (C-*,C-G), OR 1415 * P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or 1416 (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) 1417 P-tunnel" policy is not provisioned. 1419 * P1 is a Source Active A-D route whose NLRI contains (C-S,C-G). 1421 o VRF B-1 on PE1 exports a UMH-eligible route R2, which is a 1422 matching route for S. 1424 o VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a 1425 P-tunnel on which VRF B-1 may send traffic whose C-source is S, 1426 where one of the following conditions holds: 1428 * P2 is an I-PMSI A-D route, OR 1429 * P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or 1430 (C-*,C-G), OR 1432 * P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or 1433 (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) 1434 P-tunnel" policy is not provisioned. 1436 * P2 is a Source Active A-D route whose NLRI contains (C-S,C-G) 1438 As already specified in Section 4.1, there MUST NOT be any RT that is 1439 common to both R1 and R2. In addition, the following set of rules 1440 for RT assignment MUST be followed when extranets are supported. 1441 This set of rules supports all the extranet transmission models 1442 described in this specification: 1444 o There MUST NOT be any RT that is carried by both P1 and P2. 1446 o The intersection of the set of RTs carried by P1 and the set of 1447 RTs carried by R1 MUST be non-null, and any VRF that imports both 1448 P1 and R1 MUST be configured with an import RT from this 1449 intersection. 1451 o The intersection of the set of RTs carried by P2 and the set of 1452 RTs carried by R2 MUST be non-null, and any VRF that imports both 1453 P2 and R2 MUST be configured with an import RT from this 1454 intersection. 1456 Suppose VRF C-1 on PE2 imports P1 and R1 from VRF A-1, while also 1457 importing P2 from VRF B-1. Since: 1459 o R1 is VRF C-1's route to S, and 1461 o R1 has an RT in common with P1, and 1463 o R1 has no RT in common with P2 1465 it can be concluded that VRF C-1 should expect that multicast traffic 1466 from S will arrive on the P-tunnel specified in P1. See Section 6 1467 and Section 7 for more details on determining the expected P-tunnel 1468 for a given extranet C-flow. 1470 While the assignment of import and export RTs to routes is a 1471 deployment and provisioning issue rather than a protocol issue, it 1472 should be understood that failure to follow these rules is likely to 1473 result in VPN security violations. 1475 5.2. Considerations for Particular Inclusive Tunnel Types 1477 An Inclusive Tunnel (sometimes referred to as an "Inclusive Tree", 1478 see Section 2.1.1 of [RFC6513]) is a tunnel that, by default, carries 1479 all the multicast traffic of a given MVPN that enters the backbone 1480 network via a particular PE. An Inclusive Tunnel is advertised in 1481 the PTA of an I-PMSI A-D route. 1483 5.2.1. RSVP-TE P2MP or Ingress Replication 1485 This section applies when Inclusive Tunnels are created using either 1486 RSVP-TE P2MP or Ingress Replication. 1488 Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and 1489 that VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP 1490 RSVP-TE P-tunnel or an Ingress Replication P-tunnel to carry extranet 1491 traffic. 1493 In order for VRF-S to set up the P2MP RSVP-TE or Ingress Replication 1494 P-tunnel, it must know all the PEs that are leaf nodes of the 1495 P-tunnel, and to learn this it must import an Intra-AS I-PMSI A-D 1496 route from every VRF that needs to receive data through that tunnel. 1498 Therefore if VRF-R contains an extranet C-receiver that is allowed by 1499 policy to receive extranet flows from C-S, the RT(s) carried by the 1500 Intra-AS I-PMSI A-D routes originated by VRF-R MUST be such that 1501 those Intra-AS I-PMSI A-D routes will be imported into VRF-S. 1503 In the case of Ingress Replication, this has the following 1504 consequence. If an egress PE has n VRFs with receivers for a flow 1505 that VRF-S transmits on its I-PMSI, that egress PE will receive n 1506 copies of the same packet, one for each of the n VRFs. 1508 Note that Section 9.1.1 of [RFC6514] prohibits the Leaf Information 1509 Required flag from being set in the PTA of an Intra-AS I-PMSI A-D 1510 route. If this prohibition is ever removed, the requirement of this 1511 section will apply only if VRF-S does not set that flag. 1513 5.2.2. Ingress Replication 1515 This section applies only when Inclusive Tunnels are created via 1516 Ingress Replication. 1518 [RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be 1519 instantiated by Ingress Replication. The concept of an IR P-tunnel, 1520 and the procedures for supporting IR P-tunnels, are explained more 1521 fully in [MVPN-IR]. An IR P-tunnel can be thought of as a P2MP tree 1522 in which a packet is transmitted from one node on the tree to another 1523 by being encapsulated and sent through a unicast tunnel. 1525 As discussed in Section 2, when I-PMSIs are used to support 1526 extranets, egress PEs MUST have the ability to discard customer 1527 multicast data packets that arrive on the wrong P-tunnel. When 1528 I-PMSIs are instantiated by IR, this implies that the following two 1529 procedures MUST be followed: 1531 1. One of the following three procedures MUST be followed: 1533 a. the "Single Forwarder Selection" procedures of [RFC6513] 1534 Section 9.1.2, 1536 b. the "Native PIM Methods" procedures of [RFC6513] 1537 Section 9.1.3 1539 c. the unicast encapsulation used to transmit packets along the 1540 IR P-tunnel is such as to enable the receiving node to 1541 identify the transmitting node (note that this would not be 1542 the case if, e.g., the unicast tunnels were MP2P LSPs); 1544 and 1546 2. If a PE assigns an MPLS label value in the PMSI Tunnel attribute 1547 of an Intra-AS or Inter-AS I-PMSI A-D route that it originates, 1548 that label value MUST NOT appear in the PMSI Tunnel attribute of 1549 any other I-PMSI or S-PMSI A-D route originated by the same PE. 1551 Failure to follow these procedures would make it impossible to 1552 discard packets that arrive on the wrong P-tunnel, and thus could 1553 lead to duplication of data. 1555 If it is desired to support extranet while also using IR to 1556 instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs 1557 instead of I-PMSIs. (See [RFC6625], as well as Sections 7.2.2, 1558 7.3.2, and 7.4.4 of this document.) This has much the same effect in 1559 the data plane, and there are no restrictions on the type of unicast 1560 tunnel that can be used for instantiating S-PMSIs. 1562 Section 6.4.5 of [RFC6513] describes a way to support VPNs using 1563 I-PMSIs that are instantiated by IR, using no S-PMSIs, but using 1564 "explicit tracking" to ensure that a C-flow goes only to egress PEs 1565 that have receivers for it. This document does not provide 1566 procedures to support extranet using that model. 1568 6. When PIM is the PE-PE C-multicast Control Plane 1570 As specified in [RFC6513], when PIM is used as the PE-PE C-multicast 1571 control plane for a particular MVPN, there is a "Multidirectional 1572 Inclusive Provider Multicast Serivce Interface" (MI-PMSI) for that 1573 MVPN, and all the PEs of that MVPN must be able to send and receive 1574 on that MI-PMSI. Associated with each VRF of the MVPN is a PIM 1575 C-instance, and the PIM C-instance treats the MI-PMSI as if it were a 1576 LAN interface. That is, the "ordinary" PIM procedures run over the 1577 MI-PMSI just as they would over a real LAN interface, except that the 1578 data plane and control plane "RPF checks" need to be modified. 1579 Section 5.2 of [RFC6513] specifies the RPF check modifications for 1580 non-extranet MVPN service. 1582 For example, suppose that there are two VPNs, VPN-S and VPN-R. In 1583 the absence of extranet support, all the VRFs of VPN-S are connected 1584 via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of 1585 VPN-R are connected via another ("the VPN-R MI-PMSI"). If we want to 1586 provide extranet service in which the extranet C-sources are attached 1587 to some set of VPN-S VRFs, while the extranet C-receivers are 1588 attached to some set of VPN-R VRFs, then we have two choices: 1590 1. either the VPN-R VRFs need to join the VPN-S MI-PMSI, or 1592 2. the VPN-S VRFs need to join the VPN-R MI-PMSI. 1594 The first choice is used to support the "single PMSI per C-flow" 1595 transmission model. The second choice is used to support the 1596 "multiple PMSIs per C-flow" transmission model. 1598 Procedures for both models are described below. 1600 To support these models, it must be possible to determine which 1601 I-PMSI A-D routes are associated with the VPN-S I-PMSI, and which are 1602 associated with the VPN-R I-PMSI. Procedures are given for assigning 1603 RTs to these routes in a way that makes this determination possible. 1605 Both models allow the use of S-PMSIs to carry multicast data traffic. 1606 If a VRF containing receivers can receive from multiple MI-PMSIs, 1607 each S-PMSI must be uniquely associated with a particular MI-PMSI. 1608 Procedures are given for assigning RTs to these routes in a way that 1609 makes this determination possible. 1611 All the procedures specified in Sections 3, 4, and 5 still apply. 1613 Note that there are no special extranet procedures for Inter-AS 1614 I-PMSI A-D routes or for Leaf A-D routes. Source Active A-D routes 1615 are not used when PIM is the PE-PE C-multicast protocol. 1617 6.1. Provisioning VRFs with RTs 1619 6.1.1. Incoming and Outgoing Extranet RTs 1621 In the absence of extranet service, suppose that each VRF of a given 1622 VPN, call it VPN-S, is configured with RT-S as its import and export 1623 RT, and that each VRF of a second VPN, call it VPN-R, is configured 1624 with RT-R as its import and export RT. We will refer to RT-S and 1625 RT-R as "non-extranet RTs". 1627 Now suppose that VPN-S contains some extranet C-sources, and VPN-R 1628 contains some extranet C-receivers that are allowed by policy to 1629 receive extranet C-flows from the VPN-S extranet C-sources. 1631 To set up this S-to-R extranet, it is REQUIRED to provision an 1632 additional RT, call it RT-S-to-R, whose value is, in general, 1633 distinct from RT-S and RT-R. 1635 A VPN-S VRF that contains extranet C-sources allowed to transmit to 1636 VPN-R MUST be configured with RT-S-to-R as an "Outgoing Extranet RT". 1638 A VPN-R VRF that contains extranet C-receivers allowed to received 1639 from VPN-S MUST be configured with RT-S-to-R as an "Incoming Extranet 1640 RT". 1642 Note that the terms "Incoming" and "Outgoing" in this context refer 1643 to the direction of multicast data packets relative to the VRF. 1645 The Incoming Extranet RTs and Outgoing Extranet RTs that are 1646 configured for a given VRF serve as import RTs for that VRF. They 1647 also serve as export RTs, but only for specific routes as specified 1648 in Section 6.1.2 below. 1650 Note that any VRF that contains both extranet C-sources and extranet 1651 C-receivers MUST be configured with both Outgoing and Incoming 1652 Extranet RTs. 1654 A VRF MAY be configured with more than one Incoming and/or Outgoing 1655 Extranet RT. 1657 If it happens to be the case that all C-sources in VPN-S are extranet 1658 C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be 1659 configured such that RT-S is both a non-extranet RT and an Outgoing 1660 Extranet RT, and VPN-R VRFs MAY be configured such that RT-S is an 1661 Incoming Extranet RT. 1663 6.1.2. UMH-eligible Routes and RTs 1665 Suppose R1 is a route, exported from a VPN-S VRF, matching an 1666 extranet C-source that is allowed by policy to transmit to VPN-R. 1667 Then R1 MUST carry the Outgoing Extranet RT used for the S-to-R 1668 extranet. This will cause the route to be imported into the VPN-R 1669 VRFs that have extranet C-receivers that are allowed by policy to 1670 receive from VPN-S. 1672 The rules of Section 4 regarding route targets and ambiguous 1673 addresses still apply. 1675 6.1.3. PIM C-Instance Reverse Path Forwarding Determination 1677 Suppose a PIM control message, call it M, is received by a given VRF 1678 V, from a particular P-tunnel T. In order to process control message 1679 M, the PIM C-instance associated with VRF V may need to do an "RPF 1680 determination" (see Section 5.2.2 of RFC 6513) for a particular IP 1681 prefix S. RPF determination is based upon the rules for UMH 1682 selection as specified in Section 5.1 of RFC 6513. 1684 This document adds an additional constraint on the UMH selection 1685 procedure. When doing RPF determination for a PIM control message 1686 received over a P-tunnel, a route matching prefix S is not considered 1687 to be eligible for UMH selection unless there is an RT, call it RT1, 1688 configured as one of V's Outgoing Extranet RTs, such that the 1689 following two conditions both hold: 1691 1. The route matching S is exported from VRF V carrying RT1, and 1693 2. An I-PMSI A-D route advertising P-tunnel T (in its PTA) has been 1694 imported into VRF V, and that I-PMSI A-D route carries RT1. 1696 6.2. Single PMSI per C-flow Model 1698 In this model, if a VPN-S VRF has extranet multicast C-sources, and a 1699 VPN-R VRF has extranet multicast C-receivers allowed by policy to 1700 receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins 1701 the MI-PMSI that VPN-S uses for its non-extranet traffic. 1703 6.2.1. Forming the MI-PMSIs 1705 Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], 1706 each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing 1707 a PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as 1708 part of the VPN-S MI-PMSI. In the absence of extranet service, this 1709 route carries the VRF's non-extranet RT, RT-S. When extranet service 1710 is provided (using the "single PMSI per C-flow" model), this route 1711 MUST also carry each of the VRF's Outgoing Extranet RTs. 1713 Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], 1714 each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing 1715 a PTA specifying the P-tunnel to be used as part of the VPN-R MI- 1716 PMSI. This route carries the VRF's non-extranet RT RT-R. When 1717 extranet service is provided (using the "single PMSI per C-flow" 1718 model), the VPN-R VRF MUST also originate one or more additional 1719 Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- 1720 AS I-PMSI A-D route for each Incoming Extranet RT with which it has 1721 been configured; each such route will carry exactly one of the 1722 configured Incoming Extranet RTs. 1724 Note that when a VRF originates more than one Intra-AS I-PMSI A-D 1725 route, each of them MUST contain a different RD in its NLRI. In 1726 addition, we add the requirement that any pair of such routes MUST 1727 NOT contain an RT in common. 1729 A VRF with extranet C-sources MUST join the P-tunnels advertised in 1730 the imported I-PMSI A-D routes that carry its non-extranet RT or any 1731 of its Outgoing Extranet RTs. This set of P-tunnels will be treated 1732 as instantiating a single MI-PMSI, and the associated PIM C-instance 1733 will treat that MI-PMSI as a single LAN, and will run PIM procedures 1734 on that LAN, as specified in [RFC6513]. The fact that the MI-PMSI 1735 attaches to VRFs of different VPNs is not known to the PIM C-instance 1736 of the VRF containing the sources. 1738 A VRF with extranet C-receivers MUST join the P-tunnels advertised in 1739 all the imported I-PMSI A-D routes. The set of P-tunnels advertised 1740 in the I-PMSI A-D routes that carry a particular Incoming Extranet RT 1741 are treated as instantiating a particular MI-PMSI. So a VRF with 1742 C-receivers will "see" several MI-PMSIs, one corresponding to the 1743 non-extranet, and as many as one for each configured Incoming 1744 Extranet RT. The PIM C-instance associated with the VRF will treat 1745 each of these MI-PMSIs as a separate LAN interface. 1747 As an example, suppose: 1749 o All VPN-R VRFs are configured with RT-R as a non-extranet import 1750 and export RT, 1752 o VPN-R VRFs with extranet receivers are configured with RT-S-to-R 1753 as an Incoming Extranet RT, 1755 o VPN-S VRFs with extranet transmitters are configured: 1757 * with RT-S as a non-extranet import and export RT 1758 * with a list of IP addresses that are the addresses of the 1759 extranet sources 1761 * with RT-S-to-R as an Outgoing Extranet RT 1763 Then VPN-S VRFs will export UMH-eligible routes matching extranet 1764 C-sources, and these routes will carry both RT-S and RT-S-to-R. Each 1765 VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries 1766 both RT-S and RT-S-to-R. 1768 VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes: 1769 one carrying RT-R, and one carrying RT-S-to-R. The Intra-AS I-PMSI 1770 A-D route with RT-S-to-R will be imported into the VPN-S VRFs. 1772 VPN-R will regard all the I-PMSI A-D routes it has exported or 1773 imported with RT-S-to-R as part of a single MI-PMSI. VPN-R will 1774 regard all the I-PMSI A-D routes it has exported or imported with 1775 RT-R as part of a second MI-PMSI. The PIM C-instance associated with 1776 a VPN-R VRF will treat the two MI-PMSIs as two separate LAN 1777 interfaces. However, the VPN-S VRFs will regard all the I-PMSI A-D 1778 routes imported with RT-S or RT-S-to-R as establishing only a single 1779 MI-PMSI. One can think of this as follows: the VPN-R VRFs have 1780 joined the VPN-S MI-PMSI, as well as the VPN-R MI-PMSI. 1782 Extranets consisting of more than two VPNs are easily supported as 1783 follows. Suppose there are three VPNs, VPN-A, VPN-B, and VPN-C. 1784 VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers 1785 for both VPN-A extranet C-sources and VPN-B extranet C-sources. In 1786 this case, the VPN-C VRFs that have receivers for both VPN-A and 1787 VPN-B sources may be provisioned as follows. These VPN-C VRFs may be 1788 provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and 1789 RT-B-to-C as Incoming Extranet RTs. In this case, the VPN-C VRFs 1790 that are so provisioned will originate three Intra-AS I-PMSI A-D 1791 routes (each with a different RD in its NLRI), each of which carries 1792 exactly one of the three RTs just mentioned. The VPN-B VRFs with 1793 extranet C-sources will be provisioned with RT-B-to-C as an Outgoing 1794 Extranet RT, and the VPN-A VRFs are provisioned with RT-A-to-C as an 1795 Outgoing Extranet RT. The result will be that the PIM C-instance 1796 associated with a VPN-C VRF will see three LAN interfaces: one for 1797 the non-extranet, one for each of the two extranets. This 1798 generalizes easily to the case where there are VPN-C receivers in n 1799 different extranets (i.e., receiving extranet flows whose sources are 1800 in n different VPNs). 1802 Suppose again that there are there are three VPNs, VPN-A, VPN-B, and 1803 VPN-C. But in this example, VPN-A is the only one with extranet 1804 sources, while VPN-B and VPN-C both have receivers for the VPN-A 1805 extranet sources. This can be provisioned as either one extranet or 1806 as two. 1808 To provision it as one extranet, the VPN-A VRFs are configured with 1809 one Outgoing Extranet RT, call it "RT-A-extranet". The VPN-B and 1810 VPN-C VRFs with extranet receivers will be provisioned with RT- 1811 A-extranet as Incoming Extranet RT. Thus the VPN-B and VPN-C VRFs 1812 will each originate two Intra-AS I-PMSI A-D routes, one for non- 1813 extranet, and one for the extranet. The Intra-AS I-PMSI A-D route, 1814 from a given VRF, for the extranet will carry RT-A-extranet, but will 1815 not share any RT with the non-extranet A-D routes exported from the 1816 same VRF. 1818 The result is that the VPN-B and VPN-C VRFs each belong to two MI- 1819 PMSIs, one for the extranet and one for the intranet. The MI-PMSI 1820 for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs. 1822 Alternatively, one could provision the VPN-A VRFs so that some UMH- 1823 eligible extranet source routes carry an RT which we will call "RT-A- 1824 to-B", and some carry an RT which we will call "RT-A-to-C". The 1825 VPN-A VRFs would be configured with both of these as Outgoing 1826 Extranet RTs. To allow an extranet flow from a VPN-A source to have 1827 both VPN-B and VPN-C receivers, the UMH-eligible route for that 1828 source would carry both RTs. VPN-B VRFs (but not VPN-C VRFs) would 1829 be provisioned with RT-A-to-B as an Incoming Extranet RT. VPN-C VRFs 1830 (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an an 1831 Incoming Extranet RT. 1833 Following the rules above, if any VPN-A extranet source is to have 1834 both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each 1835 originate two I-PMSI A-D routes, one for extranet and one for non- 1836 extranet. The single Intra-AS I-PMSI A-D route originated by the 1837 VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as 1838 well as VPN-A's non-extranet RT). The extranet I-PMSI A-D route 1839 originated from a VPN-B VRF would have RT-A-to-B, and the extranet 1840 I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C. 1842 If a given VRF contains both extranet C-receivers and extranet 1843 C-sources, the procedures described above still work, as the VRF will 1844 be configured with both Incoming Extranet RTs and Outgoing Extranet 1845 RTs; the VRF functions both as a VPN-S VRF and as a VPN-R VRF. 1847 6.2.2. S-PMSIs 1849 When PIM is used as the PE-PE C-multicast control plane, every S-PMSI 1850 is considered to be part of the "emulated LAN" that "corresponds" to 1851 a particular MI-PMSI. 1853 When the bindings of C-flows to particular S-PMSIs are announced via 1854 S-PMSI Join Messages ([RFC6513], Section 7) sent on the MI-PMSI, the 1855 S-PMSI is considered to be part of the same LAN interface as the 1856 corresponding MI-PMSI. 1858 When the bindings of C-flows to particular S-PMSIs are announced via 1859 S-PMSI A-D routes, then any S-PMSI A-D route exported from that VRF 1860 MUST have an RT in common with exactly one of the Intra-AS A-D routes 1861 exported from that VRF, and this MUST be one of the VRF's Outgoing 1862 Extranet RTs. Further, the S-PMSI A-D route MUST NOT have an RT in 1863 common with any other Intra-AS A-D route exported from a VRF on the 1864 same PE. A given S-PMSI A-D route will be considered to "correspond" 1865 to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the 1866 same PE) with which it shares an RT. 1868 The MI-PMSI that corresponds to a given S-PMSI is determined as 1869 follows: 1871 o If there is an Intra-AS I-PMSI A-D route originated by the same PE 1872 that originated the S-PMSI A-D route, and if the those two routes 1873 have an RT in common, and if that RT is one of the VRF's Incoming 1874 Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated 1875 with that Intra-AS I-PMSI A-D route. 1877 o Otherwise, if there is an Inter-AS I-PMSI A-D route originated in 1878 the same AS as the S-PMSI A-D route, and if the those two routes 1879 have an RT in common, and if that RT is one of the VRF's Incoming 1880 Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated 1881 with that Inter-AS I-PMSI A-D route. 1883 o Otherwise, there must be a configuration error (a violation of the 1884 requirements of Sections 3, 4, and 5 of this document). 1886 When wildcard S-PMSIs are used, the rules given in [RFC6625] for 1887 determining whether a given S-PMSI A-D route is a "match for 1888 reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows: 1890 A given S-PMSI A-D route MUST NOT be considered to be a "match for 1891 reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS that 1892 S-PMSI A-D route "corresponds" (as defined above) to the MI-PMSI 1893 that is the incoming interface for the given state. 1895 The rules given in [RFC6625] for determining whether a given S-PMSI 1896 A-D route is a "match for transmission" are unchanged. 1898 6.2.3. Sending PIM Control Packets 1900 Suppose a PE, say PE1, receives a PIM Join(S,G) from a CE, over a VRF 1901 interface that is associated with a VPN-R VRF. The PE does the RPF 1902 check for S by looking up S in the VPN-R VRF. The PIM C-instance 1903 associated with that VRF must determine the correct P-tunnel over 1904 which to send a PIM Join(S,G) to other PEs. 1906 To do this, PE1 finds, in the VRF associated with the interface over 1907 which the Join was received, the selected UMH route for S, following 1908 the procedures of Section 5.1 of [RFC6513]. PE1 determines the set 1909 of RTs carried by that route. PE1 then checks to see if there is an 1910 Intra-AS I-PMSI A-D route, currently originated by PE1, that has an 1911 RT in common with the selected UMH route for S. 1913 If the rules of Sections 3, 4, and 5 have been followed, each of 1914 PE1's selected UMH routes will share an RT with a single one of PE1's 1915 currently originated Intra-AS I-PMSI A-D routes. If this is so, the 1916 Join is sent on the P-tunnel advertised in the PTA of that route. 1917 Otherwise, the Join MUST NOT be sent. 1919 In essence, this procedure makes the RPF check for C-S resolve to the 1920 MI-PMSI that is serving as the next hop "interface" to C-S. 1922 If a PE receives a PIM Join(*,G) from a CE, the procedure for doing 1923 the RPF check is the same, except that the selected UMH route will be 1924 a route to the C-RP associated with the C-G group. 1926 6.2.4. Receiving PIM Control Packets 1928 When a PIM C-instance receives a PIM control message from a P-tunnel, 1929 it needs to identify the message's "incoming interface". This 1930 incoming interface is the MI-PMSI of which the P-tunnel is a part. 1932 6.2.5. Sending and Receiving Data Packets 1934 The rules for choosing the PMSI on which to send a multicast data 1935 packet are as specified in [RFC6513] and [RFC6625], with one new 1936 restriction: a VPN-S VRF always transmits a multicast data packet 1937 either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the 1938 VPN-S MI-PMSI. From the perspective of the PIM C-instance, there is 1939 only one outgoing interface. 1941 When a PIM C-instance receives a multicast data packet from a given 1942 P-tunnel, and that P-tunnel is being used to instantiate an MI-PMSI, 1943 the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and 1944 6.2.2) is considered to be the packet's "incoming interface". If the 1945 packet is received on a P-tunnel that was advertised in an S-PMSI A-D 1946 route, the packet's "incoming interface" is the MI-PMSI to which that 1947 S-PMSI route corresponds, as defined in Section 6.2.2. Ordinary PIM 1948 rules for data plane RPF check apply. 1950 Following ordinary PIM procedures, packets arriving from an 1951 unexpected incoming interface are discarded. This eliminates any 1952 problems due to the ambiguities described in Sections 2.1 and 2.2. 1954 6.3. Multiple PMSIs per C-flow Model 1956 In this model, if a VPN-S VRF has extranet multicast C-sources, and a 1957 VPN-R VRF has extranet multicast C-receivers allowed by policy to 1958 receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins 1959 the MI-PMSI that VPN-R uses for its non-extranet traffic. 1961 In the "single PMSI per C-flow" transmission model (as described in 1962 Section 6.2), a PE that needs to transmit a multicast data packet to 1963 a set of other PEs transmits the packet on a single PMSI. This means 1964 that if a packet needs to be transmitted from a VPN-A VRF and 1965 received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel 1966 from which the VPN-B and VPN-C VRFs can both receive packets. 1968 In the "multiple PMSIs per C-flow" transmission model, a PE that 1969 needs to transmit a multicast data packet to a set of other PEs may 1970 transmit the packet on several different PMSIs. (Of course, any 1971 given packet is transmitted only once on a given P-tunnel.) For 1972 example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B 1973 receiver, and a VPN-C receiver, there could be one PMSI that the 1974 VPN-A VRF uses to transmit the packet to the VPN-B VRFs, and another 1975 PMSI that the VPN-A VRF uses to transmit the packet to the VPN-C 1976 VRFs. 1978 6.3.1. Forming the MI-PMSIs 1980 Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], 1981 each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing 1982 a PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as 1983 part of the VPN-R MI-PMSI. In the absence of extranet service, this 1984 route carries the VRF's non-extranet RT, RT-R. When extranet service 1985 is provided (using the "single PMSI per C-flow" model), this route 1986 MUST also carry each of the VRF's Incoming Extranet RTs. 1988 Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], 1989 each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing 1990 a PTA specifying the P-tunnel to be used as part of the VPN-S MI- 1991 PMSI. This route carries the VRF's non-extranet RT RT-S. When 1992 extranet service is provided using the "multiple PMSI per C-flow" 1993 model, the VPN-S VRF MUST also originate one or more additional 1994 Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- 1995 AS I-PMSI A-D route for each outgoing extranet RT with which it has 1996 been configured; each such route will have a distinct RD, and will 1997 carry exactly one of the configured Outgoing Extranet RTs. 1999 As with the "single PMSI per C-flow" transmission model, VRFs 2000 containing extranet C-receivers need to import UMH-eligible extranet 2001 C-source routes from VRFs containing C-sources. This is ensured by 2002 the rules of 3, 4, and 5. 2004 However, in the "multiple PMSIs per C-flow model", a VRF containing 2005 only C-receivers originates only a single Intra-AS I-PMSI A-D route, 2006 carrying the non-extranet RT and all the Incoming Extranet RTs. 2008 When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes 2009 that carry the non-extranet RT or one of the Incoming Extranet RTs, 2010 the P-tunnels specified in the PTA of all such routes are considered 2011 to be part of the same MI-PMSI. I.e., the associated PIM C-instance 2012 will treat them as part of a single interface. 2014 In this model, it is the VRF containing extranet C-sources that MUST 2015 originate multiple Intra-AS I-PMSI A-D routes. Each such route MUST 2016 have a distinct RD, and the set of RTs carried by any one of these 2017 routes MUST be disjoint from the set carried by any other. There 2018 MUST be one such route for each of the VRF's Outgoing Extranet RTs, 2019 and each such route MUST carry exactly one of the VRF's Outgoing 2020 Extranet RTs. The VRFs containing extranet C-sources MUST also 2021 import all the A-D routes originated by the VRFs containing extranet 2022 C-receivers. If a set of originated and/or imported Intra-AS I-PMSI 2023 A-D routes have an RT in common, and that RT is one of the VRF's 2024 Outgoing Export RTs, then those routes are considered to be "about" 2025 the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI 2026 as a LAN Interface. 2028 In effect, if VPN-S has only extranet C-sources and VPN-R has only 2029 extranet C-receivers, this model has the VPN-S VRFs join the VPN-R 2030 MI-PMSI. The VPN-S VRFs will thus be attached to multiple MI-PMSIs, 2031 while the VPN-R VRFs are attached to only one. The fact that the 2032 VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM 2033 C-instance at the VPN-R VRFs. 2035 If a VPN-A VRF has extranet C-sources allowed to send to C-receivers 2036 in a VPN-B VRF, and the VPN-B VRF has C-sources allowed to send to 2037 C-receivers in the VPN-A VRF, the above procedures still work as 2038 specified. 2040 Following normal PIM procedures, when the PIM C-instance at a VRF 2041 with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G) 2042 over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the 2043 MI-PMSI over which the Join was received may be added to the set of 2044 outgoing interfaces for that multicast state. If n MI-PMSIs are 2045 added to the outgoing interface list for a particular multicast 2046 state, a multicast data packet may need to be replicated n times, and 2047 transmitted once on each of the n MI-PMSIs. 2049 Since the all multicast data packets received from another PE are 2050 received over a single emulated LAN, it is not necessary to have any 2051 special procedures to determine a packet's "incoming interface". The 2052 ambiguities described in Section 2.1 and Section 2.2 do not occur, 2053 because a VPN-R VRF can only receive multicast data traffic that has 2054 been requested by a VPN-R VRF. 2056 7. When BGP is the PE-PE C-multicast Control Plane 2058 This document assumes that if BGP is used as the PE-PE C-multicast 2059 control plane, the "Single PMSI per C-flow" model is used. 2060 Procedures for providing the "Multiple PMSIs per C-flow" model with 2061 BGP C-multicast are outside the scope of this document. 2063 When BGP is used as the C-multicast control plane, the Single PMSI 2064 per C-flow model may be used either with or without "extranet 2065 separation". (Recall that "extranet separation" means that no 2066 P-tunnel can carry both traffic from extranet sources and traffic 2067 from non-extranet sources.) In either case, the data traffic may be 2068 carried on inclusive tunnels only, or on selective tunnels only 2069 (known as the "S-PMSI only" model), or on a combination of inclusive 2070 and selective tunnels. This is determined by provisioning. The 2071 procedures specified below support all three choices. 2073 Note that there are no special extranet procedures for Inter-AS 2074 I-PMSI A-D routes or for Leaf A-D routes. 2076 7.1. Originating C-multicast Routes 2078 This section applies whether extranet separation is used or not. 2080 When it is necessary to originate a C-multicast Source Tree Join for 2081 (C-S,C-G), a PE must follow the procedures of Section 11.1.3 2082 ("Constructing the rest of the C-multicast route") of [RFC6514] to 2083 find the selected UMH route for C-S. When it is necessary to 2084 originate a C-multicast Shared Tree Join for (C-*,C-G),where C-G is 2085 an ASM group, a PE must follow the procedures of that section to find 2086 the selected UMH route for C-G's C-RP. 2088 Section 11.1.3 of [RFC6514] specifies how information from the 2089 selected UMH route is used to find an Intra-AS I-PMSI A-D route or an 2090 Inter-AS I-PMSI A-D route. Information from that I-PMSI A-D route is 2091 then used to construct part of the C-multicast route. 2093 For extranet, this specification modifies the procedures of 2094 Section 11.1.3 of [RFC6514] as follows. The rules given in 2095 Section 7.4.5 ("I-PMSI A-D Routes") of this document are used to find 2096 the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that 2097 "corresponds to" the selected UMH route. (That is, the rules of 2098 Section 7.4.5 of this document replace the rules given in 2099 Section 11.1.3 of [RFC6514] for finding the Inter-AS or Intra-AS 2100 I-PMSI A-D route.) 2102 Information from this I-PMSI A-D route is then used, as specified in 2103 Section 11.1.3 of [RFC6514], to construct the C-multicast route. 2105 7.2. Originating A-D Routes Without Extranet Separation 2107 7.2.1. Intra-AS I-PMSI A-D Routes 2109 Consider a VRF, call it VRF-S, that contains extranet C-sources, and 2110 that exports UMH-eligible routes matching those C-sources. The VRF 2111 may also originate and export an Intra-AS I-PMSI A-D route. 2113 As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route 2114 is originated by and exported from VRF-S, the RTs carried by that 2115 route MUST be chosen such that every VRF that imports a UMH-eligible 2116 route from VRF-S also imports this Intra-AS I-PMSI A-D route. 2118 If inclusive P-tunnels are being used to carry extranet C-flows, 2119 there are additional requirements on the way the RTs carried by the 2120 Intra-AS I-PMSI A-D routes must be chosen, as specified in the 2121 following paragraph. 2123 If VRF-S is using inclusive P-tunnels, but is not using extranet 2124 separation, there is one inclusive P-tunnel rooted at VRF-S, and this 2125 tunnel carries both extranet and non-extranet C-flows. This 2126 inclusive tunnel is identified in the PMSI Tunnel Attribute (PTA) of 2127 the Intra-AS I-PMSI A-D route originated from VRF-S. The set of RTs 2128 carried by this Intra-AS I-PMSI A-D route MUST be chosen so as to 2129 ensure that every VRF that imports a UMH-eligible route from this 2130 VRF-S also imports this Intra-AS I-PMSI A-D route. Further, the set 2131 of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen such 2132 that it has at least one RT in common with every UMH-eligible route 2133 that is exported from the VRF. 2135 7.2.2. S-PMSI A-D Routes 2137 Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose 2138 that R-SP is used to bind some or all of the extranet C-flows from a 2139 given extranet C-source to a given selective P-tunnel. Let R-UMH be 2140 a UMH-eligible route that is exported from VRF-S and that matches the 2141 given extranet C-source. Then R-SP and R-UMH MUST have at least one 2142 RT in common. Further, the RTs carried by these two routes MUST be 2143 such that every VRF that imports R-UMH also imports R-SP. These 2144 rules apply whether or not R-SP uses wildcards [RFC6625]. 2146 An implementation MUST allow the set of RTs carried by the S-PMSI A-D 2147 routes to be specified by configuration. In the absence of such 2148 configuration, an S-PMSI A-D route originated by a given VRF X MUST 2149 carry a default set of RTs, as specified by the following rules: 2151 1. By default an S-PMSI A-D route originated by VRF X for a given 2152 (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible 2153 route originated by VRF X that matches C-S. 2155 2. By default an S-PMSI A-D route originated by VRF X for a given 2156 (C-*,C-G) carries as its RTs a set union of all RT(s) of the UMH- 2157 eligible route(s) matching the multicast C-sources contained in 2158 VRF X that could originate traffic for that C-G. Moreover, if 2159 the VRF contains (as defined in Section 1.1) the C-RP of C-G, 2160 then this set union also includes the RT(s) of the UMH-eligible 2161 route matching C-RP, and of the unicast VPN-IP route matching 2162 C-RP. 2164 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF X 2165 is to be used for both extranet and non-extranet traffic, it 2166 carries the same RTs that would be carried (as specified in 2167 Section 7.2.1) by an I-PMSI A-D route originated by VRF X if that 2168 I-PMSI A-D route were advertising an inclusive P-tunnel for 2169 carrying both extranet and non-extranet traffic. In general, a 2170 given VRF would not originate both (a) an S-PMSI A-D route 2171 advertising a (C-*,C-*) selective P-tunnel for both extranet and 2172 non-extranet traffic and (b) an I-PMSI A-D route advertising an 2173 inclusive P-tunnel for both extranet and non-extranet traffic, as 2174 the inclusive P-tunnel would not get used in that case. 2176 7.2.3. Source Active A-D Routes 2178 7.2.3.1. When Inter-Site Shared Trees Are Used 2180 This section applies when Inter-Site Shared Trees are used, as 2181 specified in [RFC6514] Section 13. 2183 If VRF-S exports a Source Active A-D route that contains C-S in the 2184 Multicast Source field of its NLRI, and if that VRF also exports a 2185 UMH-eligible route matching C-S, the Source Active A-D route MUST 2186 carry at least one RT in common with the UMH-eligible route. The RT 2187 MUST be chosen such that the following condition holds: if VRF-R 2188 contains an extranet C-receiver allowed by policy to receive extranet 2189 traffic from C-S, then VRF-R imports both the UMH-eligible route and 2190 the Source Active A-D route. 2192 By default, a Source Active A-D route for a given (C-S,C-G), exported 2193 by a given VRF, carries the same set of RTs as the UMH-eligible route 2194 matching C-S that is exported from that VRF. 2196 7.2.3.2. When Inter-Site Shared Trees Are Not Used 2198 This section applies when Inter-Site Shared Trees are not used, as 2199 specified in [RFC6514] Section 14. 2201 Suppose a VRF, say VRF-X, contains the C-RP for a given extranet 2202 C-group, say C-G. If C-S is an active source for C-G, then following 2203 the procedures of Section 14.1 of [RFC6514], VRF-X may export a 2204 Source Active A-D route that contains C-S in the Multicast Source 2205 field of its NLRI. This document replaces the rule for constructing 2206 the RT(s) carried by such a route, specified in Section 14.1 of 2207 [RFC6514], with the following. VRF-X MUST be configured such that 2208 the Source Active A-D route for (C-S,C-G) carries the same set of RTs 2209 as the UMH-eligible route matching C-S that is exported from the 2210 VRF(s) containing C-S. This way, if a VRF, say VRF-R, contains an 2211 extranet C-receiver allowed by policy to receive extranet traffic 2212 from C-S, then VRF-R imports both the UMH-eligible route and the 2213 Source Active A-D route. 2215 7.3. Originating A-D Routes With Extranet Separation 2217 If a VRF contains both extranet C-sources and non-extranet C-sources, 2218 it MUST be configured with both a "default RD" and an "extranet RD" 2219 (see Section 1.3). The use of these RDs is explained in the 2220 following sub-sections. 2222 7.3.1. Intra-AS I-PMSI A-D Routes 2224 This section applies when VRF-S is using extranet separation, AND 2225 when VRF-S is using an inclusive P-tunnel to carry some or all of the 2226 extranet C-flows that it needs to transmit to other VRFs. 2228 If VRF-S contains both extranet C-sources and non-extranet C-sources, 2229 and if inclusive P-tunnels are used to carry both extranet C-flows 2230 and non-extranet C-flows, then there MUST be two inclusive tunnels 2231 from VRF-S, one of which is to be used only to carry extranet C-flows 2232 (the "extranet inclusive P-tunnel"), and one of which is to be used 2233 only to carry non-extranet C-flows (the "non-extranet inclusive 2234 P-tunnel"). 2236 In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes. 2237 Their respective NLRIs MUST of course have different RDs. One of the 2238 Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel 2239 in its PTA. This route MUST have the VRF's "extranet RD" in its 2240 NLRI. The other route identifies the non-extranet inclusive P-tunnel 2241 in its PTA. This route MUST have the VRF's "default RD" in its PTA. 2243 If VRF-S uses an inclusive P-tunnel for carrying extranet traffic, 2244 but does not use an inclusive P-tunnel for carrying non-extranet 2245 traffic, then of course only a single Intra-AS I-PMSI A-D route need 2246 be originated. The PTA of this route identifies the "extranet 2247 inclusive P-tunnel". The NLRI of that route MUST contain the VRF's 2248 extranet RD. 2250 An Intra-AS I-PMSI A-D route whose PTA identifies an extranet 2251 inclusive P-tunnel MUST carry the Extranet Separation Extended 2252 Community defined in Section 4.5. 2254 The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies 2255 the "extranet inclusive P-tunnel" MUST be chosen such that the 2256 following condition holds: if a VRF (call it VRF-R) imports a UMH- 2257 eligible route from VRF-S, and if that route matches an extranet 2258 C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route. 2260 Note that when extranet separation is used, it is possible to use an 2261 inclusive P-tunnel for non-extranet traffic while using only 2262 selective P-tunnels for extranet traffic. It is also possible to use 2263 an inclusive P-tunnel for extranet traffic while using only selective 2264 P-tunnels for non-extranet traffic. 2266 7.3.2. S-PMSI A-D Routes 2268 Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose 2269 that R-SP is used to bind some or all of the extranet C-flows from a 2270 given extranet C-source to a given selective P-tunnel. Let R-UMH be 2271 a UMH-eligible route that is exported from VRF-S and that matches the 2272 given extranet C-source. Then R-SP and R-UMH MUST have at least one 2273 RT in common. Further, the RTs carried by these two routes MUST be 2274 such that every VRF that imports R-UMH also imports R-SP. These 2275 rules apply whether or not R-SP uses wildcards [RFC6625]. 2277 The following rules, specific to the use of extranet separation, 2278 apply: 2280 o A selective P-tunnel MUST NOT carry C-flows from both extranet and 2281 non-extranet C-sources, 2283 o If it is desired to use a (C-*,C-*) S-PMSI to carry extranet 2284 traffic and also to use a (C-*,C-*) S-PMSI to carry non-extranet 2285 traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated. 2286 These two routes MUST have different RDs in their respective NLRI 2287 fields, and their respective PTAs MUST identify different 2288 P-tunnels. If the route advertises a P-tunnel that carries only 2289 non-extranet traffic, the route's NLRI MUST contain the VRF's 2290 default RD. If the route advertises a P-tunnel that carries only 2291 extranet traffic, the route's NLRI MUST contain the VRF's extranet 2292 RD. 2294 o In the following cases, an S-PMSI A-D route exported from the VRF 2295 MUST have the VRF's extranet RD in its NLRI: 2297 * The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D 2298 route, and C-S is an extranet C-source. 2300 * The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G 2301 is an extranet C-group. 2303 In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI 2304 A-D route MUST have the VRF's default RD in its NLRI. 2306 o A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used 2307 to carry extranet traffic MUST carry the Extranet Separation 2308 Extended Community defined in Section 4.5. 2310 An implementation MUST allow the set of RTs carried by the S-PMSI A-D 2311 routes to be specified by configuration. In the absence of such 2312 configuration, an S-PMSI A-D route originated by a given VRF X MUST 2313 carry a default set of RTs, as specified by the following rules: 2315 1. Rule 1 of Section 7.2.2 applies. 2317 2. By default, if C-G is an extranet C-group, rule 2 of 2318 Section 7.2.2 applies. 2320 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF X 2321 is to be used for extranet traffic, it carries the same RTs that 2322 would be carried (as specified in Section 7.3.1) by an I-PMSI A-D 2323 route originated by VRF X if that I-PMSI A-D route were 2324 advertising an inclusive P-tunnel for carrying extranet traffic. 2325 In general, a given VRF would not originate both an S-PMSI A-D 2326 route advertising a (C-*,C-*) selective P-tunnel for extranet 2327 traffic and an I-PMSI A-D route advertising an inclusive P-tunnel 2328 for extranet traffic, as the inclusive P-tunnel would not get 2329 used in that case. 2331 7.3.3. Source Active A-D Routes 2333 The procedures of Section 7.2.3 apply. 2335 However, if a Source Active A-D route is exported from a given VRF, 2336 and the route contains C-S, where C-S is an extranet C-source, then 2337 the RD of the route's NLRI MUST be the extranet RD of the VRF. 2338 Otherwise the RD is the default RD of the VRF. 2340 7.4. Determining the Expected P-tunnel for a C-flow 2342 This section applies whether extranet separation is used or not. 2344 In the context of a VRF with receivers for a particular C-flow, a PE 2345 must determine the P-tunnel over which packets of that C-flow are 2346 expected to arrive. This is done by finding an I-PMSI or S-PMSI A-D 2347 route that "matches" the flow. The matching A-D route will contain a 2348 PTA that specifies the P-tunnel being used to carry the traffic of 2349 that C-flow. We will refer to this P-tunnel as the "expected 2350 P-tunnel" for the C-flow. (Note that, per [MVPN-IR], if the PTA 2351 specifies an tunnel of type "Ingress Replication" (IR), the 2352 identifier of the P-tunnel is actually the NLRI of the I-PMSI or 2353 S-PMSI A-D route. If the PTA specifies a tunnel type other than IR, 2354 the identifier of the P-tunnel is found in the "tunnel identifier" 2355 field of the PTA.) 2357 A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST 2358 join the expected P-tunnel for that C-flow, and the PE MUST remain 2359 joined to the P-tunnel as long as the PE continues to need to receive 2360 the given C-flow, and the P-tunnel continues to remain the expected 2361 P-tunnel for that C-flow. Procedures for joining and leaving a 2362 tunnel depend, of course, on the tunnel type. 2364 If a PTA specifies a non-zero MPLS label for a tunnel that is not an 2365 IR tunnel, then the PE originating the A-D route containing that PTA 2366 is advertising an aggregate P-tunnel. The aggregate P-tunnel can be 2367 thought of as an outer P-tunnel multiplexing some number of inner 2368 P-tunnels. The inner P-tunnels are demultiplexed by means of the 2369 MPLS label in the PTA. In this document, when we talk of the 2370 "expected P-tunnel" in the context of an aggregate P-tunnel, we refer 2371 to a particular inner P-tunnel, not to the outer P-tunnel. It is 2372 this "inner P-tunnel" that is the expected P-tunnel for a given 2373 C-flow. 2375 In order to find the expected P-tunnel for a given C-flow, the 2376 upstream PE of the C-flow is first determined. Then the S-PMSI A-D 2377 routes originated by that PE are examined, and their NLRIs compared 2378 to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for 2379 reception". (If there is no S-PMSI A-D route that matches a given 2380 C-flow, the expected P-tunnel for that C-flow may have been 2381 advertised in an I-PMSI A-D route; see Section 7.4.5.) 2383 The rules for determining, in non-extranet cases, whether a given 2384 C-flow is a "match for reception" for a given S-PMSI A-D route are 2385 given in [RFC6625] Section 3.2. Note that we use the terms 2386 "installed" and "originated" as they are defined in [RFC6625] 2387 Section 3.2. (See also Section 1.1 of this document.) 2389 This specification adds additional rules for determining whether a 2390 given S-PMSI A-D route is a "match for reception" for a given (C-S/ 2391 C-RP,C-G). Note that these rules all assume the context of a 2392 particular VRF into which the A-D route has been imported. 2394 The rules given in [RFC6625] for determining whether a given S-PMSI 2395 A-D route is a "match for transmission" remain unchanged. 2397 Suppose a PE has originated a C-multicast Shared Tree Join for 2398 (C-*,C-G), has not originated a C-multicast Source Tree Join for 2399 (C-S,C-G), but has received and installed a Source Active A-D route 2400 for (C-S,C-G). As described in Section 13.2 of [RFC6514], the PE 2401 must receive the (C-S,C-G) traffic from the tunnel the originator of 2402 the installed Source Active A-D route uses for sending (C-S,C-G). 2404 The originator of the installed Source Active A-D route is determined 2405 as follows: 2407 1. Look at the "UMH Route Candidate Set" for C-S, as defined in 2408 [RFC6513] Section 5.1.3. 2410 2. From that set select a subset of UMH routes to C-S, such that 2411 each route in the subset has at least one RT in common with the 2412 Source Active A-D route, and at least one of the RTs in common is 2413 an import RT of the VRF. 2415 3. From that subset, find the route whose RD is the same as the RD 2416 from the NLRI of the Source Active A-D route. 2418 4. The Upstream PE is the PE identified in the VRF Route Import 2419 Extended Community of that route. 2421 5. The Upstream AS is the AS identified in the Source AS Extended 2422 Community of that route. 2424 If the result of step 2 is an empty set, or if step 3 fails to find a 2425 route, then the Upstream PE of the Source Active A-D route cannot be 2426 determined, and it is necessary to act as if the Source Active A-D 2427 route had not been installed. (A subsequent change to the UMH Route 2428 Candidate Set for C-S may require that a new attempt be made to 2429 determine the Upstream PE.) 2431 Once the upstream PE is determined, the P-tunnel over which the flow 2432 is expected is determined according to the procedures already 2433 described in this section. 2435 7.4.1. (C-S,C-G) S-PMSI A-D Routes 2437 When extranet functionality is being provided, an S-PMSI A-D route 2438 whose NLRI contains (C-S,C-G) is NOT considered to be a "match for 2439 reception" for a given C-flow (C-S,C-G) unless one of the following 2440 conditions holds (in addition to the conditions specified in 2441 [RFC6625]): 2443 o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is 2444 provisioned, or 2446 o the selected UMH route for C-S has at least one RT in common with 2447 the S-PMSI A-D route, and at least one of the common RTs is an 2448 import RT of the VRF. 2450 7.4.2. (C-S,C-*) S-PMSI A-D Routes 2452 When extranet functionality is being provided, an S-PMSI A-D route 2453 whose NLRI contains (C-S,C-*) is NOT considered to be a "match for 2454 reception" for a given C-flow (C-S,C-G) unless one of the following 2455 conditions holds, in addition to the conditions specified in 2456 [RFC6625]: 2458 o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is 2459 provisioned, or 2461 o the selected UMH route for C-S has at least one RT in common with 2462 the S-PMSI A-D route, and at least one of the common RTs is an 2463 import RT of the VRF. 2465 7.4.3. (C-*,C-G) S-PMSI A-D Routes 2467 When extranet functionality is being provided, an S-PMSI A-D route 2468 whose NLRI contains (C-*,C-G) is NOT considered to be a "match for 2469 reception" for a given C-flow (C-S,C-G) in a given VRF unless either 2470 condition 1 or condition 2 below holds, in addition to the conditions 2471 specified in [RFC6625]: 2473 1. The given VRF has currently originated a C-multicast Shared Tree 2474 Join route for (C-*,C-G), and 2476 a. (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route 2477 (according to [RFC6625]) in the given VRF, and 2479 b. either 2481 i. the "Single C-group per (C-*,C-G) P-tunnel" policy has 2482 been provisioned, or 2484 ii. the RTs of that S-PMSI A-D route form a non-empty 2485 intersection with the RTs carried in the VRF's 2486 selected UMH route for C-RP of that C-G, or 2488 iii. installed in the VRF is at least one (C-S,C-G) Source 2489 Active A-D route that was originated by the same PE as 2490 the (C-*,C-G) S-PMSI A-D route. 2492 2. The given VRF does not have a currently originated C-multicast 2493 Shared Tree Join for (C-*,C-G), but 2495 a. there are one or more values for C-S for which the VRF has a 2496 currently originated Source Tree Join C-multicast route for 2497 (C-S,C-G), and 2499 b. the (C-* C-G) S-PMSI A-D route matches (according to 2500 [RFC6625]) each such (C-S,C-G), and 2502 c. either 2504 i. the "Single C-group per (C-*,C-G) P-tunnel" policy has 2505 been provisioned, or 2507 ii. the RTs of that S-PMSI A-D route form a non-empty 2508 intersection with the RTs carried in the VRF's selected 2509 UMH routes for each such C-S 2511 If a VRF has an installed (C-*,C-G) S-PMSI A-D route, but does 2512 not have a (C-S,C-G) or (C-*,C-G) multicast state that matches 2513 that route for reception, the procedures of Section 12.3 2514 ("Receiving S-PMSI A-D Routes by PEs") of [RFC6514] are not 2515 invoked for that route. If those multicast states are created at 2516 some later time when the route is still installed, the procedures 2517 of Section 12.3 of [RFC6514] are invoked at that time. 2519 7.4.4. (C-*,C-*) S-PMSI A-D Routes 2521 A (C-*,C-*) S-PMSI A-D Route (call it "R-AD") is NOT considered to be 2522 a match for reception for a given C-flow (C-S,C-G) or (C-*,C-G) 2523 unless the following conditions hold (in addition to the conditions 2524 specified in [RFC6625]: 2526 o the selected UMH route (call it "R-UMH") for C-S or for C-G's C-RP 2527 respectively has at least one RT in common with R-AD, and at least 2528 one of the common RTs is an import RT of the VRF. 2530 o either R-AD and R-UMH both carry the Extranet Separation Extended 2531 Community, or neither carries the Extranet Separation Extended 2532 Community. 2534 7.4.5. I-PMSI A-D Routes 2536 If a particular egress VRF in a particular egress PE contains no 2537 matching S-PMSI A-D routes for a particulalr C-flow, then the C-flow 2538 is expected to arrive (at that egress VRF) on an inclusive P-tunnel. 2540 Suppose that an egress PE has originated a (C-S,C-G) C-Multicast 2541 Source Tree Join. Let R-UMH be the selected UMH route (in the given 2542 egress VRF) or C-S. As specified in [RFC6514], the selected upstream 2543 PE for (C-S,C-G) is determined from the VRF Route Import Extended 2544 Community of R-UMH, and the "selected upstream AS" for the flow is 2545 determined from the Source AS Extended Community of R-UMH. 2547 Suppose that an egress PE has originated a (C-*,C-G) C-Multicast 2548 Shared Tree Join, but has not originated a (C-S,C-G) C-Multicast 2549 Source Tree Join. If the egress VRF does not have a (C-S,C-G) Source 2550 Active A-D route installed, the selected upstream PE is determined 2551 from the VRF Route Import Extended Community of the installed UMH- 2552 eligible route matching C-RP, where C-RP is the RP for the group C-G. 2553 The selected upstream AS for the flow is determined from the Source 2554 AS Extended Community of that route. If the egress VRF does have a 2555 (C-S,C-G) Source Active A-D route installed, the selected upstream PE 2556 and upstream AS are determined as specified in Section 7.4. In 2557 either case, let R-UMH be the installed UMH-eligible route matching 2558 C-S. 2560 The inclusive P-tunnel that is expected to be carrying a particular 2561 C-flow is found as follows: 2563 o If the selected upstream AS is the local AS, or if segmented 2564 Inter-AS P-tunnels are not being used to instantiate I-PMSIs, then 2565 look in the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, 2566 such that (a) R-AD originated by the selected upstream PE, (b) 2567 R-AD has at least one an RT in common with R-UMH, (c) at least one 2568 of the common RTs is an import RT of the local VRF, and (d) either 2569 R-AD and R-UMH both carry the Extranet Separation Extended 2570 Community, or neither carries the Extranet Separation Extended 2571 Community. 2573 The PTA of R-AD specifies the P-tunnel over which traffic of the 2574 given C-flow is expected. 2576 o If the selected upstream AS is not the local AS, and if segmented 2577 Inter-AS P-tunnels are being used to instantiate I-PMSIs, then 2578 look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD, 2579 such that (a) the Source AS field of R-AD's NLRI contains the AS 2580 number of the selected upstream AS, (b) R-AD has at least one RT 2581 in common with R-UMH, (c) at least one of the common RTs is an 2582 import RT of the local VRF, and (d) either R-AD and R-UMH both 2583 carry the Extranet Separation Extended Community, or neither 2584 carries the Extranet Separation Extended Community. 2586 The PTA of R-AD specifies the P-tunnel over which traffic of the 2587 given C-flow is expected. 2589 7.5. Packets Arriving from the Wrong P-tunnel 2591 Any packets that arrive on a P-tunnel other than the expected 2592 P-tunnel (as defined in Section 7.4) MUST be discarded, unless it is 2593 know that all the packets carried by both P-tunnels are from the same 2594 ingress VRF. (See Section 2.3.1 for a more detailed discussion of 2595 when to discard packets from other than the expected P-tunnel.) Note 2596 that packets arriving on the wrong P-tunnel are to be discarded even 2597 if they are arriving from the expected PE. 2599 8. Multiple Extranet VRFs on the same PE 2601 When multiple VRFs that contain extranet receivers for a given 2602 extranet source are present on the same PE, this PE becomes a single 2603 leaf of the P-tunnel used for sending (multicast) traffic from that 2604 source to these extranet receivers. The PE MUST be able to replicate 2605 this traffic to the multiple VRFs. Specific procedures for doing so 2606 are local to the PE, and outside the scope of this document. 2608 Two or more VRFs on the same PE may import the same S-PMSI A-D route. 2609 If this S-PMSI A-D route contains a PTA that has its "Leaf Info 2610 Required" bit set, it may be necessary for the PE to originate a Leaf 2611 A-D route whose NLRI is computed from the NLRI of the S-PMSI A-D 2612 route. (Details are in [RFC6514].) Note that for a given S-PMSI A-D 2613 route, the PE can originate only one corresponding Leaf A-D route, 2614 even if the S-PMSI A-D route is imported into multiple VRFs. This 2615 Leaf A-D route can thus be thought of as originating from several 2616 VRFs. It MUST NOT be withdrawn by the PE until there are no longer 2617 any VRFs originating it. 2619 [RFC6514] specifies conditions under which a PE originates a 2620 C-Multicast Source Tree Join or a C-Multicast Shared Tree Join, based 2621 on the (*,G) and (S,G) states associated with a given VRF. It also 2622 specifies the procedure for computing the NLRI of each such route. 2623 While a given PE may contain two or more VRFs that have (extranet) 2624 receivers for the same extranet C-flow, the PE cannot originate more 2625 than one BGP route with a given NLRI. If there are multiple VRFs, 2626 each of which has state that is sufficient to cause a given 2627 C-multicast route to be originated, the route can be thought of as 2628 originating from several VRFs. It MUST NOT be withdrawn by the PE 2629 until there is no longer any VRF with multicast state sufficient to 2630 cause the route to be originated. 2632 For a given extranet the site(s) that contain the extranet source(s) 2633 and the site(s) that contain the extranet receiver(s) may be 2634 connected to the same PE. In this scenario, the procedures by which 2635 (multicast) traffic from these sources is delivered to these 2636 receivers is a local matter to the PE, and outside the scope of this 2637 document. 2639 An implementation MUST support multiple extranet VRFs on a PE. 2641 9. IANA Considerations 2643 IANA is requested to allocate two new codepoints from the "First 2644 Come, First Served" range of the "Transitive Opaque Extended 2645 Community Sub-Types" Registry (under the top-level registry: "Border 2646 Gateway Protocol (BGP) Extended Communities"). [TO BE REMOVED: This 2647 registration should take place at the following location: 2648 http://www.iana.org/assignments/bgp-extended-communities/bgp- 2649 extended-communities.xhtml#trans-opaque] 2651 o A codepoint for "Extranet Source Extended Community" 2653 o A codepoint for "Extranet Separation Extended Community" 2655 10. Security Considerations 2657 The security considerations of [RFC6513] and [RFC6514] are 2658 applicable. 2660 As is the case with any application of technology based upon 2661 [RFC4364], misconfiguration of the RTs may result in VPN security 2662 violations (i.e., may result in a packet being delivered to a VPN 2663 where, according to policy, it is not supposed to go). 2665 In those cases where the set of extranet sources of a particular VRF 2666 is manually configured, improper configuration of the VRF can result 2667 in VPN security violations -- traffic from a host that is not an 2668 extranet source may be treated as if it were traffic from an extranet 2669 source. 2671 Section 4.4 specifies the optional use of a new Extended Community, 2672 the Extranet Source Extended Community. Security considerations 2673 regarding the use and distribution of that Extended Community are 2674 discussed in that section. 2676 The procedures of this document do not provide encryption of the data 2677 flows that are sent across the SP backbone network. Hence these 2678 procedures do not by themselves ensure the privacy or integrity of 2679 the data against attacks on the backbone network. 2681 In general, different VPNs are allowed to have overlapping IP address 2682 spaces, i.e., a host in one VPN may have the same IP address as a 2683 host in another. This is safe because the customer routes from a 2684 given VPN do not pass into other VPNs. Even if there is overlapping 2685 address space among VPNs, the routes that are known at any given VPN 2686 site are unambiguous, as long as the address space of that VPN is 2687 unambiguous. However, this is not necessarily true when extranet 2688 service is provided. If an extranet C-receiver in VPN-R is to be 2689 able to receive multicast traffic from an extranet C-source in VPN-S, 2690 then the address of the VPN-S extranet C-source must be imported into 2691 one or more VPN-R VRFs. If that address is also the address of a 2692 VPN-R non-extranet C-source, then a system attempting to receive an 2693 extranet C-flow from the VPN-R extranet C-source may instead receive 2694 a non-extranet C-flow from the VPN-S C-source. Otherwise a a VPN 2695 security violation may result. 2697 That is, when provisioning an extranet between two VPNs that have 2698 overlapping address spaces, one must ensure that the IP addresses of 2699 the extranet sources and the extranet receivers are not from the 2700 overlapping part of the address space. This document specifies that 2701 if a route is imported into a given VRF, all addresses that match 2702 that route must be unambiguous in the context of that VRF. Improper 2703 provisioning of the extranet source addresses, or improper 2704 provisioning of the RTs, may cause this rule to be violated, and may 2705 result in a VPN security violation. 2707 It is possible that a given multicast C-source is the source of 2708 multiple flows, some of which are intended to be extranet C-flows, 2709 and some of which are intended to be non-extranet flows. However, 2710 the procedures of this document will allow any C-receiver that is 2711 able to receive the extranet C-flows from a given C-source to also 2712 receive the non-extranet C-flows from that source. As a result, VPN 2713 security violations may result if any system is a C-source for both 2714 extranet and non-extranet C-flows. However, the set of C-flows 2715 transmitted by a given C-source is not under the control of the SP. 2716 SPs who offer the extranet MVPN service must make sure that this 2717 potential for VPN security violations is clearly understood by the 2718 customers who administer the C-sources. 2720 This specification does not require that UMH-eligible routes be "host 2721 routes"; they may be less specific routes. So it is possible for the 2722 NLRI of a UMH-eligible route to contain an address prefix that 2723 matches the address of both an extranet C-source and a non-extranet 2724 C-source. If such a route is exported from a VPN-S VRF and imported 2725 by a VPN-R VRF, C-receivers contained in VPN-R will be able to 2726 receive C-flows from the non-extranet C-sources whose addresses match 2727 that route. This may result in VPN security violations. Service 2728 providers who offer the extranet MVPN service must make sure that 2729 this is clearly understood by the customers who administer the 2730 distribution of routes from CE to PE routers. 2732 If the address ambiguities described in Sections 2.1 and 2.2 are not 2733 prohibited by deployment of the policies described in Section 2.3.2, 2734 VRFs must be able to discard traffic that arrives on the wrong 2735 P-tunnel (as specified in Section 2.3.1 and Section 7.5). Otherwise 2736 VPN security violations may occur. 2738 11. Acknowledgments 2740 The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini 2741 Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt 2742 Windisch for their contributions to this work. 2744 We also wish to thank Lizhong Jin and Rishabh Parekh for their 2745 reviews and comments. 2747 Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and 2748 for providing the ascii art appearing in Section 2. 2750 12. Contributor Addresses 2752 Below is a list of other contributing authors in alphabetical order: 2754 Wim Henderickx 2755 Nokia 2756 Copernicuslaan 50 2757 Antwerp 2018 2758 Belgium 2760 Email: wim.henderickx@nokia.com 2762 Praveen Muley 2763 Nokia 2765 Email: Praveen.Muley@nokia.com 2767 Ray Qiu 2768 Juniper Networks, Inc. 2769 1194 North Mathilda Avenue 2770 Sunnyvale, CA 94089 2771 United States 2773 Email: rqiu@juniper.net 2775 IJsbrand Wijnands 2776 Cisco Systems, Inc. 2777 De Kleetlaan 6a 2778 Diegem 1831 2779 Belgium 2781 Email: ice@cisco.com 2783 13. References 2785 13.1. Normative References 2787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2788 Requirement Levels", BCP 14, RFC 2119, 2789 DOI 10.17487/RFC2119, March 1997, 2790 . 2792 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 2793 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 2794 February 2006, . 2796 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2797 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2798 2006, . 2800 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 2801 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2802 2012, . 2804 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 2805 Encodings and Procedures for Multicast in MPLS/BGP IP 2806 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 2807 . 2809 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 2810 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 2811 RFC 6625, DOI 10.17487/RFC6625, May 2012, 2812 . 2814 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 2815 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 2816 March 2014, . 2818 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 2819 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 2820 Multicast - Sparse Mode (PIM-SM): Protocol Specification 2821 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2822 2016, . 2824 13.2. Informative References 2826 [MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress 2827 Replication Tunnels in Multicast VPN", internet-draft 2828 draft-ietf-bess-ir-03, April 2016. 2830 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 2831 Rendevous Point (RP) mechanism using Protocol Independent 2832 Multicast (PIM) and Multicast Source Discovery Protocol 2833 (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003, 2834 . 2836 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 2837 Discovery Protocol (MSDP)", RFC 3618, 2838 DOI 10.17487/RFC3618, October 2003, 2839 . 2841 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 2842 Independent Multicast (PIM)", RFC 4610, 2843 DOI 10.17487/RFC4610, August 2006, 2844 . 2846 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 2847 Yasukawa, Ed., "Extensions to Resource Reservation 2848 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 2849 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 2850 DOI 10.17487/RFC4875, May 2007, 2851 . 2853 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 2854 "Bidirectional Protocol Independent Multicast (BIDIR- 2855 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 2856 . 2858 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 2859 "Bootstrap Router (BSR) Mechanism for Protocol Independent 2860 Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 2861 2008, . 2863 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 2864 Thomas, "Label Distribution Protocol Extensions for Point- 2865 to-Multipoint and Multipoint-to-Multipoint Label Switched 2866 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 2867 . 2869 Authors' Addresses 2871 Yakov Rekhter (editor) 2872 Juniper Networks, Inc. 2873 1194 North Mathilda Avenue 2874 Sunnyvale, CA 94089 2875 United States 2877 Eric C. Rosen (editor) 2878 Juniper Networks, Inc. 2879 10 Technology Park Drive 2880 Westford, Massachusetts 01886 2881 United States 2883 Email: erosen@juniper.net 2885 Rahul Aggarwal 2886 Arktan 2888 Email: raggarwa_1@yahoo.com 2889 Yiqun Cai 2890 Microsoft 2891 1065 La Avenida 2892 Mountain View, CA 94043 2893 United States 2895 Email: yiqunc@microsoft.com 2897 Thomas Morin 2898 Orange 2899 2 Avenue Pierre-Marzin 2900 22307 Lannion Cedex 2901 France 2903 Email: thomas.morin@orange.com