idnits 2.17.1 draft-ietf-bess-mvpn-extranet-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6625, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC6513, updated by this document, for RFC5378 checks: 2005-06-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 7, 2015) is 3270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-05) exists of draft-ietf-bess-ir-01 Summary: 1 error (**), 0 flaws (~~), 3 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: November 8, 2015 Arktan 7 Y. Cai 8 Microsoft 9 T. Morin 10 Orange 11 May 7, 2015 13 Extranet Multicast in BGP/IP MPLS VPNs 14 draft-ietf-bess-mvpn-extranet-02 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 November 8, 2015. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.2.1. Customer Multicast Control 65 Protocols . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 71 2. Extranets and Overlapping Address 72 Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.1. Ambiguity: P-tunnel with 74 Extranet/Non-Extranet Flows . . . . . . . . . . . . . . . 12 75 2.2. Ambiguity: P-tunnel with Multiple 76 Extranet Flows . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . 18 81 3. Extranet Transmission Models . . . . . . . . . . . . . . . . 20 82 3.1. Transmitting an Extranet C-flow on a Single PMSI . . . . 20 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 . . . 21 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 . . . . . . . . . . . . . . . . . 23 92 4.3. Route Targets and Ambiguous 93 UMH-Eligible Routes . . . . . . . . . . . . . . . . . . . 24 94 4.4. Dynamically Marking Extranet 95 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 4.4.1. The Extranet Source Extended 97 Community . . . . . . . . . . . . . . . . . . . . . . 25 98 4.4.2. Distribution of Extranet Source Extended 99 Community . . . . . . . . . . . . . . . . . . . . . . 27 100 4.5. The 'Extranet Separation' Extended Community . . . . . . 27 101 5. Origination and Distribution of BGP A-D Routes . . . . . . . 28 102 5.1. Route Targets of UMH-eligible Routes and A-D 103 Routes . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 5.2. Considerations for Particular Inclusive Tunnel 105 Types . . . . . . . . . . . . . . . . . . . . . . . . . . 30 106 5.2.1. RSVP-TE P2MP or Ingress 107 Replication . . . . . . . . . . . . . . . . . . . . . 30 108 5.2.2. Ingress Replication . . . . . . . . . . . . . . . . . 31 109 6. When PIM is the PE-PE C-multicast Control Plane . . . . . . . 32 110 6.1. Provisioning VRFs with RTs . . . . . . . . . . . . . . . 33 111 6.1.1. Incoming and Outgoing Extranet RTs . . . . . . . . . 33 112 6.1.2. UMH-eligible Routes and RTs . . . . . . . . . . . . . 34 113 6.1.3. PIM C-Instance Reverse Path Forwarding 114 Determination . . . . . . . . . . . . . . . . . . . . 34 115 6.2. Single PMSI per C-flow Model . . . . . . . . . . . . . . 35 116 6.2.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 35 117 6.2.2. S-PMSIs . . . . . . . . . . . . . . . . . . . . . . . 38 118 6.2.3. Sending PIM Control Packets . . . . . . . . . . . . . 39 119 6.2.4. Receiving PIM Control Packets . . . . . . . . . . . . 39 120 6.2.5. Sending and Receiving Data Packets . . . . . . . . . 40 121 6.3. Multiple PMSIs per C-flow Model . . . . . . . . . . . . . 40 122 6.3.1. Forming the MI-PMSIs . . . . . . . . . . . . . . . . 41 123 7. When BGP is the PE-PE C-multicast Control Plane . . . . . . . 42 124 7.1. Originating C-multicast Routes . . . . . . . . . . . . . 43 125 7.2. Originating A-D Routes Without Extranet 126 Separation . . . . . . . . . . . . . . . . . . . . . . . 43 127 7.2.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 43 128 7.2.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 44 129 7.2.3. Source Active A-D Routes . . . . . . . . . . . . . . 45 130 7.2.3.1. When Inter-Site Shared Trees Are Used . . . . . . 45 131 7.2.3.2. When Inter-Site Shared Trees Are Not Used . . . . 45 132 7.3. Originating A-D Routes With Extranet Separation . . . . . 46 133 7.3.1. Intra-AS I-PMSI A-D Routes . . . . . . . . . . . . . 46 134 7.3.2. S-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 47 135 7.3.3. Source Active A-D Routes . . . . . . . . . . . . . . 48 136 7.4. Determining the Expected P-tunnel for a C-flow . . . . . 48 137 7.4.1. (C-S,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 50 138 7.4.2. (C-S,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 51 139 7.4.3. (C-*,C-G) S-PMSI A-D Routes . . . . . . . . . . . . . 51 140 7.4.4. (C-*,C-*) S-PMSI A-D Routes . . . . . . . . . . . . . 52 141 7.4.5. I-PMSI A-D Routes . . . . . . . . . . . . . . . . . . 52 142 7.5. Packets Arriving from the Wrong P-tunnel . . . . . . . . 53 143 8. Multiple Extranet VRFs on the same 144 PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 146 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 147 10. Security Considerations . . . . . . . . . . . . . . . . . . . 55 148 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 149 12. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 56 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 151 13.1. Normative References . . . . . . . . . . . . . . . . . . 57 152 13.2. Informative References . . . . . . . . . . . . . . . . . 58 153 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 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 an S-PMSI A-D route being "installed". That is, we say that an 185 S-PMSI A-D route is "installed" (in a given VRF) if it has been 186 selected by the BGP decision process as the preferred route for its 187 NLRI. We also follow the terminology of Section 3.2 of [RFC6625] 188 when saying that an S-PMSI A-D route has been "originated by a given 189 PE"; this means that the given PE's IP address is contained in the 190 "Originating Router's IP Address" field in the NLRI of the route. 192 We use the following additional terminology and notation: 194 o Extranet C-source: a multicast source, in a given VPN, that is 195 allowed by policy to send multicast traffic to receivers that are 196 in other VPNs. 198 o Extranet C-receiver: a multicast receiver, in a given VPN, that is 199 allowed by policy to receive multicast traffic from extranet 200 C-sources that are in other VPNs. 202 o Extranet C-flow: a multicast flow (with a specified C-source 203 address and C-group address) whose source is an extranet C-source, 204 and which is allowed by policy to have extranet C-receivers. 206 o Extranet C-group: a multicast group address that is in the "Any 207 Source Multicast" (ASM) group address range, and that is allowed 208 by policy to have Extranet C-sources and Extranet C-receivers that 209 are not all in the same VPN. Note that we will sometimes refer to 210 "SSM C-group addresses" (i.e., to C-group addresses in the SSM 211 group address range), but will never call them "extranet 212 C-groups". 214 N.B.: Any source of traffic for an extranet C-group is considered 215 to be an extranet C-source, and any receiver of traffic addressed 216 to an extranet C-group is considered to be an extranet C-receiver. 218 o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet 219 C-group; it is allowed by policy to receive PIM register messages 220 [RFC4601] from outside its VPN, and to send multicast data packets 221 to extranet C-receivers outside its VPN. 223 o Host(C-S,A): the host (or if C-S is an "anycast address", the set 224 of hosts) denoted by the address C-S in the context of VPN-A. For 225 example, if a particular C-source in VPN A has address C-S, then 226 Host(C-S,A) refers to that C-source. 228 o SAFI-n route: a BGP route whose Address Family Identifier (AFI) is 229 either 1 (IPv4) or 2 (IPv6), and whose Subsequent Address Family 230 Identifier (SAFI) is "n". 232 Note that a given extranet C-source is not necessarily allowed to 233 transmit to every extranet C-receiver; policy determines which 234 extranet C-sources are allowed to transmit to which extranet 235 C-receivers. However, in the case of an extranet (ASM) C-group, all 236 transmitters to the group are allowed to transmit to all the 237 receivers of the group, and all the receivers of the group are 238 allowed to receive from all transmitters to the group. 240 We say that a given VRF "contains" or "has" a multicast C-source (or 241 that the C-source is "in" the VRF), if that C-source is in a site 242 connected to that VRF, and the VRF originates a UMH-eligible route 243 (see Section 4) that matches the address of the C-source. 245 We say that a given VRF "contains" or "has" a multicast C-receiver 246 (or that the C-receiver is "in" the VRF), if that C-receiver is in a 247 site connected to that VRF. 249 We say that a given VRF "contains" or "has" the C-RP for a given ASM 250 group (or that the C-RP is "in" the VRF) if that C-RP is in a site 251 connected to that VRF, and the VRF originates a unicast route and a 252 (possibly different, possibly the same) UMH-eligible route (see 253 Section 4) whose respective address prefixes match the C-RP address. 255 [RFC6513] allows a set of "Provider tunnels" (P-tunnels) to be 256 aggregated together and transported via an outer P-tunnel, i.e., it 257 allows for the use of hierarchical Label Switched Paths (LSPs) as 258 P-tunnels. A two-level hierarchical LSP, for example, can be thought 259 of as a set of "inner tunnels" aggregated into an outer tunnel. In 260 this document, when we speak of a P-tunnel, we are always speaking of 261 the innermost P-tunnel, i.e., of a P-tunnel at the lowest level of 262 hierarchy. P-tunnels are identified in the Provider Multicast 263 Service Interface (PMSI) Tunnel Attributes (PTAs) [RFC6514] of BGP 264 Auto-Discovery (A-D) routes. Two PTAs that have the same Tunnel Type 265 and Tunnel Identifier fields, but different MPLS label fields, are 266 thus considered to identify two different P-tunnels. (I.e., for the 267 purposes of this document, the MPLS label included in the PTA, if 268 any, is considered to be part of the tunnel identifier.) 270 We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D 271 route contains (C-S,C-G) if its "Multicast Source" field contains C-S 272 and its "Multicast Group" field contains C-G. If either or both of 273 these fields is encoded as a wildcard, we will say that the NLRI 274 contains (C-*,C-*) (both fields encoded as wildcard), or (C-*,C-G) 275 (multicast source field encoded as wildcard) or (C-S,C-*) (multicast 276 group field encoded as wildcard). 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 280 "OPTIONAL", when and only when appearing in all capital letters, are 281 to be interpreted as described in [RFC2119]. 283 1.2. Scope 285 1.2.1. Customer Multicast Control Protocols 287 This document presumes that the VPN customer is using "PIM Sparse 288 Mode", operating in either "Source-Specific Mode" (SSM) or "Any 289 Source Mode" (ASM), as the multicast control protocol at the customer 290 sites. Support for other customer IP multicast control protocols 291 (e.g., [RFC5015], PIM "Dense Mode") is outside the scope of this 292 document. Support for the customer use of MPLS multicast control 293 protocols (e.g., [RFC6388], [RFC4875]) is also outside the scope of 294 this document. 296 When a VPN customer uses ASM, the customer routers need to be able to 297 map from a C-group address to a C-RP address. These mappings can be 298 provisioned in each router, or can be discovered dynamically through 299 protocols such as BSR [RFC5059]. However, it cannot be assumed that 300 such protocols will automatically work in the context of an extranet. 301 Discussion of the use of such protocols in an extranet is outside the 302 scope of this document. 304 1.2.2. Provider Multicast Control Protocols 306 [RFC6513] allows either PIM or BGP to be used as the protocol for 307 distributing customer multicast routing information. Except where 308 otherwise specified, such as in Sections 6 and 7, the procedures of 309 this document cover both cases. 311 1.3. Clarification on Use of Route Distinguishers 313 [RFC4364] requires that every VRF be associated with one or more 314 Route Distinguishers (RD). Each VPN-IPv4 or VPN-IPv6 route that is 315 exported from a particular VRF contains, in its NLRI, an RD that is 316 associated with that VRF. 318 [RFC4364] allows a given RD to be associated with more than one VRF, 319 as long as all the VRFs associated with that RD belong to the same 320 VPN. However, in the most common deployment model, each RD is 321 associated with one and only one VRF. [RFC6513] and [RFC6514] 322 presuppose this deployment model. That is, [RFC6513] and [RFC6514] 323 presuppose that every RD is associated with one and only one VRF. We 324 will call this the "unique VRF per RD" condition. 326 [RFC6514] defines the MCAST-VPN address family, which has a number of 327 route types. Each Intra-AS I-PMSI A-D route, S-PMSI A-D route, and 328 Source Active A-D route, when exported from a given VRF, contains, in 329 its NLRI, an RD that is associated with the VRF. [RFC6513] and 330 [RFC6514] also discuss a class of routes known as "UMH-eligible" 331 routes; when a UMH-eligible route is exported from a given VRF, its 332 NLRI contains an RD of the VRF. 334 [RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an 335 RD of the VRF from which they are exported: the C-multicast Join 336 routes and the Leaf A-D routes. 338 Those route types that, when exported from a given VRF, contain (in 339 their NLRIs) an RD of the VRF, will be known in this document as 340 "local-RD routes". 342 Given the "unique VRF per RD condition", if one sees that two local- 343 RD routes have the same RD, one can infer that the two routes 344 originated from the same VRF. This inference can be drawn even if 345 the two routes do not have the same SAFI, as long as the two routes 346 are both local-RD routes. 348 This document builds upon [RFC6513] and [RFC6514], and therefore 349 REQUIREs the "unique VRF per RD" condition. 351 [RFC6514] presupposes a further requirement on the use of RDs in the 352 local-RD routes exported from a given VRF. Suppose a given VRF 353 exports a Source Active A-D route containing (C-S,C-G). That VRF 354 will also export a UMH-eligible route matching C-S. [RFC6514] 355 presupposes that the UMH-eligible route and the Source Active A-D 356 route have the same RD. 358 In most cases, not only is a given RD associated with a single VRF, 359 but a given VRF is associated with a single RD. We will call this 360 the "unique RD per VRF" condition. When this condition holds, all 361 the local-RD routes exported from a given VRF will have the same RD. 362 This ensures that the presupposition of the previous paragraph will 363 hold, i.e., that the RD in a Source Active A-D route exported from a 364 given VRF will have the same RD as the corresponding UMH-eligible 365 route exported from the same VRF. 367 Section 7.3 of this document describes a procedure known as "Extranet 368 Separation". When Extranet Separation is NOT being used, this 369 document REQUIREs that the "unique RD per VRF" condition hold. This 370 ensures that all the local-RD routes exported from a given VRF will 371 have the same RD. 373 When Extranet Separation is used, a VRF that contains both extranet 374 sources and non-extranet sources MUST be configured with two RDs: the 375 "default RD" (discussed above) and the "extranet RD". The "unique 376 VRF per RD" condition also applies to the "extranet RD", i.e., a 377 given extranet RD is associated with a unique VRF. Details 378 concerning the exported routes that contain the extranet RD can be 379 found in Sections 4.1 and 7.3. 381 1.4. Overview 383 Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN 384 functionality as specified in [RFC6513] and/or [RFC6514]. In the 385 simplest configuration, VPN-S is a collection of VRFs, each of which 386 is configured with a particular Route Target (RT) value (call it "RT- 387 S") as its import RT and as its export RT. Similarly, VPN-R is a 388 collection of VRFs, each of which is configured with a particular RT 389 value (call it "RT-R") as its import RT and as its export RT. 391 In this configuration, multicast C-receivers contained in a VPN-R VRF 392 cannot receive multicast data traffic from multicast C-sources 393 contained in a VPN-S VRF. If it is desired to allow this, one needs 394 to create an MVPN "extranet". Creating an extranet requires 395 procedures in addition to those specified in [RFC6513], [RFC6514], 396 and [RFC6625]; this document specifies these additional procedures. 398 In the example above, the additional procedures will allow a selected 399 set of routes exported from the VPN-S VRFs (i.e., from the VRFs 400 containing extranet C-sources) to be imported into the VPN-R VRFs 401 (i.e., into the VRFs containing extranet C-receivers). These routes 402 include the routes that are to be eligible for use as UMH routes (see 403 Section 5.1 of [RFC6513]) in the extranet, as well as a selected set 404 of BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, 405 Source Active A-D routes). Importing these routes into the VPN-R 406 VRFs makes it possible to determine, in the context of a VPN-R VRF, 407 that a particular C-multicast Join needs to be delivered to a 408 particular VPN-S VRF. It also makes it possible to determine, in the 409 context of a VPN-R VRF, the P-tunnel through which the aforementioned 410 VPN-S VRF sends a particular C-flow. 412 Depending on the type of P-tunnel used, it may also be necessary for 413 Leaf A-D routes to be exported by one or more VPN-R VRFs and imported 414 into a VPN-S VRF. 416 There are no extranet-specific procedures governing the use and 417 distribution of BGP C-Multicast routes. 419 If PIM is used as the PE-PE protocol for distributing C-multicast 420 routing information, additional BGP A-D routes must be exported from 421 the VPN-R VRFs and imported into the VPN-S VRFS, so that the VPN-S 422 VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM 423 control messages. Details can be found in Section 6. 425 The simple example above describes an extranet created from two 426 MVPNs, one of which contains extranet C-sources and one of which 427 contains extranet C-receivers. However, the procedures described in 428 this document allow for much more complicated scenarios. 430 For instance, an extranet may contain extranet C-sources and/or 431 extranet C-receivers from an arbitrary number of VPNs, not just from 432 two VPNs. An extranet C-receiver in VPN-R may be allowed to receive 433 multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C. 435 Similarly, extranet C-sources in VPN-S may be allowed to send 436 multicast traffic to multicast C-receivers that are in VPN-A, VPN-B, 437 VPN-C, etc. 439 A given VPN customer may desire that only some of its multicast 440 C-sources be treated as extranet C-sources. This can be accomplished 441 by appropriate provisioning of the import and export RTs of that 442 customer's VRFs (as well as the VRFs of other VPNs that contain 443 extranet C-receivers for extranet C-flows of the given customer.) 445 A given VPN customer may desire that some of its extranet C-sources 446 can transmit only to a certain set of VPNs, while other of its 447 extranet C-sources can transmit only to a different set of VPNs. 448 This can be accomplished by provisioning the VRFs to export different 449 routes with different RTs. 451 In all these cases, the VPN customers set the policies, and the 452 Service Provider (SP) implements the policies by the way it 453 provisions the import and export RTs of the VRFs. It is assumed that 454 the customer communicates to the SP the set of extranet C-source 455 addresses, and the set of VPNs to which each C-source can transmit. 456 (Recall that every C-source that can transmit to an extranet C-group 457 is an extranet C-source, and must be able transmit to any VPN that 458 has receivers for that group. This must be taken into account when 459 the provisioning is done.) This customer/SP communication is part of 460 the service provisioning process, and outside the scope of this 461 document. 463 It is possible that an extranet C-source will transmit both extranet 464 C-flows and non-extranet C-flows. However, if extranet C-receiver 465 C-R can receive extranet C-flows from extranet C-source C-S, the 466 procedures of this document do not prevent C-R from requesting and 467 receiving the non-extranet flows that are transmitted by C-S. 468 Therefore it is NOT RECOMMENDED to allow an extranet C-source to 469 transmit non-extranet C-flows. However, the Service Provider (SP) 470 has no control over the set of C-flows transmitted by a given 471 C-source, and can do no more than communicate this recommendation to 472 its customers. (Alternatively, the customer and SP may coordinate on 473 setting up filters to prevent unauthorized flows from being sent to a 474 customer site; such a procedure is outside the scope of this 475 document.) See the "Security Considerations" section (Section 10) 476 for additional discussion of this issue. 478 2. Extranets and Overlapping Address Spaces 480 As specified in [RFC4364], the address space of one VPN may overlap 481 with the address space of another. A given address may be 482 "ambiguous", in that it denotes one system within VPN-A and a 483 different system within VPN-B. In the notation of Section 1.1, if an 484 address C-S is ambiguous between VPNs A and B, then Host(C-S,A) != 485 Host(C-S,B). However, any given address C-S must be unambiguous 486 (i.e., denotes a single system) in the context of a given VPN. 488 When a set of VRFs belonging to different VPNs are combined into an 489 extranet, it is no longer sufficient for an address to be unambiguous 490 only within the context of a single VPN: 492 1. Suppose C-S is the address of a given extranet C-source contained 493 in VPN-A. Now consider the set of VPNs {VPN-B, VPN-C, ...} 494 containing extranet C-receivers that are allowed by policy to 495 receive extranet C-flows from VPN-A's C-S. The address C-S MUST 496 be unambiguous among this entire set of VPNs (VPN-A, VPN-B, VPN- 497 C, etc.); i.e., Host(C-S,A) == Host(C-S,B) == Host(C-S,C). 499 The implication is that C-S in VPN-A is not necessarily an 500 extranet C-source for all VPNs that contain extranet C-receivers; 501 policy MUST be used to ensure that C-S is an extranet C-source 502 for a given VPN, say VPN-B, only if C-S is unambiguous between 503 VPN-A and VPN-B. 505 2. If a given VRF contains extranet C-receivers for a given extranet 506 C-source, then the address of this C-source MUST be unambiguous 507 among all the extranet C-sources for which there are C-receivers 508 in the VRF. This is true whether or not C-sources are in VRFs 509 that belong to the same or to different VPNs. 511 The implication is that if C-S in VRF-X is ambiguous with C-S in 512 VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing 513 C-receivers that are allowed by policy to receive extranet 514 C-flows from both C-S in VRF-X and C-S in VRF-Y. 516 Note: A VPN customer may be using "anycast" addresses. An anycast 517 address is intentionally ambiguous, as it denotes a set of systems 518 rather than a single system. In this document, we will consider an 519 anycast address to be unambiguous in a given context as long as it 520 denotes the same set of systems whenever it occurs in that context. 522 A multicast C-group address, say C-G, may also be ambiguous, in that 523 it may be used for one multicast group in VPN-A and for an entirely 524 different multicast group in VPN-B. If a set of MVPNs are combined 525 into an extranet, and C-G is an extranet C-group, it is necessary to 526 ensure that C-G is unambiguous among the entire set of VPNs whose 527 VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers 528 for that C-group. This may require, as part of the provisioning 529 process, customer/SP communication that is outside the scope of this 530 document. 532 Subject to these restrictions, the SP has complete control over the 533 distribution of routes in an MVPN. This control is exerted either by 534 provisioning the export RTs on the VRFs that originate the routes 535 (i.e., on the VRFs that contain the extranet C-sources), or by 536 provisioning the the import RTs on the VRFs that receive the routes 537 (i.e., on the VRFs that contain the extranet C-receivers), or both. 539 Some of the rules and restrictions on provisioning the RTs are 540 applicable to all extranets; these are specified in Section 4. 541 Sections 6 and 7 add additional rules and restrictions that are 542 applicable only to particular extranet scenarios. 544 Even if all the RTs are provisioned according according to the above 545 rules and restrictions, it is still possible for a single P-tunnel to 546 contain multicast data packets whose source and/or group addresses 547 are ambiguous in the context of the set of PEs that receive data from 548 the P-tunnel. That is, the above rules and restrictions are 549 necessary, but not sufficient, to prevent address ambiguity from 550 causing misdelivery of traffic. To prevent such misdelivery, 551 additional procedures or policies must be used. 553 Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may 554 carry data packets with ambiguous addresses. The additional 555 procedures and policies needed to prevent misdelivery of data in 556 those scenarios are outlined in those Section 2.3. (The detailed 557 procedures described in Sections 6 and 7 incorporate the 558 considerations of Section 2.3.) 560 2.1. Ambiguity: P-tunnel with Extranet/Non-Extranet Flows 562 In the following, we will use the notation "VRF A-n" to mean "VRF n 563 of VPN-A". 565 If VPN-A and VPN-B have overlapping address spaces, and are part of 566 the same extranet, then the following problem may exist, as 567 illustrated in Figure 1. 569 C-S2(A) C-S1 Join(C-S2(A),G) 570 \ / / 571 \ / / 572 +-------+---+ P1: (C-S1,G), (C-S2(A),G) +---+--------+ 573 |VRF A-1| |---------------------------------| |VRF A-2 | 574 +-------+PE1| |PE2+--------+ 575 |VRF B-1| |---------------------------------| |VRF B-2 | 576 +-------+---+ P2: (C-S2(B),G) +---+--------+ 577 / / \ 578 / / \ 579 C-S2(B) Join(C-S2(B),G) Join(C-S1,G) 581 Figure 1: Ambiguity of Extranet and Non-Extranet Source Address 583 Suppose: 585 o C-G is an SSM C-group used in VPNs A and B. 587 o VRF A-1, on PE1, contains an extranet C-source, whose IP address 588 is C-S1, that is allowed to have receivers in VPN B. VRF A-1 thus 589 exports to VPN B a UMH-eligible route matching C-S1. 591 o VRF A-1 also contains a non-extranet C-source, whose IP address is 592 C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 to other 593 VPN A VRFs, but NOT to VPN B. 595 o VRF B-1, also on PE1, contains a non-extranet C-source whose IP 596 address is C-S2. A UMH-eligible route matching C-S2 is thus 597 exported from VRF B-1 to other VRFs in VPN B. 599 o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous 600 address in any extranet that contains both VPN-A VRFs and VPN-B 601 VRFs. 603 o VRF B-2, on some other PE, say PE2, requests to receive the 604 multicast flow (C-S1,C-G). In the context of VRF B-2, C-S1 605 matches the route exported from VRF A-1. Thus B-2's request to 606 receive the (C-S1,C-G) flow is transmitted to VRF A-1. 608 o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by 609 transmitting that traffic on P-tunnel P1. 611 o VRF B-2 joins P-tunnel P1, in order to receiver the (C-S1,C-G) 612 traffic. 614 o VRF A-2, on PE2, requests to receive the (non-extranet) multicast 615 flow (C-S2,C-G). In the context of VRF A-2, C-S2 matches the 616 route exported from VRF A-1. Thus A-2's request to receive the 617 (C-S2,C-G) traffic is transmitted to VRF A-1. 619 o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by 620 transmitting that traffic on P-tunnel P1. 622 o VRF A-2 joins P-tunnel P1, in order to receive the (C-S2,C-G) 623 traffic. 625 o VRF B-2 requests to receive the (non-extranet) multicast flow 626 (C-S2,C-G). In the context of VRF B-2, C-S2 matches the route 627 exported from VRF B-1. Thus B-2's request to receive the 628 (C-S2,C-G) flow is transmitted to VRF B-1. 630 o VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by 631 transmitting that traffic on P-tunnel P2. 633 o VRF B-2 joins P-tunnel P2. 635 Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive 636 (C-S2,C-G) traffic on both P-tunnels. The (C-S2,C-G) traffic that 637 VRF B-2 needs to receive is traveling on P-tunnel P2; this (C-S2,C-G) 638 traffic must be forwarded by B-2 to any attached customer sites that 639 have C-receivers for it. But B-2 MUST discard the (C-S2,C-G) traffic 640 that it receives on P1, as this is not the traffic that it has 641 requested. If the (C-S2,C-G) traffic arriving on P1 were forwarded 642 to B-2's customer sites, the C-receivers would not be able to 643 distinguish the two flows, and the result would be a corrupted data 644 stream. 646 Note that the procedures of [RFC6513] Section 9.1.1 ("Discarding 647 Packets from the Wrong PE") will not cause VRF B-2 to discard the 648 (C-S2,C-G) that arrives on tunnel P1, because P1 and P2 have the same 649 upstream PE. 651 Therefore, it is necessary EITHER to prevent the above scenario from 652 occurring, OR ELSE to ensure that multicast data packets will be 653 discarded if they arrive on the "wrong" P-tunnel (even if they arrive 654 from the expected PE). See Section 2.3 for further discussion of 655 this issue. 657 2.2. Ambiguity: P-tunnel with Multiple Extranet Flows 659 Here is another example in which overlapping address spaces may cause 660 a problem. This example is illustrated in Figure 2. 662 C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G) 663 \ / / 664 \ / / 665 +-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+ 666 |VRF A-1| |---------------------------------| |VRF D-1 | 667 +-------+PE1| |PE2+--------+ 668 |VRF B-1| |---------------------------------| |VRF C-1 | 669 +-------+---+ P2: (C-S2(B2C),G) +---+--------+ 670 / / \ 671 / / \ 672 C-S2(B2C) / \ 673 Join Join 674 (C-S2(B2C),G) (C-S1(A2C),G) 676 Figure 2: Ambiguity of Extranet Source Addresses 678 Suppose: 680 o C-G is an SSM C-group address that is used in VPNs A, B, C, and D. 682 o VRF A-1, on PE1, contains an extranet C-source whose IP address is 683 C-S1, and that is allowed by policy to have C-receivers in VPN C 684 (but not in VPN D). VRF A-1 thus exports a UMH-eligible route 685 matching C-S1 to VPN C. 687 o VRF A-1 also contains an extranet C-source whose IP address is 688 C-S2, and that is allowed by policy to have C-receivers in VPN D 689 (but not in VPN C). VRF A-1 thus exports a UMH-eligible route 690 matching C-S2 to VPN D. 692 o VRF B-1, also on PE1, contains an extranet C-source whose IP 693 address is C-S2, and that is allowed by policy to have C-receivers 694 in VPN C (but not in VPN D). VRF B-1 thus exports a UMH-eligible 695 route matching C-S2 to VPN C. 697 o Host(C-S2,A) != Host (C-S2,B). That is, C-S2 is an ambiguous 698 address in any extranet that contains both VPN-A VRFs and VPN-B 699 VRFs. 701 o VRF C-1, on some other PE, say PE2, requests to receive the 702 extranet multicast flow (C-S1,C-G). In the context of VRF C-1, 703 C-S1 matches the route exported from VRF A-1. Thus C-1's request 704 to receive the (C-S1,C-G) flow is transmitted to VRF A-1. 706 o VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by 707 transmitting that traffic on P-tunnel P1, 709 o VRF C-1 joins P-tunnel P1, in order to receive the (C-S1,C-G) 710 traffic. 712 o VRF C-1 requests to receive the extranet multicast flow 713 (C-S2,C-G). In the context of VRF C-1, C-S2 matches the route 714 exported from VRF B-1. Thus C-1's request to receive the 715 (C-S2,C-G) flow is transmitted to VRF B-1. 717 o VRF B-1 responds by transmitting its (C-S2,C-G) traffic on 718 P-tunnel P2. 720 o VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) 721 traffic. 723 o VRF D-1, on PE2, requests to receive the extranet multicast flow 724 (C-S2,C-G). In the context of VRF D-1, C-S2 matches the route 725 exported from VRF A-1. Thus D-1's request to receive the 726 (C-S2,C-G) flow is transmitted to VRF A-1. 728 o VRF A-1 responds by transmitting its (C-S2,C-G) traffic on 729 P-tunnel P1. 731 o VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G) 732 traffic. 734 In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to 735 carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic. VRF 736 C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic 737 from VRF A-1, which means that VRF C-1 will also receive the unwanted 738 (C-S2,C-G) traffic from P1. VRF C-1 is also expecting (C-S2,C-G) 739 traffic from VRF B-1; this traffic will be received from P2. Thus 740 VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both 741 C-flows arrive from the expected PE, PE1. 743 Therefore, it is necessary EITHER to prevent the above scenario from 744 occurring, OR ELSE to ensure that VRF C-1 discards any (C-S,C-G) 745 traffic that arrives from the "wrong" P-tunnel. See Section 2.3 for 746 further discussion of this issue. 748 Note that the ambiguity described in this section (Section 2.2) would 749 not occur if C-G were an (ASM) extranet C-group. In that case, the 750 scenario would violate the rule, given previously in Section 2, 751 requiring that all sources sending to a particular ASM extranet 752 C-group must have addresses that are unambiguous over all the MVPNs 753 receiving traffic for that C-group. 755 2.3. Preventing Misdelivery in These Scenarios 757 There are two ways to prevent the scenarios of Section 2.1 and 758 Section 2.2 from resulting in misdelivery of data. These two ways 759 are discussed respectively in Section 2.3.1 and Section 2.3.2. 761 2.3.1. Do Not Deliver Packets from the 'Wrong' P-tunnel 763 Consider a particular C-flow that has receivers in a particular VRF. 764 Sections 6 and 7 describe a set of procedures that enable an egress 765 PE to determine the "expected P-tunnel" for that C-flow in the 766 context of that VRF. If a PE receives packets of the C-flow (as 767 determined by the IP source and/or destination address of the 768 packet), it checks to see if the packet was received on the expected 769 P-tunnel for that VRF. If so, the packet is delivered to the VRF 770 (and thus to the C-flow's receivers in that VRF). If not, the packet 771 is not delivered to the VRF. 773 Note that at a given egress PE, the "wrong" P-tunnel for one VRF may 774 be the right P-tunnel for another. 776 These procedures, if applied at every PE that joins a given P-tunnel, 777 are sufficient to prevent misdelivery of traffic in the scenarios of 778 Sections 2.1 and 2.2. 780 IF these procedures cannot be applied by every PE that is attached to 781 a given extranet, then the policies of Section 2.3.2 MUST be applied 782 at every VRF containing C-sources for that extranet. 784 In some cases, however, it may be safe to deliver packets that arrive 785 from other than the expected P-tunnel. Suppose it is known that 786 every packet gets transmitted on only a single P-tunnel. (This will 787 be the case if the "single PMSI per C-flow" transmission model, 788 discussed in Section 3.1, is being used.) Suppose further that it is 789 known that T1 and T2 carry only packets that arrived at the same 790 ingress PE, over one or more VRF interfaces that are associated with 791 the same VRF. (I.e., that there is a particular VRF that is the 792 ingress VRF for ALL the packets carried by T1 or T2.) In this case, 793 if T1 is the expected P-tunnel for a given (C-S,C-G) , it is NOT 794 necessary to discard (S,G) packets that arrive over T2. 796 It is not always possible to determine whether two P-tunnels are 797 carrying packets from the same ingress VRF. However, in some cases, 798 this can be determined by examination of the A-D routes in which the 799 tunnels have been advertised. 801 Consider the following example: 803 o Tunnel T1 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an 804 Intra-AS I-PMSI A-D route, call it R1. 806 o Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an 807 S-PMSI A-D route, call it R2. 809 o The respective NLRIs of R1 and R2 contain the same RD value. 811 o The MPLS Label field of R1's PMSI Tunnel attribute is zero, and 812 the MPLS label value of R2's PMSI Tunnel attribute is zero. 814 In this example, it can be concluded that T1 and T2 are carrying 815 packets from the same ingress VRF. Thus if T1 is the expected 816 P-tunnel for a (C-S,C-G) flow, (S,G) packets from T2 can be safely 817 delivered to the egress VRF; they do not need to be discarded. 818 Similarly, if T2 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) 819 packets from T1 can be safely delivered to the egress VRF. 821 Another example is the following: 823 o Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a 824 (C-*,C-*) S-PMSI A-D route, call it R3. 826 o Tunnel T4 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a 827 (C-S,C-G) S-PMSI A-D route, call it R4. 829 o The respective NLRIs of R3 and R4 contain the same RD value. 831 o The MPLS Label field of R3's PMSI Tunnel attribute is zero, and 832 the MPLS label value of R4's PMSI Tunnel attribute is zero. 834 In this example, it can be concluded that T3 and T4 are carrying 835 packets from the same ingress VRF. Thus if T3 is the expected 836 P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely 837 delivered to the egress VRF; they do not need to be discarded. 838 Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) 839 packets from T3 can be safely delivered to the egress VRF. 841 When Ingress Replication (IR) P-tunnels are being used, please see 842 [MVPN-IR], especially Section 6 ("The PTA's MPLS Label Field") for a 843 discussion of how to determine when packets from other than the 844 expected P-tunnel must be discarded. 846 2.3.2. Policies to Prevent Ambiguity on a P-tunnel 848 For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI 849 contains (C-S,C-G) or (C-S,C-*), the ambiguities described in 850 Sections 2.1 and 2.2 can be prevented by provisioning a policy that 851 assigns, to such P-tunnels, only flows from the same C-source. 853 However, it is not always possible to determine, through inspection 854 of the control messages, whether this policy has been deployed. For 855 instance, suppose a given VRF has imported a set of S-PMSI A-D 856 routes, that each route in the set has bound only a single 857 (C-S1,C-G1) to a single P-tunnel, and that each route in the set 858 identifies a different P-tunnel in its PTA than is identified by the 859 PTA of any other route in the set. One cannot infer from this that 860 there is no ambiguity, as the same P-tunnel may also have been 861 advertised in an S-PMSI A-D route that is not imported by the given 862 VRF, and that S-PMSI A-D route may have bound (C-S2,C-G2) to the 863 P-tunnel, where C-S1 != C-S2. 865 Therefore, in order to determine that a given P-tunnel (advertised in 866 a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from 867 a single C-source, a PE must have a priori knowledge (through 868 provisioning) that this policy has been deployed. In the remainder 869 of this document, we will refer to this policy as the "Single 870 C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy. Note that this 871 policy is only applicable to P-tunnels that are advertised only in 872 (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes. 874 Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route, or 875 (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an 876 S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always 877 possible for the P-tunnel to contain traffic from multiple C-sources; 878 there is no policy that can prevent that. 880 However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route 881 contains only traffic addressed to a single C-G, the address 882 uniqueness rules of Section 2 prevent the C-source addresses from 883 being ambiguous; the set of C-sources transmitting to a particular 884 extranet C-group address must be unambiguous over the set of MVPNs 885 that have receivers for that C-group. So for P-tunnels that are 886 advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguities described 887 Section 2.1 and Section 2.2 can be prevented by provisioning a policy 888 that assigns, to such P-tunnels, only flows to the same extranet 889 C-group. We will refer to this policy as the "Single C-group per 890 (C-*,C-G) P-tunnel" policy. 892 These considerations can be summarized as follows. IF the procedures 893 referenced in Section 2.3.1 cannot be applied, then the PEs MUST be 894 provisioned so that the all of the following conditions hold true of 895 the VRFs that contain extranet C-sources: 897 o the "Single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy 898 is provisioned, and 900 o either no (C-*,C-G) S-PMSI A-D routes are advertised, or else the 901 "Single C-group per (C-*,C-G) P-tunnel" policy is provisioned, and 903 o no P-tunnels are advertised in I-PMSI A-D routes, and 905 o no (C-*,C-*) S-PMSI A-D routes are advertised. 907 Section 3 of this document describes a procedure known as "extranet 908 separation". When extranet separation is used, the ambiguity of 909 Section 2.1 is prevented. However, the ambiguity of Section 2.2 is 910 not prevented by extranet separation. Therefore, the use of extranet 911 separation is not a sufficient condition for avoiding the procedures 912 referenced in Section 2.3.1. Extranet separation is, however, 913 implied by the policies discussed in this section (Section 2.3.2). 915 3. Extranet Transmission Models 917 This document specifies several "extranet transmission models". A 918 given VRF, containing extranet C-sources or C-receivers, MUST use 919 only one of these models. Further if VRF S contains extranet 920 C-sources, VRF R contains extranet C-receivers, and it is allowed by 921 policy for an extranet C-receiver in VRF R to receive a C-flow from 922 an extranet C-source in VRF S, then VRFs S and R MUST use the same 923 extranet transmission model. The model used by a given VRF is 924 determined by provisioning. 926 3.1. Transmitting an Extranet C-flow on a Single PMSI 928 In one extranet transmission model, which we call the "transmitting 929 an extranet C-flow on a single PMSI" model, or more simply, the 930 "single PMSI per C-flow model", a PE transmitting a packet of an 931 extranet C-flow transmits it on only a single PMSI. If the PMSI is 932 instantiated by a multicast P-tunnel, this means that the PE 933 transmits the packet on a single P-tunnel. Of course, if the PE is a 934 replication point for that multicast P-tunnel, the packet is 935 transmitted more than once by the PE. Similarly, if the PMSI is 936 instantiated by a set of unicast tunnels (i.e., via Ingress 937 Replication), each packet may be transmitted multiple times. It is 938 still the case though that the packet is transmitted only on one 939 PMSI. 941 This document provides procedures for supporting this transmission 942 model using either BGP or PIM as the PE-PE C-multicast control 943 protocol. 945 There are two variants of this transmission model: "without extranet 946 separation" and "with extranet separation". 948 3.1.1. Without Extranet Separation 950 In this variant, multicast data traffic from extranet C-sources and 951 from non-extranet C-sources may be carried in the same P-tunnel. 953 This document provides procedures for supporting this variant using 954 either BGP or PIM as the PE-PE C-multicast control protocol. 956 3.1.2. With Extranet Separation 958 In this variant, multicast data traffic from extranet C-sources and 959 from non-extranet C-sources are never carried in the same P-tunnel. 960 Under certain circumstances, this can reduce the amount of multicast 961 data traffic that is delivered unnecessarily to certain PE routers. 962 It also eliminates the ambiguity discussed in Section 2.1. 964 By definition, when extranet separation is used, the following rule 965 MUST be applied: 967 Traffic from extranet C-sources MUST NOT be carried in the same 968 P-tunnel as traffic from non-extranet C-sources. 970 This rule does not impact those VRFs that contain only non-extranet 971 C-sources, nor does it impact those VRFs that contain only extranet 972 C-sources. However, if a particular VRF contains both kinds of 973 C-source, it will need to advertise some P-tunnels that are used for 974 carrying only extranet C-flows, and some that are used only for 975 carrying non-extranet C-flows. 977 This document provides procedures for supporting extranet separation 978 when BGP is used as the PE-PE C-multicast control protocol. Support 979 for extranet separation using PIM as the PE-PE C-multicast control 980 protocol is outside the scope of this document. 982 3.2. Transmitting an Extranet C-flow over Multiple PMSIs 984 The second extranet transmission model is called the "transmitting an 985 extranet C-flow over multiple PMSIs" model, or more simply, the 986 "multiple PMSIs per C-flow model". In this model, a PE may transmit 987 the packets of an extranet C-flow on several different PMSIs. 989 Support for extranet separation with this model is outside the scope 990 of this document. 992 This document provides procedures for supporting this transmission 993 model when PIM as the PE-PE C-multicast control protocol. Support 994 for this transmission model when BGP is used as the PE-PE C-multicast 995 control protocol is outside the scope of this document. 997 4. Distribution of Routes that Match C-S/C-RP Addresses 999 4.1. UMH-Eligible Routes 1001 As described in Section 5.1 of [RFC6513], in order for a C-flow 1002 (C-S,C-G) to be carried across the SP backbone, a VRF that has 1003 multicast receivers for that C-flow MUST import a route that matches 1004 C-S, and this route must be "eligible for UMH selection". In this 1005 document, we will refer to these routes as "UMH-eligible extranet 1006 C-source routes". 1008 The UMH-eligible extranet C-source routes do not necessarily have to 1009 be unicast routes. If one wants, e.g., a VPN-R C-receiver to be able 1010 to receive extranet C-flows from C-sources in VPN-S, but one does not 1011 want any VPN-R system to be able to send unicast traffic to those 1012 C-sources, then the UMH-eligible routes exported from VPN-S and 1013 imported by VPN-R MAY be SAFI-129 routes (see Section 5.1.1 of 1014 [RFC6513]). The SAFI-129 routes are used only for UMH determination, 1015 but not for unicast routing. 1017 If a customer is using PIM-SM in ASM mode, and one or more customer 1018 sites have C-receivers that are allowed by policy to join a (C-*,C-G) 1019 tree, where C-G is an extranet C-group, then any VRF with C-receivers 1020 for that group MUST import a UMH-eligible route that matches C-RP, 1021 where C-RP is the Rendezvous Point (RP) address for C-G. 1023 The UMH-eligible extranet C-source and C-RP routes do not have to be 1024 "host routes." That is, they can be routes whose IPv4 address 1025 prefixes are not 32 bits in length, or whose IPv6 address prefixes 1026 are not 128 bits in length. So it is possible for a UMH-eligible 1027 extranet C-source route to match the address of an extranet C-source 1028 and to also match the address of a non-extranet C-source. However, 1029 if such a route is exported from a VPN-S VRF and imported by a VPN-R 1030 VRF, VPN-R receivers will be able to receive C-flows from any non- 1031 extranet C-sources whose addresses match that route. To prevent 1032 this, the VPN-S VRF SHOULD be provisioned such that it will NOT 1033 export a UMH-eligible route that matches (in the context of the VPN-R 1034 VRF) both extranet C-sources and non-extranet C-sources. Failure to 1035 follow this rule may result in a VPN security violation. (See 1036 Section 10.) 1038 In general, one does not want ALL the routes from the VPN-S VRFs to 1039 be exported to all the VPN-R VRFs, as only a subset of the routes in 1040 the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route 1041 distribution is, as always in a BGP/MPLS IP VPN [RFC4364], controlled 1042 by Route Targets (RTs). A variety of route distribution policies can 1043 be created by appropriately provisioning the import and export RTs of 1044 the various VRFs. 1046 For example, the VPN-S VRFs that contain extranet C-sources could be 1047 configured to apply an export RT whose value is "RT-A-extranet" to 1048 the routes that match the extranet C-sources. The VPN-R VRFs that 1049 contain extranet C-receivers allowed to receive extranet C-flows from 1050 VPN-S extranet C-sources could then be configured with "RT- 1051 A-extranet" as an import RT. 1053 Arbitrarily complex policies can be created by suitable manipulation 1054 of the import and export RTs. 1056 4.1.1. Extranet Separation 1058 If Extranet Separation is being used, and if a given VRF is exporting 1059 UMH-eligible routes both for extranet C-sources for non-extranet 1060 C-sources, then the VRF MUST be configured not only with its "default 1061 RD", but also with an "extranet RD". The exported UMH-eligible 1062 routes MUST contain the extranet RD in their NLRIs. 1064 4.2. Distribution of Unicast Routes Matching C-RPs and DRs 1066 Consider a C-source, C-S, that may transmit to a particular extranet 1067 C-group, C-G. 1069 In order to follow the procedures of [RFC4601], 1071 o the "first hop designated router" (DR) of C-S needs to be able to 1072 unicast "PIM Register Messages" to a C-RP that services C-G; 1074 o the C-RPs servicing C-G need to be able to unicast "PIM Register- 1075 Stop Messages" to the DR of C-S. 1077 It follows that if a VRF contains C-S, but does not contain a C-RP 1078 for C-G, then the VRF must import a unicast route matching a C-RP for 1079 C-G. Note that the unicast route matching the C-RP is needed whether 1080 or not the VRF has also imported a SAFI-129 route matching the C-RP. 1081 (If the VRF also contains receivers for C-G, and if UMH determination 1082 is being done using SAFI-129 routes, both a unicast route and a 1083 SAFI-129 matching C-RP route are needed.) 1085 Similarly, if a VRF contains a C-RP for C-G, but does not contain 1086 C-S, the VRF must import a unicast route matching the DR for C-S. 1087 Note that the unicast route matching the DR for C-S is needed even if 1088 UMH determination is being done using SAFI-129 routes; in that case, 1089 if the VRF also contains receivers for C-G, it needs to import a 1090 SAFI-129 route matching C-S and a unicast route matching the DR for 1091 C-S. 1093 If, for a particular extranet C-group, C-G, the customer is using 1094 "anycast-RP"([RFC3446], [RFC4610]) or MSDP [RFC3618], then all the 1095 C-RPs serving C-G need to send unicast messages to each other. Thus 1096 any VRF that contains a C-RP for C-G needs to import unicast routes 1097 matching ALL the other C-RPs that serve C-G. 1099 The need to distribute these unicast routes is usually not a problem 1100 as long as all the C-sources and C-RPs for C-G are in the same MVPN. 1101 If, however, the C-sources are not all in the same MVPN, great care 1102 must be taken to ensure that the unicast routes mentioned above are 1103 properly distributed. 1105 There may be scenarios in which all the C-sources for C-G are in the 1106 same MVPN, but there are receivers in different VPNs, and some or all 1107 of the VPNs with receivers have their own C-RPs for C-G. In this 1108 case, care must be taken to ensure that the C-RPs can all unicast to 1109 each other. 1111 4.3. Route Targets and Ambiguous UMH-Eligible Routes 1113 This section imposes constraints on the way RTs are assigned to (a) 1114 UMH-eligible routes and to (b) the BGP A-D routes that advertise 1115 P-tunnels (i.e., to BGP A-D routes that contain a PTA). The 1116 constraints specified here apply to any extranet for which the 1117 ambiguity of Section 2.2 is possible. (The conditions under which 1118 such ambiguity is possible are described in Section 2.2.) 1120 We want to ensure that, in any given VRF, the UMH-eligible route 1121 matching a given extranet C-source has an RT in common with every BGP 1122 A-D route that advertises a P-tunnel that may be used to carry 1123 extranet multicast traffic from that C-source. We also want to 1124 ensure that the UMH-eligible route matching a given extranet C-source 1125 does not have any RT in common with any BGP A-D route that advertises 1126 a P-tunnel that may be used to carry any multicast traffic from a 1127 different C-source that has the same IP address. This enables us to 1128 determine whether traffic that appears to be from the given C-source 1129 is really arriving on the "wrong tunnel", and hence is really from a 1130 different C-source with the same IP address. 1132 Suppose an IP address C-S is used in VPN-A as the address of one 1133 system, and is used in VPN-B as the address of a different system. 1134 In this case, one or more VPN-A VRFs may export a VPN-IP route whose 1135 NLRI is , and one or more VPN-B VRFs may export a VPN-IP route 1136 whose NLRI is , where RD1 != RD2. Consider two routes, R1 and 1137 R2, for which the following conditions all hold: 1139 o R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or 1140 are unicast routes matching a C-RP 1142 o R1 is exported from a VRF of VPN-A, while R2 is exported from a 1143 VRF of a different VPN, say VPN-B 1145 o R1's NLRI specifies IP address prefix S/n 1147 o R2's NLRI specifies IP address prefix S/m 1149 o m >= n, (S/m is either the same as or more specific than S/n) 1151 o There is some host address H such that: 1153 * H denotes a different system in VPN-A than in VPN-B, 1155 * H/m == S/m (so either S/m or S/n might be a longest match for H 1156 in some VRF). 1158 We impose the following constraint: RTs MUST be assigned in such a 1159 way that R1 and R2 do not have any RT in common. 1161 (This constraint is not as onerous at it may seem. Typically R1 and 1162 R2 would not have an RT in common, as that might result in their 1163 being imported into the same VRF, making the address H ambiguous in 1164 that VRF.) 1166 Sections 6 and 7 specify procedures for determining if a received 1167 C-flow has been received over the expected P-tunnel. Those 1168 procedures will not work if this constraint is violated. (The 1169 constraint described in this section is necessary but not sufficient 1170 for the procedures of those sections to work; additional constraints, 1171 covering the assignment of RTs to BGP A-D routes, are given in 1172 subsequent sections.) 1174 4.4. Dynamically Marking Extranet Routes 1176 4.4.1. The Extranet Source Extended Community 1178 Sections 4.1, 4.2, and 4.3 place specific requirements on the way in 1179 which certain VPN-IP routes are distributed. In order to ensure that 1180 these requirements are met, a VPN customer must tell its SP which 1181 routes are the matching routes for extranet C-sources and C-RPs. 1182 This may be done as part of the provisioning process. Note that this 1183 does not necessarily require customer/provider interaction every time 1184 the customer adds a new extranet C-source or C-RP, but only when the 1185 IP address of the new C-source or C-RP does not match an existing 1186 route that is already being distributed as a VPN-IP extranet route. 1187 Nevertheless, it seems worthwhile to support an OPTIONAL mechanism 1188 that allows a customer to dynamically mark certain routes as being 1189 extranet routes. 1191 To facilitate this, we define a new transitive opaque extended 1192 community, the "Extranet Source" extended community. When a CE 1193 router advertises (via BGP) a route to a PE router, and the AFI/SAFI 1194 of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source 1195 extended community MAY be attached to the route. The value field of 1196 the extended community MUST be set to zero. By placing this extended 1197 community on a particular route, a CE router indicates to a PE router 1198 that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied 1199 to that route. That is, the CE router may use this extended 1200 community to indicate to the PE router that a particular route is to 1201 be treated as a route that matches the address of an extranet source, 1202 and exported accordingly to other VPNs. 1204 Whether a CE router uses the Extranet Source extended community is 1205 determined by the configuration of the CE router. If used, the set 1206 of routes to which the extended community is attached is also 1207 determined by configuration of the CE. Note that a particular PE 1208 router may or may not support the use of the Extranet Source extended 1209 community by a particular CE router; this is determined by the 1210 service agreement between the SP and its customer. 1212 If a CE is advertising SAFI-2 routes to the PE as the UMH-eligible 1213 extranet C-source and C-RP routes, and if the CE is using the 1214 Extranet Source extended community, it is important that the CE 1215 attach that extended community to the SAFI-2 routes, rather than just 1216 to the corresponding SAFI-1 routes. Otherwise extranet receivers may 1217 not be able to join the (C-S,C-G) or (C-*,C-G) multicast trees. 1219 However, if the C-sources and the C-RPs for a given extranet C-group 1220 are not all in the same VPN, the extended community would also have 1221 to be attached to the SAFI-1 routes that match the C-RP addresses and 1222 to the SAFI-1 routes that match the addresses of the first hop 1223 designated routers for all the C-sources. Otherwise, the first hop 1224 routers might not be able to send PIM Register messages to the C-RPs, 1225 and the C-RPs might not be able to send PIM Register-Stop messages to 1226 the first hop routers. 1228 While this extended community allows a customer to inform the SP 1229 dynamically that certain routes are "extranet routes", it does not 1230 allow a customer to control the set of RTs that the route will carry 1231 when it is redistributed as a VPN-IP route. Thus it is only useful 1232 when all the extranet routes from a given VRF are exported with 1233 exactly the same set of RTs. (Cf. Section 4.3.1 of [RFC4364], which 1234 does provide a mechanism that, if properly supported by the SP, 1235 allows the customer to determine the set of RTs carried by a VPN-IP 1236 route.) 1238 Note that misconfiguration on the CE router can result in the 1239 Extranet Source extended community being mistakenly attached to a 1240 route that is not intended to be exported as an extranet route. This 1241 could result in a VPN security violation. 1243 4.4.2. Distribution of Extranet Source Extended Community 1245 When a PE receives from a CE a route with the Extranet Source 1246 extended community, the corresponding VPN-IP route originated by the 1247 PE MUST carry this extended community. 1249 A Route Reflector MUST NOT add/remove the Extranet Source extended 1250 community from the VPN-IP routes reflected by the Route Reflector, 1251 including the case where VPN-IP routes received via IBGP are 1252 reflected to EBGP peers (inter-AS option (c), see [RFC6513] 1253 Section 10). 1255 When re-advertising VPN-IP routes, ASBRs MUST NOT add/remove the 1256 Extranet Source extended community from these routes. This includes 1257 inter-AS options (a) and (b) (see [RFC6513] Section 10). 1259 When a PE advertises (via BGP) IP routes to a CE, these routes MUST 1260 NOT carry the Extranet Source extended community, unless the PE-CE 1261 connection is actually an inter-AS option (a) connection (see 1262 [RFC6513] Section 10). When the PE-CE connection is not an inter-AS 1263 option (a) connection, a CE that receives an IP route with the 1264 Extranet Source extended community MUST remove it from the route 1265 before readvertising the route. 1267 4.5. The 'Extranet Separation' Extended Community 1269 We define a new transitive opaque extended community, the "Extranet 1270 Separation" extended community. This extended community is used only 1271 when extranet separation is being used. Its value field MUST be set 1272 to zero upon origination, MUST be ignored upon reception, and MUST be 1273 passed unchanged by intermediate routers. 1275 If a VRF has been provisioned to use extranet separation, and if that 1276 VRF has been provisioned to transmit any extranet C-flows on a 1277 P-tunnel that it advertises in an I-PMSI A-D route or a (C-*,C-*) 1278 S-PMSI A-D route, then any UMH-eligible routes that are exported from 1279 that VRF following the procedures of Sections 4.1, 4.2, and 4.3 MUST 1280 carry the Extranet Separation extended community. In addition, if an 1281 I-PMSI A-D route and/or (C-*,C-*) S-PMSI A-D route, exported from 1282 that VRF, is used to carry extranet traffic, that A-D route MUST also 1283 carry the Extranet Separation extended community. Further details 1284 may be found in Sections 7.3, 7.4.4, and 7.4.5. 1286 5. Origination and Distribution of BGP A-D Routes 1288 Except where otherwise specified, this section describes procedures 1289 and restrictions that are independent of the PE-PE C-multicast 1290 control protocol. 1292 5.1. Route Targets of UMH-eligible Routes and A-D Routes 1294 Suppose there is an extranet C-flow such that: 1296 o The extranet C-source of that C-flow is in VRF A-1. 1298 o One or more extranet C-receivers of that C-flow are in VRF B-1. 1300 In this case VRF A-1 must export a UMH-eligible route that matches 1301 the extranet C-source address, and VRF B-1 must import that route. 1302 In addition, VRF A-1 must export an Intra-AS I-PMSI A-D route or an 1303 S-PMSI A-D route specifying the P-tunnel through which it will send 1304 the data traffic of the given extranet C-flow, and VRF B-1 must 1305 import that route. If BGP is the PE-PE C-multicast control protocol, 1306 then under certain conditions (as specified in [RFC6514]), VRF A-1 1307 may also need to export a Source Active A-D route specifying that it 1308 contains a source of the given C-flow, and VRF B-1 must import that 1309 Source Active A-D route. That is, in order for VRF B-1 to receive a 1310 C-flow from, a given extranet C-source contained in VRF A-1, VRF A-1 1311 must export a set of A-D routes that are "about" that source, and VRF 1312 B-1 must import them. 1314 One way to ensure this is to provision an RT that is carried by all 1315 the routes exported from VRF A-1 that are "about" a given extranet 1316 C-source, and to provision this RT as an import RT at any VRF (such 1317 as VRF B-1) that is allowed to receive extranet flows from source. 1319 If the "single PMSI per C-flow" transmission model is being used 1320 (with or without extranet separation), there is a an additional 1321 requirement, stated below, on the way RTs are provisioned, as the RTs 1322 carried by a UMH-eligible route that matches a given extranet 1323 C-source may need to be used to identify the A-D routes that are 1324 "about" that source. 1326 Consider the following scenario: 1328 o IP address S is the address of one system in VPN-A, and of a 1329 different system in VPN-B. 1331 o VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching 1332 route for S. 1334 o VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a 1335 P-tunnel through which VRF A-1 may send traffic whose C-source is 1336 S, where one of the following conditions holds: 1338 * P1 is an I-PMSI A-D route, OR 1340 * P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or 1341 (C-*,C-G), OR 1343 * P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or 1344 (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) 1345 P-tunnel" policy is not provisioned. 1347 * P1 is a Source Active A-D route whose NLRI contains (C-S,C-G). 1349 o VRF B-1 on PE1 exports a UMH-eligible route R2, which is a 1350 matching route for S. 1352 o VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a 1353 P-tunnel on which VRF B-1 may send traffic whose C-source is S, 1354 where one of the following conditions holds: 1356 * P2 is an I-PMSI A-D route, OR 1358 * P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or 1359 (C-*,C-G), OR 1361 * P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or 1362 (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) 1363 P-tunnel" policy is not provisioned. 1365 * P2 is a Source Active A-D route whose NLRI contains (C-S,C-G) 1367 As already specified in Section 4.1, there MUST NOT be any RT that is 1368 common to both R1 and R2. In addition, the following set of rules 1369 for RT assignment MUST be followed when extranets are supported. 1370 This set of rules supports all the extranet transmission models 1371 described in this specification: 1373 o There MUST NOT be any RT that is carried by both P1 and P2. 1375 o The intersection of the set of RTs carried by P1 and the set of 1376 RTs carried by R1 MUST be non-null, and any VRF that imports both 1377 P1 and R1 MUST be configured with an import RT from this 1378 intersection. 1380 o The intersection of the set of RTs carried by P2 and the set of 1381 RTs carried by R2 MUST be non-null, and any VRF that imports both 1382 P2 and R2 MUST be configured with an import RT from this 1383 intersection. 1385 Suppose VRF C-1 on PE2 imports P1 and R1 from VRF A-1, while also 1386 importing P2 from VRF B-1. Since: 1388 o R1 is VRF C-1's route to S, and 1390 o R1 has an RT in common with P1, and 1392 o R1 has no RT in common with P2 1394 it can be concluded that VRF C-1 should expect that multicast traffic 1395 from S will arrive on the P-tunnel specified in P1. See Section 6 1396 and Section 7 for more details on determining the expected P-tunnel 1397 for a given extranet C-flow. 1399 While the assignment of import and export RTs to routes is a 1400 deployment and provisioning issue rather than a protocol issue, it 1401 should be understood that failure to follow these rules is likely to 1402 result in VPN security violations. 1404 5.2. Considerations for Particular Inclusive Tunnel Types 1406 5.2.1. RSVP-TE P2MP or Ingress Replication 1408 This section applies when Inclusive Tunnels are created using either 1409 RSVP-TE P2MP or Ingress Replication. 1411 Suppose a VRF, VRF-S, contains a given extranet C-source C-S, and 1412 that VRF-S advertises in its Intra-AS I-PMSI A-D route either a P2MP 1413 RSVP-TE P-tunnel or an Ingress Replication P-tunnel to carry extranet 1414 traffic. 1416 In order for VRF-S to set up the P2MP RSVP-TE or Ingress Replication 1417 P-tunnel, it must know all the PEs that are leaf nodes of the 1418 P-tunnel, and to learn this it MUST import an Intra-AS I-PMSI A-D 1419 route from every VRF that needs to receive data through that tunnel. 1421 Therefore if VRF-R contains an extranet C-receiver that is allowed by 1422 policy to receive extranet flows from C-S, the the RT(s) carried by 1423 the Intra-AS I-PMSI A-D routes originated by VRF-R must be such that 1424 those Intra-AS I-PMSI A-D routes will be imported into VRF-S. 1426 In the case of Ingress Replication, this has the following 1427 consequence. If an egress PE has n VRFs with receivers for a flow 1428 that VRF-S transmits on its I-PMSI, that egress PE will receive n 1429 copies of the same packet, one for each of the n VRFs. 1431 Note that Section 9.1.1 of [RFC6514] prohibits the Leaf Information 1432 Required flag from being set in the PTA of an Intra-AS I-PMSI A-D 1433 route. If this prohibition is ever removed, the requirement of this 1434 section will apply only if VRF-S does not set that flag. 1436 5.2.2. Ingress Replication 1438 This section applies only when Inclusive Tunnels are created via 1439 Ingress Replication. 1441 [RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be 1442 instantiated by Ingress Replication. The concept of an IR P-tunnel, 1443 and the procedures for supporting IR P-tunnels, are explained more 1444 fully in [MVPN-IR]. An IR P-tunnel can be thought of as a P2MP tree 1445 in which a packet is transmitted from one node on the tree to another 1446 by being encapsulated and sent through a unicast tunnel. 1448 As discussed in Section 2, when I-PMSIs are used to support 1449 extranets, egress PEs MUST have the ability to discard customer 1450 multicast data packets that arrive on the wrong P-tunnel. When 1451 I-PMSIs are instantiated by IR, this implies that the following two 1452 procedures MUST be followed: 1454 1. One of the following three procedures MUST be followed: 1456 a. the "Single Forwarder Selection" procedures of [RFC6513] 1457 Section 9.1.2, 1459 b. the "Native PIM Methods" procedures of [RFC6513] 1460 Section 9.1.3 1462 c. the unicast encapsulation used to transmit packets along the 1463 IR P-tunnel must be such as to enable the receiving node to 1464 identify the transmitting node (note that this would not be 1465 the case if, e.,g., the unicast tunnels were MP2P LSPs); 1467 and 1469 2. If a PE assigns an MPLS label value in the PMSI Tunnel attribute 1470 of an Intra-AS or Inter-AS I-PMSI A-D route that it originates, 1471 that label value MUST NOT appear in the PMSI Tunnel attribute of 1472 any other I-PMSI or S-PMSI A-D route originated by the same PE. 1474 Failure to follow these procedures would make it impossible to 1475 discard packets that arrive on the wrong P-tunnel, and thus could 1476 lead to duplication of data. 1478 If it is desired to support extranet while also using IR to 1479 instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs 1480 instead of I-PMSIs. (See [RFC6625] and Sections 7.2.2, 7.3.2, and 1481 7.4.4 of this document.) This has much the same effect in the data 1482 plane, and there are no restrictions on the type of unicast tunnel 1483 that can be used for instantiating S-PMSIs. 1485 Section 6.4.5 of [RFC6513] describes a way to support VPNs using 1486 I-PMSIs that are instantiated by IR, using no S-PMSIs, but using 1487 "explicit tracking" to ensure that a C-flow goes only to egress PEs 1488 that have receivers for it. This document does not provide 1489 procedures to support extranet using that model. 1491 6. When PIM is the PE-PE C-multicast Control Plane 1493 As specified in [RFC6513], when PIM is used as the PE-PE C-multicast 1494 control plane for a particular MVPN, there is an MI-PMSI for that 1495 MVPN, and all the PEs of that MVPN must be able to send and receive 1496 on that MI-PMSI. Associated with each VRF of the MVPN is a PIM 1497 C-instance, and the PIM C-instance treats the MI-PMSI as if it were a 1498 LAN interface. That is, the "ordinary" PIM procedures run over the 1499 MI-PMSI just as they would over a real LAN interface, except that the 1500 data plane and control plane "RPF checks" need to be modified. 1501 Section 5.2 of [RFC6513] specifies the RPF check modifications for 1502 non-extranet MVPN service. 1504 For example, suppose that there are two VPNs, VPN-S and VPN-R. In 1505 the absence of extranet support, all the VRFs of VPN-S are connected 1506 via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of 1507 VPN-R are connected via another ("the VPN-R MI-PMSI"). If we want to 1508 provide extranet service in which the extranet C-sources are attached 1509 to some set of VPN-S VRFs, while the extranet C-receivers are 1510 attached to some set of VPN-R VRFs, then we have two choices: 1512 1. either the VPN-R VRFs need to join the VPN-S MI-PMSI, or 1514 2. the VPN-S VRFs need to join the VPN-R MI-PMSI. 1516 The first choice is used to support the "single PMSI per C-flow" 1517 transmission model. The second choice is used to support the 1518 "multiple PMSIs per C-flow" transmission model. 1520 Procedures for both models are described below. 1522 To support these models, it must be possible to determine which 1523 I-PMSI A-D routes are associated with the VPN-S I-PMSI, and which are 1524 associated with the VPN-R I-PMSI. Procedures are given for assigning 1525 RTs to these routes in a way that makes this determination possible. 1527 Both models allow the use of S-PMSIs to carry multicast data traffic. 1528 If a VRF containing receivers can receive from multiple MI-PMSIs, 1529 each S-PMSI must be uniquely associated with a particular MI-PMSI. 1530 Procedures are given for assigning RTs to these routes in a way that 1531 makes this determination possible. 1533 All the procedures specified in Sections 3, 4, and 5 still apply. 1535 Note that there are no special extranet procedures for Inter-AS 1536 I-PMSI A-D routes or for Leaf A-D routes. Source Active A-D routes 1537 are not used when PIM is the PE-PE C-multicast protocol. 1539 6.1. Provisioning VRFs with RTs 1541 6.1.1. Incoming and Outgoing Extranet RTs 1543 In the absence of extranet service, suppose that each VRF of a given 1544 VPN, call it VPN-S, is configured with RT-S as its import and export 1545 RT, and that each VRF of a second VPN, call it VPN-R, is configured 1546 with RT-R as its import and export RT. We will refer to RT-S and 1547 RT-R as "non-extranet RTs". 1549 Now suppose that VPN-S contains some extranet C-sources, and VPN-R 1550 contains some extranet C-receivers that are allowed by policy to 1551 receive extranet C-flows from the VPN-S extranet C-sources. 1553 To set up this S-to-R extranet, it is necessary to provision an 1554 additional RT, call it RT-S-to-R, whose value is, in general, 1555 distinct from RT-S and RT-R. 1557 A VPN-S VRF that contains extranet C-sources allowed to transmit to 1558 VPN-R must be configured with RT-S-to-R as an "Outgoing Extranet RT". 1560 A VPN-R VRF that contains extranet C-receivers allowed to received 1561 from VPN-S must be configured with RT-S-to-R as an "Incoming Extranet 1562 RT". 1564 Note that the terms "Incoming" and "Outgoing" in this context refer 1565 to the direction of multicast data packets relative to the VRF. 1567 The Incoming Extranet RTs and Outgoing Extranet RTs that are 1568 configured for a given VRF serve as import RTs for that VRF. They 1569 also serve as export RTs, but only for specific routes as specified 1570 in Section 6.1.2 below. 1572 Note that any VRF that contains both extranet C-sources and extranet 1573 C-receivers MUST be configured with both Outgoing and Incoming 1574 Extranet RTs. 1576 A VRF may be configured with more than one Incoming and/or Outgoing 1577 Extranet RT. 1579 If it happens to be the case that all C-sources in VPN-S are extranet 1580 C-sources allowed to transmit to VPN-R, then VPN-S VRFs may be 1581 configured such that RT-S is both a non-extranet RT and an Outgoing 1582 Extranet RT, and VPN-R VRFs may be configured such that RT-S is an 1583 Incoming Extranet RT. 1585 6.1.2. UMH-eligible Routes and RTs 1587 Suppose R1 is a route, exported from a VPN-S VRF, matching an 1588 extranet C-source that is allowed by policy to transmit to VPN-R. 1589 Then R1 MUST carry the Outgoing Extranet RT used for the S-to-R 1590 extranet. This will cause the route to be imported into the VPN-R 1591 VRFs that have extranet C-receivers that are allowed by policy to 1592 receive from VPN-S. 1594 The rules of Section 4 regarding route targets and ambiguous 1595 addresses still apply. 1597 6.1.3. PIM C-Instance Reverse Path Forwarding Determination 1599 Suppose a PIM control message, call it M, is received by a given VRF 1600 V, from a particular P-tunnel T. In order to process control message 1601 M, the PIM C-instance associated with VRF V may need to do an "RPF 1602 determination" (see Section 5.2.2 of RFC 6513) for a particular IP 1603 prefix S. RPF determination is based upon the rules for UMH 1604 selection as specified in Section 5.1 of RFC 6513. 1606 This document adds an additional constraint on the UMH selection 1607 procedure. When doing RPF determination for a PIM control message 1608 received over a P-tunnel, a route matching prefix S is not considered 1609 to be eligible for UMH selection unless there is an RT, call it RT1, 1610 configured as one of V's Outgoing Extranet RTs, such that the 1611 following two conditions both hold: 1613 1. The route matching S is exported from VRF V carrying RT1, and 1614 2. An I-PMSI A-D route advertising P-tunnel T (in its PTA) has been 1615 imported into VRF V, and that I-PMSI A-D route carries RT1. 1617 6.2. Single PMSI per C-flow Model 1619 In this model, if a VPN-S VRF has extranet multicast C-sources, and a 1620 VPN-R VRF has extranet multicast C-receivers allowed by policy to 1621 receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins 1622 the MI-PMSI that VPN-S uses for its non-extranet traffic. 1624 6.2.1. Forming the MI-PMSIs 1626 Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], 1627 each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing 1628 a PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as 1629 part of the VPN-S MI-PMSI. In the absence of extranet service, this 1630 route carries the VRF's non-extranet RT, RT-S. When extranet service 1631 is provided (using the "single PMSI per C-flow" model), this route 1632 MUST also carry EACH of the VRF's Outgoing Extranet RTs. 1634 Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], 1635 each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing 1636 a PTA specifying the P-tunnel to be used as part of the VPN-R MI- 1637 PMSI. This route carries the VRF's non-extranet RT RT-R. When 1638 extranet service is provided (using the "single PMSI per C-flow" 1639 model), the VPN-R VRF MUST also originate one or more additional 1640 Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- 1641 AS I-PMSI A-D route for each Incoming Extranet RT with which it has 1642 been configured; each such route will carry exactly one of the 1643 configured Incoming Extranet RTs. 1645 Note that when a VRF originates more than one Intra-AS I-PMSI A-D 1646 route, each of them MUST contain a different RD in its NLRI. In 1647 addition, we add the requirement that any pair of such routes MUST 1648 NOT contain an RT in common. 1650 A VRF with extranet C-sources MUST join the P-tunnels advertised in 1651 the imported I-PMSI A-D routes that carry its non-extranet RT or any 1652 of its Outgoing Extranet RTs. This set of P-tunnels will be treated 1653 as instantiating a single MI-PMSI, and the associated PIM C-instance 1654 will treat that MI-PMSI as a single LAN, and will run PIM procedures 1655 on that LAN, as specified in [RFC6513]. The fact that the MI-PMSI 1656 attaches to VRFs of different VPNs is not known to the PIM C-instance 1657 of the VRF containing the sources. 1659 A VRF with extranet C-receivers MUST join the P-tunnels advertised in 1660 all the imported I-PMSI A-D routes. The set of P-tunnels advertised 1661 in the I-PMSI A-D routes that carry a particular Incoming Extranet RT 1662 are treated as instantiating a particular MI-PMSI. So a VRF with 1663 C-receivers will "see" several MI-PMSIs, one corresponding to the 1664 non-extranet, and as many as one for each configured Incoming 1665 Extranet RT. The PIM C-instance associated with the VRF will treat 1666 each of these MI-PMSIs as a separate LAN interface. 1668 As an example, suppose: 1670 o All VPN-R VRFs are configured with RT-R as a non-extranet import 1671 and export RT, 1673 o VPN-R VRFs with extranet receivers are configured with RT-S-to-R 1674 as an Incoming Extranet RT, 1676 o VPN-S VRFs with extranet transmitters are configured: 1678 * with RT-S as a non-extranet import and export RT 1680 * with a list of IP addresses that are the addresses of the 1681 extranet sources 1683 * with RT-S-to-R as an Outgoing Extranet RT 1685 Then VPN-S VRFs will export UMH-eligible routes matching extranet 1686 C-sources, and these routes will carry both RT-S and RT-S-to-R. Each 1687 VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries 1688 both RT-S and RT-S-to-R. 1690 VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes: 1691 one carrying RT-R, and one carrying RT-S-to-R. The Intra-AS I-PMSI 1692 A-D route with RT-S-to-R will be imported into the VPN-S VRFs. 1694 VPN-R will regard all the I-PMSI A-D routes it has exported or 1695 imported with RT-S-to-R as part of a single MI-PMSI. VPN-R will 1696 regard all the I-PMSI A-D routes it has exported or imported with 1697 RT-R as part of a second MI-PMSI. The PIM C-instance associated with 1698 a VPN-R VRF will treat the two MI-PMSIs as two separate LAN 1699 interfaces. However, the VPN-S VRFs will regard all the I-PMSI A-D 1700 routes imported with RT-S or RT-S-to-R as establishing only a single 1701 MI-PMSI. One can think of this as follows: the VPN-R VRFs have 1702 joined the VPN-S MI-PMSI, as well as the VPN-R MI-PMSI. 1704 Extranets consisting of more than two VPNs are easily supported as 1705 follows. Suppose there are three VPNs, VPN-A, VPN-B, and VPN-C. 1706 VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers 1707 for both VPN-A extranet C-sources and VPN-B extranet C-sources. In 1708 this case, the VPN-C VRFs that have receivers for both VPN-A and 1709 VPN-B sources may be provisioned as follows. These VPN-C VRFs may be 1710 provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and 1711 RT-B-to-C as Incoming Extranet RTs. In this case, the VPN-C VRFs 1712 that are so provisioned will originate three Intra-AS I-PMSI A-D 1713 routes (each with a different RD in its NLRI), each of which carries 1714 exactly one of the three RTs just mentioned. The VPN-B VRFs with 1715 extranet C-sources will be provisioned with RT-B-to-C as an Outgoing 1716 Extranet RT, and the VPN-A VRFs are provisioned with RT-A-to-C as an 1717 Outgoing Extranet RT. The result will be that the PIM C-instance 1718 associated with a VPN-C VRF will see three LAN interfaces: one for 1719 the non-extranet, one for each of the two extranets. This 1720 generalizes easily to the case where there are VPN-C receivers in n 1721 different extranets (i.e., receiving extranet flows whose sources are 1722 in n different VPNs). 1724 Suppose again that there are there are three VPNs, VPN-A, VPN-B, and 1725 VPN-C. But in this example, VPN-A is the only one with extranet 1726 sources, while VPN-B and VPN-C both have receivers for the VPN-A 1727 extranet sources. This can be provisioned as either one extranet or 1728 as two. 1730 To provision it as one extranet, the VPN-A VRFs are configured with 1731 one Outgoing Extranet RT, call it "RT-A-extranet". The VPN-B and 1732 VPN-C VRFs with extranet receivers will be provisioned with RT- 1733 A-extranet as Incoming Extranet RT. Thus the VPN-B and VPN-C VRFs 1734 will each originate two Intra-AS I-PMSI A-D routes, one for non- 1735 extranet, and one for the extranet. The Intra-AS I-PMSI A-D route, 1736 from a given VRF, for the extranet will carry RT-A-extranet, but will 1737 not share any RT with the non-extranet A-D routes exported from the 1738 same VRF. 1740 The result is that the VPN-B and VPN-C VRFs each belong to two MI- 1741 PMSIs, one for the extranet and one for the intranet. The MI-PMSI 1742 for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs. 1744 Alternatively, one could provision the VPN-A VRFs so that some UMH- 1745 eligible extranet source routes carry an RT which we will call "RT-A- 1746 to-B", and some carry an RT which we will call "RT-A-to-C". The 1747 VPN-A VRFs would be configured with both of these as Outgoing 1748 Extranet RTs. To allow an extranet flow from a VPN-A source to have 1749 both VPN-B and VPN-C receivers, the UMH-eligible route for that 1750 source would carry both RTs. VPN-B VRFs (but not VPN-C VRFs) would 1751 be provisioned with RT-A-to-B as an Incoming Extranet RT. VPN-C VRFs 1752 (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an an 1753 Incoming Extranet RT. 1755 Following the rules above, if any VPN-A extranet source is to have 1756 both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each 1757 originate two I-PMSI A-D routes, one for extranet and one for non- 1758 extranet. The single Intra-AS I-PMSI A-D route originated by the 1759 VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as 1760 well as VPN-A's non-extranet RT). The extranet I-PMSI A-D route 1761 originated from a VPN-B VRF would have RT-A-to-B, and the extranet 1762 I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C. 1764 If a given VRF contains both extranet C-receivers and extranet 1765 C-sources, the procedures described above still work, as the VRF will 1766 be configured with both Incoming Extranet RTs and Outgoing Extranet 1767 RTs; the VRF functions both as a VPN-S VRF and as a VPN-R VRF. 1769 6.2.2. S-PMSIs 1771 When PIM is used as the PE-PE C-multicast control plane, every S-PMSI 1772 is considered to be part of the "emulated LAN" that "corresponds" to 1773 a particular MI-PMSI. 1775 When the bindings of C-flows to particular S-PMSIs are announced via 1776 S-PMSI Join Messages ([RFC6513], Section 7) sent on the MI-PMSI, the 1777 S-PMSI is considered to be part of the same LAN interface as the 1778 corresponding MI-PMSI. 1780 When the bindings of C-flows to particular S-PMSIs are announced via 1781 S-PMSI A-D routes, then any S-PMSI A-D route exported from that VRF 1782 MUST have an RT in common with exactly one of the Intra-AS A-D routes 1783 exported from that VRF, and this MUST be one of the VRF's Outgoing 1784 Extranet RTs. Further, the S-PMSI A-D route MUST NOT have an RT in 1785 common with any other Intra-AS A-D route exported from a VRF on the 1786 same PE. A given S-PMSI A-D route will be considered to "correspond" 1787 to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the 1788 same PE) with which it shares an RT. 1790 The MI-PMSI that corresponds to a given S-PMSI is determined as 1791 follows: 1793 o If there is an Intra-AS I-PMSI A-D route originated by the same PE 1794 that originated the S-PMSI A-D route, and if the those two routes 1795 have an RT in common, and if that RT is one of the VRF's Incoming 1796 Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated 1797 with that Intra-AS I-PMSI A-D route. 1799 o Otherwise, if there is an Inter-AS I-PMSI A-D route originated in 1800 the same AS as the S-PMSI A-D route, and if the those two routes 1801 have an RT in common, and if that RT is one of the VRF's Incoming 1802 Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated 1803 with that Inter-AS I-PMSI A-D route. 1805 o Otherwise, there must be a configuration error (a violation of the 1806 requirements of Sections 3, 4, and 5 of this document). 1808 When wildcard S-PMSIs are used, the rules given in [RFC6625] for 1809 determining whether a given S-PMSI A-D route is a "match for 1810 reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows: 1812 A given S-PMSI A-D route MUST NOT be considered to be a "match for 1813 reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS that 1814 S-PMSI A-D route "corresponds" (as defined above) to the MI-PMSI 1815 that is the incoming interface for the given state. 1817 The rules given in [RFC6625] for determining whether a given S-PMSI 1818 A-D route is a "match for transmission" are unchanged. 1820 6.2.3. Sending PIM Control Packets 1822 Suppose a PE, say PE1, receives a PIM Join(S,G) from a CE, over a VRF 1823 interface that is associated with a VPN-R VRF. The PE does the RPF 1824 check for S by looking up S in the VPN-R VRF. The PIM C-instance 1825 associated with that VRF must determine the correct P-tunnel over 1826 which to send a PIM Join(S,G) to other PEs. 1828 To do this, PE1 finds, in the VRF associated with the interface over 1829 which the Join was received, the selected UMH route for S, following 1830 the procedures of Section 5.1 of [RFC6513]. PE1 determines the set 1831 of RTs carried by that route. PE1 then checks to see if there is an 1832 Intra-AS I-PMSI A-D route, currently originated by PE1, that has an 1833 RT in common with the selected UMH route for S. 1835 If the rules of Sections 3, 4, and 5 have been followed, each of 1836 PE1's selected UMH routes will share an RT with a single one of PE1's 1837 currently originated Intra-AS I-PMSI A-D routes. If this is so, the 1838 Join is sent on the P-tunnel advertised in the PTA of that route. 1839 Otherwise, the Join MUST NOT be sent. 1841 In essence, this procedure makes the RPF check for C-S resolve to the 1842 MI-PMSI that is serving as the next hop "interface" to C-S. 1844 If a PE receives a PIM Join(*,G) from a CE, the procedure for doing 1845 the RPF check is the same, except that the selected UMH route will be 1846 a route to the C-RP associated with the C-G group. 1848 6.2.4. Receiving PIM Control Packets 1850 When a PIM C-instance receives a PIM control message from a P-tunnel, 1851 it needs to identify the message's "incoming interface". This 1852 incoming interface is the MI-PMSI of which the P-tunnel is a part. 1854 6.2.5. Sending and Receiving Data Packets 1856 The rules for choosing the PMSI on which to send a multicast data 1857 packet are as specified in [RFC6513] and [RFC6625], with one new 1858 restriction: a VPN-S VRF always transmits a multicast data packet 1859 either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the 1860 VPN-S MI-PMSI. From the perspective of the PIM C-instance, there is 1861 only one outgoing interface. 1863 When a PIM C-instance receives a multicast data packet from a given 1864 P-tunnel, and that P-tunnel is being used to instantiate an MI-PMSI, 1865 the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and 1866 6.2.2) is considered to be the packet's "incoming interface". If the 1867 packet is received on a P-tunnel that was advertised in an S-PMSI A-D 1868 route, the packet's "incoming interface" is the MI-PMSI to which that 1869 S-PMSI route corresponds, as defined in Section 6.2.2. Ordinary PIM 1870 rules for data plane RPF check apply. 1872 Following ordinary PIM procedures, packets arriving from an 1873 unexpected incoming interface are discarded. This eliminates any 1874 problems due to the ambiguities described in Sections 2.1 and 2.2. 1876 6.3. Multiple PMSIs per C-flow Model 1878 In this model, if a VPN-S VRF has extranet multicast C-sources, and a 1879 VPN-R VRF has extranet multicast C-receivers allowed by policy to 1880 receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins 1881 the MI-PMSI that VPN-R uses for its non-extranet traffic. 1883 In the "single PMSI per C-flow" transmission model (as described in 1884 Section 6.2), a PE that needs to transmit a multicast data packet to 1885 a set of other PEs transmits the packet on a single PMSI. This means 1886 that if a packet needs to be transmitted from a VPN-A VRF and 1887 received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel 1888 from which the VPN-B and VPN-C VRFs can both receive packets. 1890 In the "multiple PMSIs per C-flow" transmission model, a PE that 1891 needs to transmit a multicast data packet to a set of other PEs may 1892 transmit the packet on several different PMSIs. (Of course, any 1893 given packet is transmitted only once on a given P-tunnel.) For 1894 example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B 1895 receiver, and a VPN-C receiver, there could be one PMSI that the 1896 VPN-A VRF uses to transmit the packet to the VPN-B VRFs, and another 1897 PMSI that the VPN-A VRF uses to transmit the packet to the VPN-C 1898 VRFs. 1900 6.3.1. Forming the MI-PMSIs 1902 Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], 1903 each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing 1904 a PMSI Tunnel Attribute (PTA) specifying the P-tunnel to be used as 1905 part of the VPN-R MI-PMSI. In the absence of extranet service, this 1906 route carries the VRF's non-extranet RT, RT-R. When extranet service 1907 is provided (using the "single PMSI per C-flow" model), this route 1908 MUST also carry each of the VRF's Incoming Extranet RTs. 1910 Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], 1911 each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing 1912 a PTA specifying the P-tunnel to be used as part of the VPN-S MI- 1913 PMSI. This route carries the VRF's non-extranet RT RT-S. When 1914 extranet service is provided using the "multiple PMSI per C-flow" 1915 model, the VPN-S VRF MUST also originate one or more additional 1916 Intra-AS I-PMSI A-D routes. It MUST originate one additional Intra- 1917 AS I-PMSI A-D route for each outgiong extranet RT with which it has 1918 been configured; each such route will have a distinct RD, and will 1919 carry exactly one of the configured Outgoing Extranet RTs. 1921 As with the "single PMSI per C-flow" transmission model, VRFs 1922 containing extranet C-receivers need to import UMH-eligible extranet 1923 C-source routes from VRFs containing C-sources. This is ensured by 1924 the rules of 3, 4, and 5. 1926 However, in the "multiple PMSIs per C-flow model", a VRF containing 1927 only C-receivers originates only a single Intra-AS I-PMSI A-D route, 1928 carrying the non-extranet RT and all the Incoming Extranet RTs. 1930 When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes 1931 that carry the non-extranet RT or one of the Incoming Extranet RTs, 1932 the P-tunnels specified in the PTA of all such routes are considered 1933 to be part of the same MI-PMSI. I.e., the associated PIM C-instance 1934 will treat them as part of a single interface. 1936 In this model, it is the VRF containing extranet C-sources that must 1937 originate multiple Intra-AS I-PMSI A-D routes. Each such route must 1938 have a distinct RD, and the set of RTs carried by any one of these 1939 routes must be disjoint from the set carried by any other. There 1940 must be one such route for each of the VRF's Outgoing Extranet RTs, 1941 and Each such route must carry exactly one of the VRF's Outgoing 1942 Extranet RTs. The VRFs containing extranet C-sources MUST also 1943 import all the A-D routes originated by the VRFs containing extranet 1944 C-receivers. If a set of originated and/or imported Intra-AS I-PMSI 1945 A-D routes have an RT in common, and that RT is one of the VRF's 1946 Outgoing Export RTs, then those routes are considered to be "about" 1947 the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI 1948 as a LAN Interface. 1950 In effect, if VPN-S has only extranet C-sources and VPN-R has only 1951 extranet C-receivers, this model has the VPN-S VRFs join the VPN-R 1952 MI-PMSI. The VPN-S VRFs will thus be attached to multiple MI-PMSIs, 1953 while the VPN-R VRFs are attached to only one. The fact that the 1954 VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM 1955 C-instance at the VPN-R VRFs. 1957 If a VPN-A VRF has extranet C-sources allowed to send to C-receivers 1958 in a VPN-B VRF, and the VPN-B VRF has C-sources allowed to send to 1959 C-receivers in the VPN-A VRF, the above procedures still work as 1960 specified. 1962 Following normal PIM procedures, when the PIM C-instance at a VRF 1963 with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G) 1964 over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the 1965 MI-PMSI over which the Join was received may be added to the set of 1966 outgoing interfaces for that multicast state. If n MI-PMSIs are 1967 added to the outgoing interface list for a particular multicast 1968 state, a multicast data packet may need to be replicated n times, and 1969 transmitted once on each of the n MI-PMSIs. 1971 Since the all multicast data packets received from another PE are 1972 received over a single emulated LAN, it is not necessary to have any 1973 special procedures to determine a packet's "incoming interface". The 1974 ambiguities described in Section 2.1 and Section 2.2 do not occur, 1975 because a VPN-R VRF can only receive multicast data traffic that has 1976 been requested by a VPN-R VRF. 1978 7. When BGP is the PE-PE C-multicast Control Plane 1980 This document assumes that if BGP is used as the PE-PE C-multicast 1981 control plane, the "Single PMSI per C-flow" model is used. 1982 Procedures for providing the "Multiple PMSIs per C-flow" model with 1983 BGP C-multicast are outside the scope of this document. 1985 When BGP is used as the C-multicast control plane, the Single PMSI 1986 per C-flow model may be used either with or without "extranet 1987 separation". (Recall that "extranet separation" means that no 1988 P-tunnel can carry both traffic from extranet sources and traffic 1989 from non-extranet sources.) In either case, the data traffic may be 1990 carried on inclusive tunnels only, or on selective tunnels only 1991 (known as the "S-PMSI only" model), or on a combination of inclusive 1992 and selective tunnels. This is determined by provisioning. The 1993 procedures specified below support all three choices. 1995 Note that there are no special extranet procedures for Inter-AS 1996 I-PMSI A-D routes or for Leaf A-D routes. 1998 7.1. Originating C-multicast Routes 2000 This section applies whether extranet separation is used or not. 2002 When it is necessary to originate a C-multicast Source Tree Join for 2003 (C-S,C-G), a PE must follow the procedures of Section 11.1.3 2004 ("Constructing the rest of the C-multicast route") of [RFC6514] to 2005 find the selected UMH route for C-S. When it is necessary to 2006 originate a C-multicast Shared Tree Join for (C-*,C-G),where C-G is 2007 an ASM group, a PE must follow the procedures of that section to find 2008 the selected UMH route for C-G's C-RP. 2010 Section 11.1.3 of [RFC6514] specifies how information from the 2011 selected UMH route is used to find an Intra-AS I-PMSI A-D route or an 2012 Inter-AS I-PMSI A-D route. Information from that I-PMSI A-D route is 2013 then used to construct part of the C-multicast route. 2015 For extranet, this specification modifies the procedures of 2016 Section 11.1.3 of [RFC6514] as follows. The rules given in 2017 Section 7.4.5 ("I-PMSI A-D Routes") of this document are used to find 2018 the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D route that 2019 "corresponds to" to the selected UMH route. (That is, the rules of 2020 Section 7.4.5 of this document replace the rules given in 2021 Section 11.1.3 of [RFC6514] for finding the Inter-AS or Intra-AS 2022 I-PMSI A-D route.) 2024 Information from this I-PMSI A-D route is then used, as specified in 2025 Section 11.1.3 of [RFC6514], to construct the C-multicast route. 2027 7.2. Originating A-D Routes Without Extranet Separation 2029 7.2.1. Intra-AS I-PMSI A-D Routes 2031 Consider a VRF, call it VRF-S, that contains extranet C-sources, and 2032 that exports UMH-eligible routes matching those C-sources. The VRF 2033 may also originate and export an Intra-AS I-PMSI A-D route. 2035 As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route 2036 is originated by and exported from VRF-S, the RTs carried by that 2037 route MUST be chosen such that every VRF that imports a UMH-eligible 2038 route from VRF-S also imports this Intra-AS I-PMSI A-D route. 2040 If inclusive P-tunnels are being used to carry extranet C-flows, 2041 there are additional requirements on the way the RTs carried by the 2042 Intra-AS I-PMSI A-D routes must be chosen, as specified in the 2043 following paragraph. 2045 If VRF-S is using inclusive P-tunnels, but is not using extranet 2046 separation, there is one inclusive P-tunnel rooted at VRF-S, and this 2047 tunnel carries both extranet and non-extranet C-flows. This 2048 inclusive tunnel is identified in the PMSI Tunnel Attribute (PTA) of 2049 the Intra-AS I-PMSI A-D route originated from VRF-S. The set of RTs 2050 carried by this Intra-AS I-PMSI A-D route MUST be chosen so as to 2051 ensure that every VRF that imports a UMH-eligible route from this 2052 VRF-S also imports this Intra-AS I-PMSI A-D route. Further, the set 2053 of RTs carried by this Intra-AS I-PMSI A-D route MUST be chosen such 2054 that it has at least one RT in common with every UMH-eligible route 2055 that is exported from the VRF. 2057 7.2.2. S-PMSI A-D Routes 2059 Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose 2060 that R-SP is used to bind some or all of the extranet C-flows from a 2061 given extranet C-source to a given selective P-tunnel. Let R-UMH be 2062 a UMH-eligible route that is exported from VRF-S and that matches the 2063 given extranet C-source. Then R-SP and R-UMH MUST have at least one 2064 RT in common. Further, the RTs carried by these two routes MUST be 2065 such that every VRF that imports R-UMH also imports R-SP. These 2066 rules apply whether or not R-SP uses wildcards [RFC6625]. 2068 An implementation MUST allow the set of RTs carried by the S-PMSI A-D 2069 routes to be specified by configuration. In the absence of such 2070 configuration, an S-PMSI A-D route originated by a given VRF X MUST 2071 carry a default set of RTs, as specified by the following rules: 2073 1. By default an S-PMSI A-D route originated by VRF X for a given 2074 (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible 2075 route originated by VRF X that matches C-S. 2077 2. By default an S-PMSI A-D route originated by VRF X for a given 2078 (C-*,C-G) carries as its RTs a set union of all RT(s) of the UMH- 2079 eligible route(s) matching the multicast C-sources contained in 2080 VRF X that could originate traffic for that C-G. Moreover, if 2081 the VRF contains (as defined in Section 1.1) the C-RP of C-G, 2082 then this set union also includes the RT(s) of the UMH-eligible 2083 route matching C-RP, and of the unicast VPN-IP route matching 2084 C-RP. 2086 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF X 2087 is to be used for both extranet and non-extranet traffic, it 2088 carries the same RTs that would be carried (as specified in 2089 Section 7.2.1) by an I-PMSI A-D route originated by VRF X if that 2090 I-PMSI A-D route were advertising an inclusive P-tunnel for 2091 carrying both extranet and non-extranet traffic. In general, a 2092 given VRF would not originate both (a) an S-PMSI A-D route 2093 advertising a (C-*,C-*) selective P-tunnel for both extranet and 2094 non-extranet traffic and (b) an I-PMSI A-D route advertising an 2095 inclusive P-tunnel for both extranet and non-extranet traffic, as 2096 the inclusive P-tunnel would not get used in that case. 2098 7.2.3. Source Active A-D Routes 2100 7.2.3.1. When Inter-Site Shared Trees Are Used 2102 This section applies when Inter-Site Shared Trees are used, as 2103 specified in [RFC6514] Section 13. 2105 If VRF-S exports a Source Active A-D route that contains C-S in the 2106 Multicast Source field of its NLRI, and if that VRF also exports a 2107 UMH-eligible route matching C-S, the Source Active A-D route MUST 2108 carry at least one RT in common with the UMH-eligible route. The RT 2109 must be chosen such that the following condition holds: if VRF-R 2110 contains an extranet C-receiver allowed by policy to receive extranet 2111 traffic from C-S, then VRF-R imports both the UMH-eligible route and 2112 the Source Active A-D route. 2114 By default, a Source Active A-D route for a given (C,S,C-G), exported 2115 by a given VRF, carries the same set of RTs as the UMH-eligible route 2116 matching C-S that is exported from that VRF. 2118 7.2.3.2. When Inter-Site Shared Trees Are Not Used 2120 This section applies when Inter-Site Shared Trees are not used, as 2121 specified in [RFC6514] Section 14. 2123 Suppose a VRF, say VRF-X, contains the C-RP for a given extranet 2124 C-group, say C-G. If C-S is an active source for C-G, then following 2125 the procedures of Section 14.1 of [RFC6514], VRF-X may export a 2126 Source Active A-D route that contains C-S in the Multicast Source 2127 field of its NLRI. This document replaces the rule for constructing 2128 the RT(s) carried by such a route, specified in Section 14.1 of 2129 [RFC6514], with the following. VRF-X MUST be configured such that 2130 the Source Active A-D route for (C-S,C-G) carries the same set of RTs 2131 as the UMH-eligible route matching C-S that is exported from the 2132 VRF(s) containing C-S. This way, if a VRF, say VRF-R, contains an 2133 extranet C-receiver allowed by policy to receive extranet traffic 2134 from C-S, then VRF-R imports both the UMH-eligible route and the 2135 Source Active A-D route. 2137 7.3. Originating A-D Routes With Extranet Separation 2139 If a VRF contains both extranet C-sources and non-extranet C-sources, 2140 it MUST be configured with both a "default RD" and an "extranet RD" 2141 (see Section 1.3). The use of these RDs is explained in the 2142 following sub-sections. 2144 7.3.1. Intra-AS I-PMSI A-D Routes 2146 This section applies when VRF-S is using extranet separation, AND 2147 when VRF-S is using an inclusive P-tunnel to carry some or all of the 2148 extranet C-flows that it needs to transmit to other VRFs. 2150 If VRF-S contains both extranet C-sources and non-extranet C-sources, 2151 and if inclusive P-tunnels are used to carry both extranet C-flows 2152 and non-extranet C-flows, then there MUST be two inclusive tunnels 2153 from VRF-S, one of which is to be used only to carry extranet C-flows 2154 (the "extranet inclusive P-tunnel"), and one of which is to be used 2155 only to carry non-extranet C-flows (the "non-extranet inclusive 2156 P-tunnel"). 2158 In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes. 2159 Their respective NLRIs must of course have different RDs. One of the 2160 Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel 2161 in its PTA. This route must have the VRF's "extranet RD" in its 2162 NLRI. The other route identifies the non-extranet inclusive P-tunnel 2163 in its PTA. This route must have the VRF's "default RD" in its PTA. 2165 If VRF-S uses an inclusive P-tunnel for carrying extranet traffic, 2166 but does not use an inclusive P-tunnel for carrying non-extranet 2167 traffic, then of course only a single Intra-AS I-PMSI A-D route need 2168 be originated. The PTA of this route identifies the "extranet 2169 inclusive P-tunnel". The NLRI of that route must contain the VRF's 2170 extranet RD. 2172 An Intra-AS I-PMSI A-D route whose PTA identifies an extranet 2173 inclusive P-tunnel MUST carry the Extranet Separation extended 2174 community defined in Section 4.5. 2176 The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies 2177 the "extranet inclusive P-tunnel" MUST be chosen such that the 2178 following condition holds: if a VRF (call it VRF-R) imports a UMH- 2179 eligible route from VRF-S, and if that route matches an extranet 2180 C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route. 2182 Note that when extranet separation is used, it is possible to use an 2183 inclusive P-tunnel for non-extranet traffic while using only 2184 selective P-tunnels for extranet traffic. It is also possible to use 2185 an inclusive P-tunnel for extranet traffic while using only selective 2186 P-tunnels for non-extranet traffic. 2188 7.3.2. S-PMSI A-D Routes 2190 Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose 2191 that R-SP is used to bind some or all of the extranet C-flows from a 2192 given extranet C-source to a given selective P-tunnel. Let R-UMH be 2193 a UMH-eligible route that is exported from VRF-S and that matches the 2194 given extranet C-source. Then R-SP and R-UMH MUST have at least one 2195 RT in common. Further, the RTs carried by these two routes MUST be 2196 such that every VRF that imports R-UMH also imports R-SP. These 2197 rules apply whether or not R-SP uses wildcards [RFC6625]. 2199 The following rules, specific to the use of extranet separation, 2200 apply: 2202 o A selective P-tunnel MUST NOT carry C-flows from both extranet and 2203 non-extranet C-sources, 2205 o If it is desired to use a (C-*,C-*) S-PMSI to carry extranet 2206 traffic and also to use a (C-*,C-*) S-PMSI to carry non-extranet 2207 traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated. 2208 These two routes MUST have different RDs in their respective NLRI 2209 fields, and their respective PTAs MUST identify different 2210 P-tunnels. If the route advertises a P-tunnel that carries only 2211 non-extranet traffic, the route's NLRI MUST contain the VRF's 2212 default RD. If the route advertises a P-tunnel that carries only 2213 extranet traffic, the route's NLRI MUST contain the VRF's extranet 2214 RD. 2216 o In the following cases, an S-PMSI A-D route exported from the VRF 2217 MUST have the VRF's extranet RD in its NLRI: 2219 * The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D 2220 route, and C-S is an extranet C-source. 2222 * The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G 2223 is an extranet C-group. 2225 In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI 2226 A-D route MUST have the VRF's default RD in its NLRI. 2228 o A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used 2229 to carry extranet traffic MUST carry the Extranet Separation 2230 extended community defined in Section 4.5. 2232 An implementation MUST allow the set of RTs carried by the S-PMSI A-D 2233 routes to be specified by configuration. In the absence of such 2234 configuration, an S-PMSI A-D route originated by a given VRF X MUST 2235 carry a default set of RTs, as specified by the following rules: 2237 1. Rule 1 of Section 7.2.2 applies. 2239 2. By default, if C-G is an extranet C-group, rule 2 of 2240 Section 7.2.2 applies. 2242 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF X 2243 is to be used for extranet traffic, it carries the same RTs that 2244 would be carried (as specified in Section 7.3.1) by an I-PMSI A-D 2245 route originated by VRF X if that I-PMSI A-D route were 2246 advertising an inclusive P-tunnel for carrying extranet traffic. 2247 In general, a given VRF would not originate both an S-PMSI A-D 2248 route advertising a (C-*,C-*) selective P-tunnel for extranet 2249 traffic and an I-PMSI A-D route advertising an inclusive P-tunnel 2250 for extranet traffic, as the inclusive P-tunnel would not get 2251 used in that case. 2253 7.3.3. Source Active A-D Routes 2255 The procedures of Section 7.2.3 apply. 2257 However, if a Source Active A-D route is exported from a given VRF, 2258 and the route contains C-S, where C-S is an extranet C-source, then 2259 the RD of the route's NLRI MUST be the extranet RD of the VRF. 2260 Otherwise the RD is the default RD of the VRF. 2262 7.4. Determining the Expected P-tunnel for a C-flow 2264 This section applies whether extranet separation is used or not. 2266 In the context of a VRF with receivers for a particular C-flow, a PE 2267 must determine the P-tunnel over which packets of that C-flow are 2268 expected to arrive. This is done by finding an I-PMSI or S-PMSI A-D 2269 route that "matches" the flow. The matching A-D route will contain a 2270 PTA that specifies the P-tunnel being used to carry the traffic of 2271 that C-flow. We will refer to this P-tunnel as the "expected 2272 P-tunnel" for the C-flow. (Note that, per [MVPN-IR], if the PTA 2273 specifies an tunnel of type "Ingress Replication" (IR), the 2274 identifier of the P-tunnel is actually the NLRI of the I-PMSI or 2275 S-PMSI A-D route. If the PTA specifies a tunnel type other than IR, 2276 the identifier of the P-tunnel is found in the "tunnel identifier" 2277 field of the PTA.) 2278 A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST 2279 join the expected P-tunnel for that C-flow, and the PE MUST remain 2280 joined to the P-tunnel as long as the PE continues to need to receive 2281 the given C-flow, and the P-tunnel continues to remain the expected 2282 P-tunnel for that C-flow. Procedures for joining and leaving a 2283 tunnel depend, of course, on the tunnel type. 2285 If a PTA specifies a non-zero MPLS label for a tunnel that is not an 2286 IR tunnel, then the PE originating the A-D route containing that PTA 2287 is advertising an aggregate P-tunnel. The aggregate P-tunnel can be 2288 thought of as an outer P-tunnel multiplexing some number of inner 2289 P-tunnels. The inner P-tunnels are demultiplexed by means of the 2290 MPLS label in the PTA. In this document, when we talk of the 2291 "expected P-tunnel" in the context of an aggregate P-tunnel, we refer 2292 to a particular inner P-tunnel, not to the outer P-tunnel. It is 2293 this "inner P-tunnel" that is the expected P-tunnel for a given 2294 C-flow. 2296 In order to find the expected P-tunnel for a given C-flow, the 2297 upstream PE of the C-flow is first determined. Then the S-PMSI A-D 2298 routes originated by that PE are examined, and their NLRIs compared 2299 to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for 2300 reception". (If there is no S-PMSI A-D route that matches a given 2301 C-flow, the expected P-tunnel for that C-flow may have been 2302 advertised in an I-PMSI A-D route; see Section 7.4.5.) 2304 The rules for determining, in non-extranet cases, whether a given 2305 C-flow is a "match for reception" for a given S-PMSI A-D route are 2306 given in [RFC6625] Section 3.2. Note that we use the terms 2307 "installed" and "originated" as they are defined in [RFC6625] 2308 Section 3.2. (See also Section 1.1 of this document.) 2310 This specification adds additional rules for determining whether a 2311 given S-PMSI A-D route is a "match for reception" for a given (C-S/ 2312 C-RP,C-G). Note that these rules all assume the context of a 2313 particular VRF into which the A-D route has been imported. 2315 The rules given in [RFC6625] for determining whether a given S-PMSI 2316 A-D route is a "match for transmission" remain unchanged. 2318 Suppose a PE has originated a C-multicast Shared Tree Join for 2319 (C-*,C-G), has not originated a C-multicast Source Tree Join for 2320 (C-S,C-G), but has received and installed a Source Active A-D route 2321 for (C-S,C-G). As described in Section 13.2 of [RFC6514], the PE 2322 must receive the (C-S,C-G) traffic from the tunnel the originator of 2323 the installed Source Active A-D route uses for sending (C-S,C-G). 2325 The originator of the installed Source Active A-D route is determined 2326 as follows: 2328 1. Look at the "UMH Route Candidate Set" for C-S, as defined in 2329 [RFC6513] Section 5.1.3. 2331 2. From that set select a subset of UMH routes to C-S, such that 2332 each route in the subset has at least one RT in common with the 2333 Source Active A-D route, and at least one of the RTs in common is 2334 an import RT of the VRF. 2336 3. From that subset, find the route whose RD is the same as the RD 2337 from the NLRI of the Source Active A-D route. 2339 4. The Upstream PE is the PE identified in the VRF Route Import 2340 Extended Community of that route. 2342 5. The Upstream AS is the AS identified in the Source AS Extended 2343 Community of that route. 2345 If the result of step 2 is an empty set, or if step 3 fails to find a 2346 route, then the Upstream PE of the Source Active A-D route cannot be 2347 determined, and it is necessary to act as if the Source Active A-D 2348 route had not been installed. (A subsequent change to the UMH Route 2349 Candidate Set for C-S may require that a new attempt be made to 2350 determine the Upstream PE.) 2352 Once the upstream PE is determined, the P-tunnel over which the flow 2353 is expected is determined according to the procedures already 2354 described in this section. 2356 7.4.1. (C-S,C-G) S-PMSI A-D Routes 2358 When extranet functionality is being provided, an S-PMSI A-D route 2359 whose NLRI contains (C-S,C-G) is NOT considered to be a "match for 2360 reception" for a given C-flow (C-S,C-G) unless one of the following 2361 conditions holds (in addition to the conditions specified in 2362 [RFC6625]): 2364 o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is 2365 provisioned, or 2367 o the selected UMH route for C-S has at least one RT in common with 2368 the S-PMSI A-D route, and at least one of the common RTs is an 2369 import RT of the VRF. 2371 7.4.2. (C-S,C-*) S-PMSI A-D Routes 2373 When extranet functionality is being provided, an S-PMSI A-D route 2374 whose NLRI contains (C-S,C-*) is NOT considered to be a "match for 2375 reception" for a given C-flow (C-S,C-G) unless one of the following 2376 conditions holds, in addition to the conditions specified in 2377 [RFC6625]: 2379 o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is 2380 provisioned, or 2382 o the selected UMH route for C-S has at least one RT in common with 2383 the S-PMSI A-D route, and at least one of the common RTs is an 2384 import RT of the VRF. 2386 7.4.3. (C-*,C-G) S-PMSI A-D Routes 2388 When extranet functionality is being provided, an S-PMSI A-D route 2389 whose NLRI contains (C-*,C-G) is NOT considered to be a "match for 2390 reception" for a given C-flow (C-S,C-G) in a given VRF unless either 2391 condition 1 or condition 2 below holds, in addition to the conditions 2392 specified in [RFC6625]: 2394 1. The given VRF has currently originated a C-multicast Shared Tree 2395 Join route for (C-*,C-G), and 2397 a. (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route 2398 (according to [RFC6625]) in the given VRF, and 2400 b. either 2402 i. the "Single C-group per (C-*,C-G) P-tunnel" policy has 2403 been provisioned, or 2405 ii. the RTs of that S-PMSI A-D route form a non-empty 2406 intersection with the RTs carried in the VRF's 2407 selected UMH route for C-RP of that C-G, or 2409 iii. installed in the VRF is at least one (C-S,C-G) Source 2410 Active A-D route that was originated by the same PE as 2411 the (C-*,C-G) S-PMSI A-D route. 2413 2. The given VRF does not have a currently originated C-multicast 2414 Shared Tree Join for (C-*,C-G), but 2416 a. there are one or more values for C-S for which the VRF has a 2417 currently originated Source Tree Join C-multicast route for 2418 (C-S,C-G), and 2420 b. the (C-* C-G) S-PMSI A-D route matches (according to 2421 [RFC6625]) each such (C-S,C-G), and 2423 c. either 2425 i. the "Single C-group per (C-*,C-G) P-tunnel" policy has 2426 been provisioned, or 2428 ii. the RTs of that S-PMSI A-D route form a non-empty 2429 intersection with the RTs carried in the VRF's selected 2430 UMH routes for each such C-S 2432 If a VRF has an installed (C-*,C-G) S-PMSI A-D route, but does 2433 not have a (C-S,C-G) or (C-*,C-G) multicast state that matches 2434 that route for reception, the procedures of Section 12.3 2435 ("Receiving S-PMSI A-D Routes by PEs") of [RFC6514] are not 2436 invoked for that route. If those multicast states are created at 2437 some later time when the route is still installed, the procedures 2438 of Section 12.3 of [RFC6514] are invoked at that time. 2440 7.4.4. (C-*,C-*) S-PMSI A-D Routes 2442 A (C-*,C-*) S-PMSI A-D Route (call it "R-AD") is NOT considered to be 2443 a match for reception for a given C-flow (C-S,C-G) or (C-*,C-G) 2444 unless the following conditions hold (in addition to the conditions 2445 specified in [RFC6625]: 2447 o the selected UMH route (call it "R-UMH") for C-S or for C-G's C-RP 2448 respectively has at least one RT in common with R-AD, and at least 2449 one of the common RTs is an import RT of the VRF. 2451 o either R-AD and R-UMH both carry the Extranet Separation extended 2452 community, or neither carries the Extranet Separation extended 2453 community. 2455 7.4.5. I-PMSI A-D Routes 2457 If a particular egress VRF in a particular egress PE contains no 2458 matching S-PMSI A-D routes for a particulalr C-flow, then the C-flow 2459 is expected to arrive (at that egress VRF) on an inclusive P-tunnel. 2461 Suppose that an egress PE has originated a (C-S,C-G) C-Multicast 2462 Source Tree Join. Let R-UMH be the selected UMH route (in the given 2463 egress VRF) or C-S. As specified in [RFC6514], the selected upstream 2464 PE for (C-S,C-G) is determined from the VRF Route Import RT of R-UMH, 2465 and the "selected upstream AS" for the flow is determined from the 2466 Source AS Extended Community of R-UMH. 2468 Suppose that an egress PE has originated a (C-*,C-G) C-Multicast 2469 Shared Tree Join, but has not originated a (C-S,C-G) C-Multicast 2470 Source Tree Join. If the egress VRF does not have a (C-S,C-G) Source 2471 Active A-D route installed, the selected upstream PE is determined 2472 from the VRF Route Import EC of the installed UMH-eligible route 2473 matching C-RP, where C-RP is the RP for the group C-G. The selected 2474 upstream AS for the flow is detemined from the Source AS EC of that 2475 route. If the egress VRF does have a (C-S,C-G) Source Active A-D 2476 route installed, the selected upstream PE and upstream AS are 2477 determined as specified in Section 7.4. In either case, let R-UMH be 2478 the installed UMH-eligible route matching C-S. 2480 The inclusive P-tunnel that is expected to be carrying a particular 2481 C-flow is found as follows: 2483 o If the selected upstream AS is the local AS, or if segmented 2484 Inter-AS P-tunnels are not being used to instantiate I-PMSIs, then 2485 look in the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, 2486 such that (a) R-AD originated by the selected upstream PE, (b) 2487 R-AD has at least one an RT in common with R-UMH, (c) at least one 2488 of the common RTs is an import RT of the local VRF, and (d) either 2489 R-AD and R-UMH both carry the Extranet Separation extended 2490 community, or neither carries the Extranet Separation extended 2491 community. 2493 The PTA of R-AD specifies the P-tunnel over which traffic of the 2494 given C-flow is expected. 2496 o If the selected upstream AS is not the local AS, and if segmented 2497 Inter-AS P-tunnels are being used to instantiate I-PMSIs, then 2498 look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD, 2499 such that (a) the Source AS field of R-AD's NLRI contains the AS 2500 number of the selected upstream AS, (b) R-AD has at least one RT 2501 in common with R-UMH, (c) at least one of the common RTs is an 2502 import RT of the local VRF, and (d) either R-AD and R-UMH both 2503 carry the Extranet Separation extended community, or neither 2504 carries the Extranet Separation extended community. 2506 The PTA of R-AD specifies the P-tunnel over which traffic of the 2507 given C-flow is expected. 2509 7.5. Packets Arriving from the Wrong P-tunnel 2511 Any packets that arrive on a P-tunnel other than the expected 2512 P-tunnel (as defined in Section 7.4) MUST be discarded, unless it is 2513 know that all the packets carried by both P-tunnels are from the same 2514 ingress VRF. (See Section 2.3.1 for a more detailed discussion of 2515 when to discard packets from other than the expected P-tunnel.) Note 2516 that packets arriving on the wrong P-tunnel are to be discarded even 2517 if they are arriving from the expected PE. 2519 8. Multiple Extranet VRFs on the same PE 2521 When multiple VRFs that contain extranet receivers for a given 2522 extranet source are present on the same PE, this PE becomes a single 2523 leaf of the P-tunnel used for sending (multicast) traffic from that 2524 source to these extranet receivers. The PE MUST be able to replicate 2525 this traffic to the multiple VRFs. Specific procedures for doing so 2526 are local to the PE, and outside the scope of this document. 2528 Two or more VRFs on the same PE may import the same S-PMSI A-D route. 2529 If this S-PMSI A-D route contains a PTA that has its "Leaf Info 2530 Required" bit set, it may be necessary for the PE to originate a Leaf 2531 A-D route whose NLRI is computed from the NLRI of the S-PMSI A-D 2532 route. (Details are in [RFC6514].) Note that for a given S-PMSI A-D 2533 route, the PE can originate only one corresponding Leaf A-D route, 2534 even if the S-PMSI A-D route is imported into multiple VRFs. This 2535 Leaf A-D route can thus be thought of as originating from several 2536 VRFs. It MUST NOT be withdrawn by the PE until there are no longer 2537 any VRFs originating it. 2539 [RFC6514] specifies conditions under which a PE originates a 2540 C-Multicast Source Tree Join or a C-Multicast Shared Tree Join, based 2541 on the (*,G) and (S,G) states associated with a given VRF. It also 2542 specifies the procedure for computing the NLRI of each such route. 2543 While a given PE may contain two or more VRFs that have (extranet) 2544 receivers for the same extranet C-flow, the PE cannot originate more 2545 than one BGP route with a given NLRI. If there are multiple VRFs, 2546 each of which has state that is sufficient to cause a given 2547 C-multicast route to be originated, the route can be thought of as 2548 originating from several VRFs. It MUST NOT be withdrawn by the PE 2549 until there is no longer any VRF with multicast state sufficient to 2550 cause the route to be originated. 2552 For a given extranet the site(s) that contain the extranet source(s) 2553 and the site(s) that contain the extranet receiver(s) may be 2554 connected to the same PE. In this scenario, the procedures by which 2555 (multicast) traffic from these sources is delivered to these 2556 receivers is a local matter to the PE, and outside the scope of this 2557 document. 2559 An implementation MUST support multiple extranet VRFs on a PE. 2561 9. IANA Considerations 2563 IANA is requested to allocate two new codepoints from the "Transitive 2564 Opaque Extended Community Sub-Types" Registry: 2566 o A codepoint for "Extranet Source Extended Community" 2568 o A codepoint for "Extranet Separation Extended Community" 2570 10. Security Considerations 2572 The security considerations of [RFC6513] and [RFC6514] are 2573 applicable. 2575 In general, different VPNs are allowed to have overlapping IP address 2576 spaces, i.e., a host in one VPN may have the same IP address as a 2577 host in another. This is safe because the customer routes from a 2578 given VPN do not pass into other VPNs. Even if there is overlapping 2579 address space among VPNs, the routes that are known at any given VPN 2580 site are unambiguous, as long as the address space of that VPN is 2581 unambiguous. However, this is not necessarily true when extranet 2582 service is provided. If an extranet C-receiver in VPN-R is to be 2583 able to receive multicast traffic from an extranet C-source in VPN-S, 2584 then the address of the VPN-S extranet C-source must be imported into 2585 one or more VPN-R VRFs. If that address is also the address of a 2586 VPN-R non-extranet C-source, then a system attempting to receive an 2587 extranet C-flow from the VPN-R extranet C-source may instead receive 2588 a non-extranet C-flow from the VPN-S C-source. This would result in 2589 a VPN security violation. 2591 To avoid this, this document specifies that if a route is imported 2592 into a given VRF, all addresses that are match that route must be 2593 unambiguous in the context of that VRF. Improper provisioning of the 2594 RTs may cause this rule to be violated, and hence result in a VPN 2595 security violation. 2597 It is possible that a given multicast C-source is the source of 2598 multiple flows, some of which are intended to be extranet C-flows, 2599 and some of which are intended to be non-extranet flows. However, 2600 the procedures of this document will allow any C-receiver that is 2601 able to receive the extranet C-flows from a given C-source to also 2602 receive the non-extranet C-flows from that source. As a result, VPN 2603 security violations may result if any system is a C-source for both 2604 extranet and non-extranet C-flows. However, the set of C-flows 2605 transmitted by a given C-source is not under the control of the SP. 2606 SPs who offer the extranet MVPN service must make sure that this 2607 potential for VPN security violations is clearly understood by the 2608 customers who administer the C-sources. 2610 This specification does not require that UMH-eligible routes be "host 2611 routes"; they may be less specific routes. So it is possible for the 2612 NLRI of a UMH-eligible route to contain an address prefix that 2613 matches the address of both an extranet C-source and a non-extranet 2614 C-source. If such a route is exported from a VPN-S VRF and imported 2615 by a VPN-R VRF, C-receivers contained in VPN-R will be able to 2616 receive C-flows from the non-extranet C-sources whose addresses match 2617 that route. This may result in VPN security violations. Service 2618 providers who offer the extranet MVPN service must make sure that 2619 this is clearly understood by the customers who administer the 2620 distribution of routes from CE to PE routers. 2622 If the address ambiguities described in Sections 2.1 and 2.2 are not 2623 prohibited by policy, VRFs MUST be able to discard traffic that 2624 arrives on the wrong P-tunnel; otherwise VPN security violations may 2625 occur. 2627 Section 4.4 specifies the OPTIONAL use of a new extended community, 2628 the Extranet Source extended community. Security considerations 2629 regarding the use and distribution of that extended community are 2630 discussed in that section. 2632 11. Acknowledgments 2634 The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini 2635 Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt 2636 Windisch for their contributions to this work. 2638 We also wish to thank Lizhong Jin and Rishabh Parekh for their 2639 reviews and comments. 2641 Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and 2642 for providing the ascii art appearing in Section 2. 2644 12. Contributor Addresses 2646 Below is a list of other contributing authors in alphabetical order: 2648 Wim Henderickx 2649 Alcatel-Lucent 2650 Copernicuslaan 50 2651 Antwerp 2018 2652 Belgium 2654 Email: wim.henderickx@alcatel-lucent.com 2656 Praveen Muley 2657 Alcatel-Lucent 2659 Email: Praveen.Muley@alcatel-lucent.com 2661 Ray Qiu 2662 Juniper Networks, Inc. 2663 1194 North Mathilda Avenue 2664 Sunnyvale, CA 94089 2665 United States 2667 Email: rqiu@juniper.net 2669 IJsbrand Wijnands 2670 Cisco Systems, Inc. 2671 De Kleetlaan 6a 2672 Diegem 1831 2673 Belgium 2675 Email: ice@cisco.com 2677 13. References 2679 13.1. Normative References 2681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2682 Requirement Levels", BCP 14, RFC 2119, March 1997. 2684 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2685 Networks (VPNs)", RFC 4364, February 2006. 2687 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 2688 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 2689 Protocol Specification (Revised)", RFC 4601, August 2006. 2691 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 2692 VPNs", RFC 6513, February 2012. 2694 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 2695 Encodings and Procedures for Multicast in MPLS/BGP IP 2696 VPNs", RFC 6514, February 2012. 2698 [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, 2699 "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 2700 6625, May 2012. 2702 13.2. Informative References 2704 [MVPN-IR] Rosen, E., Subramanian, K., and Z. Zhang, "Ingress 2705 Replication Tunnels in Multicast VPN", internet-draft 2706 draft-ietf-bess-ir-01, May 2015. 2708 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 2709 Rendevous Point (RP) mechanism using Protocol Independent 2710 Multicast (PIM) and Multicast Source Discovery Protocol 2711 (MSDP)", RFC 3446, January 2003. 2713 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 2714 Protocol (MSDP)", RFC 3618, October 2003. 2716 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 2717 Independent Multicast (PIM)", RFC 4610, August 2006. 2719 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 2720 "Extensions to Resource Reservation Protocol - Traffic 2721 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 2722 Switched Paths (LSPs)", RFC 4875, May 2007. 2724 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 2725 "Bidirectional Protocol Independent Multicast (BIDIR- 2726 PIM)", RFC 5015, October 2007. 2728 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 2729 "Bootstrap Router (BSR) Mechanism for Protocol Independent 2730 Multicast (PIM)", RFC 5059, January 2008. 2732 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 2733 "Label Distribution Protocol Extensions for Point-to- 2734 Multipoint and Multipoint-to-Multipoint Label Switched 2735 Paths", RFC 6388, November 2011. 2737 Authors' Addresses 2738 Yakov Rekhter (editor) 2739 Juniper Networks, Inc. 2740 1194 North Mathilda Avenue 2741 Sunnyvale, CA 94089 2742 United States 2744 Eric C. Rosen (editor) 2745 Juniper Networks, Inc. 2746 10 Technology Park Drive 2747 Westford, Massachusetts 01886 2748 United States 2750 Email: erosen@juniper.net 2752 Rahul Aggarwal 2753 Arktan 2755 Email: raggarwa_1@yahoo.com 2757 Yiqun Cai 2758 Microsoft 2759 1065 La Avenida 2760 Mountain View, CA 94043 2761 United States 2763 Email: yiqunc@microsoft.com 2765 Thomas Morin 2766 Orange 2767 2 Avenue Pierre-Marzin 2768 22307 Lannion Cedex 2769 France 2771 Email: thomas.morin@orange.com