diff options
Diffstat (limited to 'doc/rfc/rfc7900.txt')
| -rw-r--r-- | doc/rfc/rfc7900.txt | 3643 |
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc7900.txt b/doc/rfc/rfc7900.txt new file mode 100644 index 0000000..2a6b8cd --- /dev/null +++ b/doc/rfc/rfc7900.txt @@ -0,0 +1,3643 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Rekhter, Ed. +Request for Comments: 7900 E. Rosen, Ed. +Updates: 6513, 6514, 6625 Juniper Networks, Inc. +Category: Standards Track R. Aggarwal +ISSN: 2070-1721 Arktan + Y. Cai + Alibaba Group + T. Morin + Orange + June 2016 + + + Extranet Multicast in BGP/IP MPLS VPNs + +Abstract + + Previous RFCs specify the procedures necessary to allow IP multicast + traffic to travel from one site to another within a BGP/MPLS IP VPN + (Virtual Private Network). However, it is sometimes desirable to + allow multicast traffic whose source is in one VPN to be received by + systems that are in another VPN. This is known as a "Multicast VPN + (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by + specifying the procedures that are necessary in order to provide + extranet MVPN service. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7900. + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 1] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................4 + 1.2. Scope ......................................................7 + 1.2.1. Customer Multicast Control Protocols ................7 + 1.2.2. Provider Multicast Control Protocols ................7 + 1.3. Clarification on Use of Route Distinguishers ...............8 + 1.4. Overview ...................................................9 + 2. Extranets and Overlapping Address Spaces .......................12 + 2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows ......14 + 2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows ..........16 + 2.3. Preventing Misdelivery in These Scenarios .................18 + 2.3.1. Do Not Deliver Packets from the Wrong P-tunnel .....18 + 2.3.2. Policies to Prevent Ambiguity on a P-Tunnel ........20 + 3. Extranet Transmission Models ...................................21 + 3.1. Transmitting an Extranet C-Flow on a Single PMSI ..........21 + 3.1.1. Without Extranet Separation ........................22 + 3.1.2. With Extranet Separation ...........................22 + 3.2. Transmitting an Extranet C-Flow over Multiple PMSIs .......23 + 4. Distribution of Routes That Match C-S/C-RP Addresses ...........23 + 4.1. UMH-Eligible Routes .......................................23 + 4.1.1. Extranet Separation ................................24 + 4.2. Distribution of Unicast Routes Matching C-RPs and DRs .....25 + 4.3. Route Targets and Ambiguous UMH-Eligible Routes ...........26 + 4.4. Dynamically Marking Extranet Routes .......................27 + 4.4.1. The Extranet Source Extended Community .............27 + 4.4.2. Distribution of Extranet Source Extended + Community ..........................................29 + 4.5. The Extranet Separation Extended Community ................30 + + + + + + +Rekhter, et al. Standards Track [Page 2] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + 5. Origination and Distribution of BGP A-D Routes .................30 + 5.1. Route Targets of UMH-Eligible Routes and A-D Routes .......30 + 5.2. Considerations for Particular Inclusive Tunnel Types ......33 + 5.2.1. RSVP-TE P2MP or Ingress Replication ................33 + 5.2.2. Ingress Replication ................................34 + 6. When PIM Is the PE-PE C-Multicast Control Plane ................35 + 6.1. Provisioning VRFs with RTs ................................36 + 6.1.1. Incoming and Outgoing Extranet RTs .................36 + 6.1.2. UMH-Eligible Routes and RTs ........................37 + 6.1.3. PIM C-Instance Reverse Path Forwarding + Determination ......................................37 + 6.2. "Single PMSI per C-Flow" Model ............................38 + 6.2.1. Forming the MI-PMSIs ...............................38 + 6.2.2. S-PMSIs ............................................41 + 6.2.3. Sending PIM Control Packets ........................42 + 6.2.4. Receiving PIM Control Packets ......................43 + 6.2.5. Sending and Receiving Data Packets .................43 + 6.3. "Multiple PMSIs per C-Flow" Model .........................43 + 6.3.1. Forming the MI-PMSIs ...............................44 + 7. When BGP Is the PE-PE C-Multicast Control Plane ................46 + 7.1. Originating C-Multicast Routes ............................46 + 7.2. Originating A-D Routes without Extranet Separation ........47 + 7.2.1. Intra-AS I-PMSI A-D Routes .........................47 + 7.2.2. S-PMSI A-D Routes ..................................47 + 7.2.3. Source Active A-D Routes ...........................48 + 7.2.3.1. When Inter-Site Shared Trees Are Used .....48 + 7.2.3.2. When Inter-Site Shared Trees Are + Not Used ..................................49 + 7.3. Originating A-D Routes with Extranet Separation ...........49 + 7.3.1. Intra-AS I-PMSI A-D Routes .........................49 + 7.3.2. S-PMSI A-D Routes ..................................50 + 7.3.3. Source Active A-D Routes ...........................52 + 7.4. Determining the Expected P-Tunnel for a C-Flow ............52 + 7.4.1. (C-S,C-G) S-PMSI A-D Routes ........................54 + 7.4.2. (C-S,C-*) S-PMSI A-D Routes ........................54 + 7.4.3. (C-*,C-G) S-PMSI A-D Routes ........................55 + 7.4.4. (C-*,C-*) S-PMSI A-D Routes ........................56 + 7.4.5. I-PMSI A-D Routes ..................................56 + 7.5. Packets Arriving from the Wrong P-Tunnel ..................57 + 8. Multiple Extranet VRFs on the Same PE ..........................57 + 9. IANA Considerations ............................................58 + 10. Security Considerations .......................................59 + 11. References ....................................................61 + 11.1. Normative References .....................................61 + 11.2. Informative References ...................................62 + Acknowledgments ...................................................64 + Contributors ......................................................64 + Authors' Addresses ................................................65 + + + +Rekhter, et al. Standards Track [Page 3] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +1. Introduction + + Previous RFCs [RFC6513] [RFC6514] specify the procedures necessary to + allow IP multicast traffic to travel from one site to another within + a BGP/MPLS IP VPN (Virtual Private Network). However, it is + sometimes desirable to allow multicast traffic whose source is in one + VPN to be received by systems that are in another VPN. This is known + as an "extranet Multicast VPN (MVPN)". This document specifies the + procedures that are necessary in order to provide extranet MVPN + functionality. + + This document updates RFCs 6513, 6514, and 6625 by specifying the + procedures that are necessary in order to provide extranet MVPN + service. + +1.1. Terminology + + This document uses terminology from [RFC6513] and in particular uses + the prefixes "C-" and "P-" as specified in Section 3.1 of [RFC6513], + and "A-D routes" for "auto-discovery routes". + + The term "Upstream Multicast Hop" (UMH) is used as defined in + [RFC6513]. + + The term "UMH-eligible route" is used to mean "route eligible for UMH + determination", as defined in Section 5.1.1 of [RFC6513]. We will + say that a given UMH-eligible route or unicast route "matches" a + given IP address, in the context of a given Virtual Routing and + Forwarding table (VRF), if the address prefix of the given route is + the longest match in that VRF for the given IP address. We will + sometimes say that a route "matches" a particular host if the route + matches an IP address of the host. + + We follow the terminology of Section 3.2 of [RFC6625] when talking of + a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route + being "installed". That is, we say that an S-PMSI A-D route is + "installed" (in a given VRF) if it has been selected by the BGP + decision process as the preferred route for its Network Layer + Reachability Information (NLRI). We also follow the terminology of + Section 3.2 of [RFC6625] when saying that an S-PMSI A-D route has + been "originated by a given PE"; this means that the given Provider + Edge's (PE's) IP address is contained in the Originating Router's IP + Address field in the NLRI of the route. + + + + + + + + +Rekhter, et al. Standards Track [Page 4] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + We use the following additional terminology and notation: + + o Extranet C-source: a multicast source, in a given VPN, that is + allowed by policy to send multicast traffic to receivers that are + in other VPNs. + + o Extranet C-receiver: a multicast receiver, in a given VPN, that is + allowed by policy to receive multicast traffic from extranet + C-sources that are in other VPNs. + + o Extranet C-flow: a multicast flow (with a specified C-source + address and C-group address) with the following properties: its + source is an extranet C-source, and it is allowed by policy to + have extranet C-receivers. + + o Extranet C-group: a multicast group address that is in the + "Any-Source Multicast" (ASM) group address range and that is + allowed by policy to have extranet C-sources and extranet + C-receivers that are not all in the same VPN. Note that we will + sometimes refer to "Source-Specific Multicast (SSM) C-group + addresses" (i.e., C-group addresses in the SSM group address + range) but will never call them "extranet C-groups". + + N.B.: Any source of traffic for an extranet C-group is considered + to be an extranet C-source, and any receiver of traffic addressed + to an extranet C-group is considered to be an extranet C-receiver. + + o Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet + C-group; it is allowed by policy to receive PIM Register messages + [RFC7761] from outside its VPN and to send multicast data packets + to extranet C-receivers outside its VPN. + + o Host(C-S,A): the host (or, if C-S is an "anycast address", the set + of hosts) denoted by the address C-S in the context of VPN-A. For + example, if a particular C-source in VPN-A has address C-S, then + Host(C-S,A) refers to that C-source. + + o "SAFI n" route: a BGP route whose Address Family Identifier (AFI) + is either 1 (IPv4) or 2 (IPv6) and whose Subsequent Address Family + Identifier (SAFI) is "n". + + o PTA: PMSI Tunnel Attribute [RFC6514]. + + + + + + + + + +Rekhter, et al. Standards Track [Page 5] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Note that a given extranet C-source is not necessarily allowed to + transmit to every extranet C-receiver; policy determines which + extranet C-sources are allowed to transmit to which extranet + C-receivers. However, in the case of an extranet (ASM) C-group, all + transmitters to the group are allowed to transmit to all the + receivers of the group, and all the receivers of the group are + allowed to receive from all transmitters to the group. + + We say that a given VRF "contains" or "has" a multicast C-source (or + that the C-source is "in" the VRF) if that C-source is in a site + connected to that VRF and the VRF originates a UMH-eligible route + (see Section 4) that matches the address of the C-source. + + We say that a given VRF "contains" or "has" a multicast C-receiver + (or that the C-receiver is "in" the VRF) if that C-receiver is in a + site connected to that VRF. + + We say that a given VRF "contains" or "has" the C-RP for a given ASM + group (or that the C-RP is "in" the VRF) if that C-RP is in a site + connected to that VRF and the VRF originates a unicast route and a + (possibly different, possibly the same) UMH-eligible route (see + Section 4) whose respective address prefixes match the C-RP address. + + [RFC6513] allows a set of "P-tunnels" (defined in Section 3.2 of + [RFC6513]) to be aggregated together and transported via an outer + P-tunnel; i.e., it allows for the use of hierarchical Label Switched + Paths (LSPs) as P-tunnels. A two-level hierarchical LSP, for + example, can be thought of as a set of "inner tunnels" aggregated + into an outer tunnel. In this document, when we speak of a P-tunnel, + we are always speaking of the innermost P-tunnel, i.e., of a P-tunnel + at the lowest hierarchical level. P-tunnels are identified in the + PMSI Tunnel attributes ("PTAs" in this document) [RFC6514] of BGP + auto-discovery (A-D) routes. Two PTAs that have the same Tunnel Type + and Tunnel Identifier fields but different MPLS label fields are thus + considered to identify two different P-tunnels. (That is, for the + purposes of this document, the MPLS label included in the PTA, if + any, is considered to be part of the tunnel identifier.) + + We say that the NLRI of a BGP S-PMSI A-D route or Source Active A-D + route contains (C-S,C-G) if its Multicast Source field contains C-S + and its Multicast Group field contains C-G. If either or both of + these fields are encoded as a wildcard, we will say that the NLRI + contains (C-*,C-*) (both fields encoded as wildcards), (C-*,C-G) + (Multicast Source field encoded as a wildcard), or (C-S,C-*) + (Multicast Group field encoded as a wildcard). + + + + + + +Rekhter, et al. Standards Track [Page 6] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + We use the term "VPN security violation" to refer to any situation in + which a packet is delivered to a particular VPN, even though, by + policy, it should not be delivered to that VPN. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +1.2. Scope + +1.2.1. Customer Multicast Control Protocols + + This document presumes that the VPN customer is using PIM - Sparse + Mode (PIM-SM) [RFC7761] as the multicast control protocol at the + customer sites. PIM-SM may be used in either the ASM service model + or the SSM service model; this document covers both cases. Support + for other customer IP multicast control protocols (e.g., [RFC5015], + PIM - Dense Mode) is outside the scope of this document. Support for + the use of MPLS multicast control protocols (e.g., [RFC6388] + [RFC4875]) by customer sites is also outside the scope of this + document. + + When a VPN customer uses ASM, the customer routers need to be able to + map from a C-group address to a C-RP address. These mappings can be + provisioned in each router, or they can be discovered dynamically + through protocols such as the Bootstrap Router (BSR) mechanism + [RFC5059]. However, it cannot be assumed that such protocols will + automatically work in the context of an extranet. Discussion of the + use of such protocols in an extranet is outside the scope of this + document. + +1.2.2. Provider Multicast Control Protocols + + [RFC6513] allows either PIM or BGP to be used as the protocol for + distributing customer multicast routing information. Except where + otherwise specified, such as in Sections 6 and 7, the procedures of + this document cover both cases. + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 7] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +1.3. Clarification on Use of Route Distinguishers + + [RFC4364] requires that every VRF be associated with one or more + Route Distinguishers (RDs). Each VPN-IPv4 or VPN-IPv6 route that is + exported from a particular VRF contains, in its NLRI, an RD that is + associated with that VRF. + + [RFC4364] allows a given RD to be associated with more than one VRF, + as long as all the VRFs associated with that RD belong to the same + VPN. However, in the most common deployment model, each RD is + associated with one and only one VRF. [RFC6513] and [RFC6514] + presuppose this deployment model. That is, [RFC6513] and [RFC6514] + presuppose that every RD is associated with one and only one VRF. We + will call this the "unique VRF per RD" condition. + + [RFC6514] defines the MCAST-VPN address family, which has a number of + route types. Each Intra-Autonomous System (Intra-AS) "Inclusive + Provider Multicast Service Interface" (I-PMSI) A-D route, S-PMSI A-D + route, and Source Active A-D route, when exported from a given VRF, + contains, in its NLRI, an RD that is associated with the VRF. + [RFC6513] and [RFC6514] also discuss a class of routes known as + "UMH-eligible" routes; when a UMH-eligible route is exported from a + given VRF, its NLRI contains an RD of the VRF. + + [RFC6514] also defines MCAST-VPN routes whose NLRIs do not contain an + RD of the VRF from which they are exported: the C-multicast Join + routes and the Leaf A-D routes. + + Those route types that, when exported from a given VRF, contain (in + their NLRIs) an RD of the VRF, will be known in this document as + "local-RD routes". + + Given the "unique VRF per RD" condition, if one sees that two + local-RD routes have the same RD, one can infer that the two routes + originated from the same VRF. This inference can be drawn even if + the two routes do not have the same SAFI, as long as the two routes + are both local-RD routes. + + This document builds upon [RFC6513] and [RFC6514]; therefore, the + "unique VRF per RD" condition is REQUIRED. + + [RFC6514] presupposes a further requirement on the use of RDs in the + local-RD routes exported from a given VRF. Suppose that a given VRF + exports a Source Active A-D route containing (C-S,C-G). That VRF + will also export a UMH-eligible route matching C-S. [RFC6514] + presupposes that the UMH-eligible route and the Source Active A-D + route have the same RD. + + + + +Rekhter, et al. Standards Track [Page 8] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + In most cases, not only is a given RD associated with only a single + VRF, but a given VRF is associated with only a single RD. We will + call this the "unique RD per VRF" condition. When this condition + holds, all the local-RD routes exported from a given VRF will have + the same RD. This ensures that the presupposition of the previous + paragraph will hold, i.e., that the RD in a Source Active A-D route + exported from a given VRF will have the same RD as the corresponding + UMH-eligible route exported from the same VRF. + + Section 7.3 of this document describes a procedure known as "extranet + separation". When extranet separation is NOT being used, it is + REQUIRED by this document that the "unique RD per VRF" condition + hold. This ensures that all the local-RD routes exported from a + given VRF will have the same RD. + + When extranet separation is used, a VRF that contains both extranet + sources and non-extranet sources MUST be configured with two RDs. + One of these RDs is known as the "default RD", and the other is known + as the "extranet RD". It MUST be known by configuration which RD is + the default RD and which is the extranet RD. + + When a VRF is configured with only one RD, we will refer to that RD + as the "default RD". + + In general, local-RD routes exported from a given VRF will contain + the default RD. However, when extranet separation is used, some of + the local-RD routes exported from the VRF will contain the + extranet RD. Details concerning the exported routes that contain + the extranet RD can be found in Sections 4.1 and 7.3. + + Note that the "unique VRF per RD" condition applies to the + extranet RD as well as the default RD. That is, a given extranet RD + is associated with a unique VRF. + +1.4. Overview + + Consider two VPNs, VPN-S and VPN-R, each of which supports MVPN + functionality as specified in [RFC6513] and/or [RFC6514]. In the + simplest configuration, VPN-S is a collection of VRFs, each of which + is configured with a particular Route Target (RT) value (call it + "RT-S") as its import RT and as its export RT. Similarly, VPN-R is a + collection of VRFs, each of which is configured with a particular RT + value (call it "RT-R") as its import RT and as its export RT. + + + + + + + + +Rekhter, et al. Standards Track [Page 9] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + In this configuration, multicast C-receivers contained in a VPN-R VRF + cannot receive multicast data traffic from multicast C-sources + contained in a VPN-S VRF. If it is desired to allow this, one needs + to create an MVPN "extranet". Creating an extranet requires + procedures in addition to those specified in [RFC6513], [RFC6514], + and [RFC6625]; this document specifies these additional procedures. + + In the example above, the additional procedures will allow a selected + set of routes exported from the VPN-S VRFs (i.e., from the VRFs + containing extranet C-sources) to be imported into the VPN-R VRFs + (i.e., into the VRFs containing extranet C-receivers). These routes + include the routes that are to be eligible for use as UMH routes (see + Section 5.1 of [RFC6513]) in the extranet, as well as a selected set + of BGP A-D routes (Intra-AS I-PMSI A-D routes, S-PMSI A-D routes, and + Source Active A-D routes). Importing these routes into the VPN-R + VRFs makes it possible to determine, in the context of a VPN-R VRF, + that a particular C-multicast Join needs to be delivered to a + particular VPN-S VRF. It also makes it possible to determine, in the + context of a VPN-R VRF, the P-tunnel through which the aforementioned + VPN-S VRF sends a particular C-flow. + + Depending on the type of P-tunnel used, it may also be necessary for + Leaf A-D routes to be exported by one or more VPN-R VRFs and imported + into a VPN-S VRF. + + There are no extranet-specific procedures governing the use and + distribution of BGP C-multicast routes. + + If PIM is used as the PE-PE protocol for distributing C-multicast + routing information, additional BGP A-D routes must be exported from + the VPN-R VRFs and imported into the VPN-S VRFs, so that the VPN-S + VRFs can join the P-tunnels that the VPN-R VRFs use for sending PIM + control messages. Details can be found in Section 6. + + The simple example above describes an extranet created from two + MVPNs, one of which contains extranet C-sources and one of which + contains extranet C-receivers. However, the procedures described in + this document allow for much more complicated scenarios. + + For instance, an extranet may contain extranet C-sources and/or + extranet C-receivers from an arbitrary number of VPNs, not just from + two VPNs. An extranet C-receiver in VPN-R may be allowed to receive + multicast traffic from extranet C-sources in VPN-A, VPN-B, and VPN-C. + Similarly, extranet C-sources in VPN-S may be allowed to send + multicast traffic to multicast C-receivers that are in VPN-A, VPN-B, + VPN-C, etc. + + + + + +Rekhter, et al. Standards Track [Page 10] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + A given VPN customer may desire that only some of its multicast + C-sources be treated as extranet C-sources. This can be accomplished + by appropriate provisioning of the import and export RTs of that + customer's VRFs (as well as the VRFs of other VPNs that contain + extranet C-receivers for extranet C-flows of the given customer). + + A given VPN customer may desire that some of its extranet C-sources + can transmit only to a certain set of VPNs while other of its + extranet C-sources can transmit only to a different set of VPNs. + This can be accomplished by provisioning the VRFs to export different + routes with different RTs. + + In all these cases, the VPN customers set the policies, and the + Service Provider (SP) implements the policies by the way it + provisions the import and export RTs of the VRFs. It is assumed that + the customer communicates to the SP the set of extranet C-source + addresses and the set of VPNs to which each C-source can transmit. + (Recall that every C-source that can transmit to an extranet C-group + is an extranet C-source and must be able to transmit to any VPN that + has receivers for that group. This must be taken into account when + the provisioning is done.) This customer/SP communication is part of + the service provisioning process and is outside the scope of this + document. + + It is possible that an extranet C-source will transmit both extranet + C-flows and non-extranet C-flows. However, if extranet C-receiver + C-R can receive extranet C-flows from extranet C-source C-S, the + procedures of this document do not prevent C-R from requesting and + receiving the non-extranet flows that are transmitted by C-S. + Therefore, allowing an extranet C-source to transmit non-extranet + C-flows is NOT RECOMMENDED. However, the SP has no control over the + set of C-flows transmitted by a given C-source and can do no more + than communicate this recommendation to its customers. + (Alternatively, the customer and SP may coordinate on setting up + filters to prevent unauthorized flows from being sent to a customer + site; such a procedure is outside the scope of this document.) See + Section 10 ("Security Considerations") for additional discussion of + this issue. + + Whenever a VPN is provisioned, there is a risk that errors in + provisioning may result in an unintended cross-connection of VPNs. + This would create a security problem for the customers. When + provisioning an extranet, attention to detail is particularly + important, as an extranet intentionally cross-connects VPNs. Care + must always be taken to ensure that the cross-connections are + according to the policy agreed upon by the SP and its customers. + + + + + +Rekhter, et al. Standards Track [Page 11] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Additionally, if one is connecting two VPNs that have overlapping + address spaces, one has to be sure that the inter-VPN traffic neither + originates from nor is destined to the part of the address space that + is in the overlap. Other problems that can arise due to overlapping + address spaces are discussed in Section 2. + +2. Extranets and Overlapping Address Spaces + + As specified in [RFC4364], the address space of one VPN may overlap + with the address space of another. A given address may be + "ambiguous" in that it denotes one system within VPN-A and a + different system within VPN-B. In the notation of Section 1.1, + if an address C-S is ambiguous between VPN-A and VPN-B, then + Host(C-S,A) != Host(C-S,B). However, any given address C-S MUST be + unambiguous (i.e., MUST denote a single system) in the context of a + given VPN. + + When a set of VRFs belonging to different VPNs are combined into an + extranet, it is no longer sufficient for an address to be unambiguous + only within the context of a single VPN: + + 1. Suppose that C-S is the address of a given extranet C-source + contained in VPN-A. Now consider the set of VPNs + {VPN-B, VPN-C, ...} containing extranet C-receivers that are + allowed by policy to receive extranet C-flows from VPN-A's C-S. + The address C-S MUST be unambiguous among this entire set of VPNs + {VPN-A, VPN-B, VPN-C, ...}; i.e., Host(C-S,A) == Host(C-S,B) == + Host(C-S,C). + + The implication is that C-S in VPN-A is not necessarily an + extranet C-source for all VPNs that contain extranet C-receivers; + policy MUST be used to ensure that C-S is an extranet C-source + for a given VPN, say VPN-B, only if C-S is unambiguous between + VPN-A and VPN-B. + + 2. If a given VRF contains extranet C-receivers for a given extranet + C-source, then the address of this C-source MUST be unambiguous + among all the extranet C-sources for which there are C-receivers + in the VRF. This is true whether or not C-sources are in VRFs + that belong to the same VPN or different VPNs. + + The implication is that if C-S in VRF-X is ambiguous with C-S in + VRF-Y, then there MUST NOT be any VRF, say VRF-Z, containing + C-receivers that are allowed by policy to receive extranet + C-flows from both C-S in VRF-X and C-S in VRF-Y. + + + + + + +Rekhter, et al. Standards Track [Page 12] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Note: A VPN customer may be using anycast addresses. An anycast + address is intentionally ambiguous, as it denotes a set of systems + rather than a single system. In this document, we will consider an + anycast address to be unambiguous in a given context as long as it + denotes the same set of systems whenever it occurs in that context. + + A multicast C-group address, say C-G, may also be ambiguous in that + it may be used for one multicast group in VPN-A and for an entirely + different multicast group in VPN-B. If a set of MVPNs are combined + into an extranet and C-G is an extranet C-group, it is necessary to + ensure that C-G is unambiguous among the entire set of VPNs whose + VRFs contain extranet C-sources, C-RPs, and/or extranet C-receivers + for that C-group. This may require, as part of the provisioning + process, customer/SP communication that is outside the scope of this + document. + + Subject to these restrictions, the SP has complete control over the + distribution of routes in an MVPN. This control is exerted by + provisioning either (1) the export RTs on the VRFs that originate the + routes (i.e., the VRFs that contain the extranet C-sources) or + (2) the import RTs on the VRFs that receive the routes (i.e., the + VRFs that contain the extranet C-receivers), or both. + + Some of the rules and restrictions on provisioning the RTs are + applicable to all extranets; these are specified in Section 4. + Sections 6 and 7 list additional rules and restrictions that are + applicable only to particular extranet scenarios. + + Even if all the RTs are provisioned according to the above rules and + restrictions, it is still possible for a single P-tunnel to contain + multicast data packets whose source and/or group addresses are + ambiguous in the context of the set of PEs that receive data from the + P-tunnel. That is, the above rules and restrictions are necessary, + but not sufficient, to prevent address ambiguity from causing + misdelivery of traffic. To prevent such misdelivery, additional + procedures or policies must be used. + + Sections 2.1 and 2.2 describe scenarios in which a given P-tunnel may + carry data packets with ambiguous addresses. The additional + procedures and policies needed to prevent misdelivery of data in + those scenarios are outlined in Section 2.3. (The detailed + procedures described in Sections 6 and 7 incorporate the + considerations discussed in Section 2.3.) + + + + + + + + +Rekhter, et al. Standards Track [Page 13] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +2.1. Ambiguity: P-Tunnel with Extranet/Non-extranet Flows + + In the following, we will use the notation "VRF A-n" to mean "VRF n + of VPN-A". + + If VPN-A and VPN-B have overlapping address spaces and are part of + the same extranet, then the following problem may exist, as + illustrated in Figure 1. + + C-S2(A) C-S1 Join(C-S2(A),G) + \ / / + \ / / + +-------+---+ P1: (C-S1,G), (C-S2(A),G) +---+--------+ + |VRF A-1| |---------------------------------| |VRF A-2 | + +-------+PE1| |PE2+--------+ + |VRF B-1| |---------------------------------| |VRF B-2 | + +-------+---+ P2: (C-S2(B),G) +---+--------+ + / / \ + / / \ + C-S2(B) Join(C-S2(B),G) Join(C-S1,G) + + Figure 1: Ambiguity of Extranet and Non-extranet Source Address + + Suppose that: + + o C-G is an SSM C-group used in VPN-A and VPN-B. + + o VRF A-1, on PE1, contains an extranet C-source, with IP address + C-S1, that is allowed to have receivers in VPN-B. VRF A-1 thus + exports to VPN-B a UMH-eligible route matching C-S1. + + o In addition, VRF A-1 contains a non-extranet C-source with IP + address C-S2. VRF A-1 exports a UMH-eligible route matching C-S2 + to other VPN-A VRFs but NOT to VPN-B. + + o VRF B-1, also on PE1, contains a non-extranet C-source with IP + address C-S2. A UMH-eligible route matching C-S2 is thus exported + from VRF B-1 to other VRFs in VPN-B. + + o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous + address in any extranet that contains both VPN-A VRFs and VPN-B + VRFs. + + o VRF B-2, on some other PE, say PE2, requests the multicast flow + (C-S1,C-G). In the context of VRF B-2, C-S1 matches the route + exported from VRF A-1. Thus, B-2's request to receive the + (C-S1,C-G) flow is transmitted to VRF A-1. + + + + +Rekhter, et al. Standards Track [Page 14] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + o VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by + transmitting that traffic on P-tunnel P1. + + o VRF B-2 joins P-tunnel P1 in order to receive the (C-S1,C-G) + traffic. + + o VRF A-2, on PE2, requests the (non-extranet) multicast flow + (C-S2,C-G). In the context of VRF A-2, C-S2 matches the route + exported from VRF A-1. Thus, A-2's request to receive the + (C-S2,C-G) traffic is transmitted to VRF A-1. + + o VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by + transmitting that traffic on P-tunnel P1. + + o VRF A-2 joins P-tunnel P1 in order to receive the (C-S2,C-G) + traffic. + + o VRF B-2 requests the (non-extranet) multicast flow (C-S2,C-G). In + the context of VRF B-2, C-S2 matches the route exported from VRF + B-1. Thus, B-2's request to receive the (C-S2,C-G) flow is + transmitted to VRF B-1. + + o VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by + transmitting that traffic on P-tunnel P2. + + o VRF B-2 joins P-tunnel P2. + + Since VRF B-2 has joined P-tunnel P1 and P-tunnel P2, it will receive + (C-S2,C-G) traffic on both P-tunnels. The (C-S2,C-G) traffic that + VRF B-2 needs to receive is traveling on P-tunnel P2; this (C-S2,C-G) + traffic must be forwarded by B-2 to any attached customer sites that + have C-receivers for it. But B-2 MUST discard the (C-S2,C-G) traffic + that it receives on P1, as this is not the traffic that it has + requested. If the (C-S2,C-G) traffic arriving on P1 were forwarded + to B-2's customer sites, the C-receivers would not be able to + distinguish the two flows, and the result would be a corrupted data + stream. + + Note that the procedures of Section 9.1.1 of [RFC6513] ("Discarding + Packets from Wrong PE") will not cause VRF B-2 to discard the + (C-S2,C-G) traffic that arrives on tunnel P1, because P1 and P2 have + the same upstream PE. + + Therefore, it is necessary to EITHER (1) prevent the above scenario + from occurring OR (2) ensure that multicast data packets will be + discarded if they arrive on the wrong P-tunnel (even if they arrive + from the expected PE). See Section 2.3 for further discussion of + this issue. + + + +Rekhter, et al. Standards Track [Page 15] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows + + Figure 2 illustrates another example of how overlapping address + spaces may cause a problem. + + C-S2(A2D) C-S1(A2C) Join(C-S2(A2D),G) + \ / / + \ / / + +-------+---+ P1: (C-S1(A2C),G), (C-S2(A2D),G)+---+--------+ + |VRF A-1| |---------------------------------| |VRF D-1 | + +-------+PE1| |PE2+--------+ + |VRF B-1| |---------------------------------| |VRF C-1 | + +-------+---+ P2: (C-S2(B2C),G) +---+--------+ + / / \ + / / \ + C-S2(B2C) / \ + Join Join + (C-S2(B2C),G) (C-S1(A2C),G) + + Figure 2: Ambiguity of Extranet Source Addresses + + Suppose that: + + o C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C, + and VPN-D. + + o VRF A-1, on PE1, contains an extranet C-source, with IP address + C-S1, that is allowed by policy to have C-receivers in VPN-C (but + not in VPN-D). VRF A-1 thus exports a UMH-eligible route matching + C-S1 to VPN-C. + + o In addition, VRF A-1 contains an extranet C-source, with IP + address C-S2, that is allowed by policy to have C-receivers in + VPN-D (but not in VPN-C). VRF A-1 thus exports a UMH-eligible + route matching C-S2 to VPN-D. + + o VRF B-1, also on PE1, contains an extranet C-source, with IP + address C-S2, that is allowed by policy to have C-receivers in + VPN-C (but not in VPN-D). VRF B-1 thus exports a UMH-eligible + route matching C-S2 to VPN-C. + + o Host(C-S2,A) != Host(C-S2,B). That is, C-S2 is an ambiguous + address in any extranet that contains both VPN-A VRFs and + VPN-B VRFs. + + + + + + + +Rekhter, et al. Standards Track [Page 16] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + o VRF C-1, on some other PE, say PE2, requests the extranet + multicast flow (C-S1,C-G). In the context of VRF C-1, C-S1 + matches the route exported from VRF A-1. Thus, C-1's request to + receive the (C-S1,C-G) flow is transmitted to VRF A-1. + + o VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by + transmitting that traffic on P-tunnel P1. + + o VRF C-1 joins P-tunnel P1 in order to receive the (C-S1,C-G) + traffic. + + o VRF C-1 requests the extranet multicast flow (C-S2,C-G). In the + context of VRF C-1, C-S2 matches the route exported from VRF B-1. + Thus, C-1's request to receive the (C-S2,C-G) flow is transmitted + to VRF B-1. + + o VRF B-1 responds by transmitting its (C-S2,C-G) traffic on + P-tunnel P2. + + o VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) + traffic. + + o VRF D-1, on PE2, requests the extranet multicast flow (C-S2,C-G). + In the context of VRF D-1, C-S2 matches the route exported from + VRF A-1. Thus, D-1's request to receive the (C-S2,C-G) flow is + transmitted to VRF A-1. + + o VRF A-1 responds by transmitting its (C-S2,C-G) traffic on + P-tunnel P1. + + o VRF D-1 joins P-tunnel P1 in order to receive the (C-S2,C-G) + traffic. + + In this example, VRF A-1 has chosen to use the same P-tunnel, P1, to + carry both its (C-S2,C-G) traffic and the (C-S1,C-G) traffic. VRF + C-1 has joined tunnel P1 in order to receive the (C-S1,C-G) traffic + from VRF A-1, which means that VRF C-1 will also receive the unwanted + (C-S2,C-G) traffic from P1. VRF C-1 is also expecting (C-S2,C-G) + traffic from VRF B-1; this traffic will be received from P2. Thus, + VRF C-1 is receiving (C-S2,C-G) traffic on both tunnels, and both + C-flows arrive from the expected PE, PE1. + + Therefore, it is necessary to EITHER (1) prevent the above scenario + from occurring OR (2) ensure that VRF C-1 discards any (C-S,C-G) + traffic that arrives from the wrong P-tunnel. See Section 2.3 for + further discussion of this issue. + + + + + +Rekhter, et al. Standards Track [Page 17] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Note that the ambiguity described in this section (Section 2.2) would + not occur if C-G were an (ASM) extranet C-group. In that case, the + scenario would violate the rule, given previously in Section 2, + requiring that all sources sending to a particular ASM extranet + C-group must have addresses that are unambiguous over all the MVPNs + receiving traffic for that C-group. + +2.3. Preventing Misdelivery in These Scenarios + + There are two ways to prevent the scenarios discussed in Sections 2.1 + and 2.2 from resulting in misdelivery of data; these techniques are + discussed in Sections 2.3.1 and 2.3.2, respectively. + +2.3.1. Do Not Deliver Packets from the Wrong P-tunnel + + Consider a particular C-flow that has receivers in a particular VRF. + Sections 6 and 7 describe a set of procedures that enable an egress + PE to determine the "expected P-tunnel" for that C-flow in the + context of that VRF. If a PE receives packets of the C-flow (as + determined by the IP source and/or destination address of the + packet), it checks to see if the packet was received on the expected + P-tunnel for that VRF. If so, the packet is delivered to the VRF + (and thus to the C-flow's receivers in that VRF). If not, the packet + is not delivered to the VRF. + + Note that at a given egress PE, the wrong P-tunnel for one VRF may be + the correct P-tunnel for another. + + These procedures, if applied at every PE that joins a given P-tunnel, + are sufficient to prevent misdelivery of traffic in the scenarios + discussed in Sections 2.1 and 2.2. + + IF these procedures cannot be applied by every PE that is attached to + a given extranet, then the policies of Section 2.3.2 MUST be applied + at every VRF containing C-sources for that extranet. + + In some cases, however, it may be safe to deliver packets that arrive + from other than the expected P-tunnel. Suppose that it is known that + every packet gets transmitted on only a single P-tunnel. (This will + be the case if the "single PMSI per C-flow" transmission model, + discussed in Section 3.1, is being used.) Suppose also that it is + known that T1 and T2 carry only packets that arrived at the same + ingress PE, over one or more VRF interfaces that are associated with + the same VRF (i.e., that there is a particular VRF that is the + ingress VRF for ALL the packets carried by T1 or T2). In this case, + if T1 is the expected P-tunnel for a given (C-S,C-G), it is NOT + necessary to discard (S,G) packets that arrive over T2. + + + + +Rekhter, et al. Standards Track [Page 18] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + It is not always possible to determine whether two P-tunnels are + carrying packets from the same ingress VRF. However, in some cases, + this can be determined by examination of the A-D routes in which the + tunnels have been advertised. + + Consider the following example: + + o Tunnel T1 is a Point-to-Multipoint (P2MP) multipoint Label + Distribution Protocol (mLDP) or RSVP-TE P-tunnel advertised in an + Intra-AS I-PMSI A-D route (call it "R1"). + + o Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an + S-PMSI A-D route (call it "R2"). + + o The respective NLRIs of R1 and R2 contain the same RD value. + + o The MPLS Label field of R1's PTA is zero, and the MPLS label value + of R2's PTA is zero. + + In this example, it can be concluded that T1 and T2 are carrying + packets from the same ingress VRF. Thus, if T1 is the expected + P-tunnel for a (C-S,C-G) flow, (S,G) packets from T2 can be safely + delivered to the egress VRF; they do not need to be discarded. + Similarly, if T2 is the expected P-tunnel for a (C-S,C-G) flow, (S,G) + packets from T1 can be safely delivered to the egress VRF. + + Another example is the following: + + o Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a + (C-*,C-*) S-PMSI A-D route (call it "R3"). + + o Tunnel T4 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a + (C-S,C-G) S-PMSI A-D route (call it "R4"). + + o The respective NLRIs of R3 and R4 contain the same RD value. + + o The MPLS Label field of R3's PTA is zero, and the MPLS label value + of R4's PTA is zero. + + In this example, it can be concluded that T3 and T4 are carrying + packets from the same ingress VRF. Thus, if T3 is the expected + P-tunnel for a (C-S,C-G) flow, (S,G) packets from T4 can be safely + delivered to the egress VRF; they do not need to be discarded. + Similarly, if T4 is the expected P-tunnel for a (C-S,C-G) flow, + (S,G) packets from T3 can be safely delivered to the egress VRF. + + + + + + +Rekhter, et al. Standards Track [Page 19] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + When Ingress Replication (IR) P-tunnels are being used, please see + [MVPN-IR], especially Section 7 ("The PTA's 'MPLS Label' Field") for + a discussion of how to determine when packets from other than the + expected P-tunnel must be discarded. + +2.3.2. Policies to Prevent Ambiguity on a P-Tunnel + + For P-tunnels that are advertised in S-PMSI A-D routes whose NLRI + contains (C-S,C-G) or (C-S,C-*), the ambiguities described in + Sections 2.1 and 2.2 can be prevented by provisioning a policy that + assigns, to such P-tunnels, only flows from the same C-source. + + However, it is not always possible to determine, through inspection + of the control messages, whether this policy has been deployed. For + instance, suppose that (1) a given VRF has imported a set of S-PMSI + A-D routes, (2) each route in the set has bound only a single + (C-S1,C-G1) to a single P-tunnel, and (3) each route in the set + identifies a different P-tunnel in its PTA than the P-tunnel + identified by the PTA of any other route in the set. One cannot + infer from this that there is no ambiguity, as the same P-tunnel may + also have been advertised in an S-PMSI A-D route that is not imported + by the given VRF, and that S-PMSI A-D route may have bound + (C-S2,C-G2) to the P-tunnel, where C-S1 != C-S2. + + Therefore, in order to determine that a given P-tunnel (advertised in + a (C-S,C-G) or (C-S,C-*) S-PMSI A-D route) carries only C-flows from + a single C-source, a PE must have a priori knowledge (through + provisioning) that this policy has been deployed. In the remainder + of this document, we will refer to this policy as the "single + C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy. Note that this + policy is only applicable to P-tunnels that are advertised only in + (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes. + + Of course, if a P-tunnel is advertised in (a) an I-PMSI A-D route, + (b) an S-PMSI A-D route whose NLRI contains (C-*,C-*), or (c) an + S-PMSI A-D route whose NLRI contains (C-*,C-G), then it is always + possible for the P-tunnel to contain traffic from multiple C-sources; + there is no policy that can prevent that. + + However, if a P-tunnel advertised in a (C-*,C-G) S-PMSI A-D route + contains only traffic addressed to a single C-G, the address + uniqueness rules of Section 2 prevent the C-source addresses from + being ambiguous; the set of C-sources transmitting to a particular + extranet C-group address must be unambiguous over the set of MVPNs + that have receivers for that C-group. So, for P-tunnels that are + advertised in (C-*,C-G) S-PMSI A-D routes, the ambiguities described + in Sections 2.1 and 2.2 can be prevented by provisioning a policy + + + + +Rekhter, et al. Standards Track [Page 20] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + that assigns to such P-tunnels only flows to the same extranet + C-group. We will refer to this policy as the "single C-group per + (C-*,C-G) P-tunnel" policy. + + These considerations can be summarized as follows. IF the procedures + referenced in Section 2.3.1 cannot be applied, then the PEs MUST be + provisioned so that all of the following conditions hold true for the + VRFs that contain extranet C-sources: + + o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy + is provisioned, + + o either no (C-*,C-G) S-PMSI A-D routes are advertised or the + "single C-group per (C-*,C-G) P-tunnel" policy is provisioned, + + o no P-tunnels are advertised in I-PMSI A-D routes, and + + o no (C-*,C-*) S-PMSI A-D routes are advertised. + + Section 3 of this document describes a procedure known as "extranet + separation". When extranet separation is used, the ambiguity + described in Section 2.1 is prevented. However, the ambiguity + described in Section 2.2 is not prevented by extranet separation. + Therefore, the use of extranet separation is not a sufficient + condition for avoiding the use of the procedures discussed in + Section 2.3.1. Extranet separation is, however, implied by the + policies discussed in this section (Section 2.3.2). + +3. Extranet Transmission Models + + This document specifies several "extranet transmission" models. A + given VRF containing extranet C-sources or C-receivers MUST use only + one of these models. Further, if VRF-S contains extranet C-sources, + VRF-R contains extranet C-receivers, and it is allowed by policy for + an extranet C-receiver in VRF-R to receive a C-flow from an extranet + C-source in VRF-S, then VRF-S and VRF-R MUST use the same extranet + transmission model. The model used by a given VRF is determined by + provisioning. + +3.1. Transmitting an Extranet C-Flow on a Single PMSI + + In one extranet transmission model, which we call the "transmitting + an extranet C-flow on a single PMSI" model or, more simply, the + "single PMSI per C-flow" model, a PE transmitting a packet of an + extranet C-flow transmits it on only a single PMSI. If the PMSI is + instantiated by a multicast P-tunnel, this means that the PE + transmits the packet on a single P-tunnel. Of course, if the PE is a + replication point for that multicast P-tunnel, the packet is + + + +Rekhter, et al. Standards Track [Page 21] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + transmitted more than once by the PE. Similarly, if the PMSI is + instantiated by IR, each packet may be transmitted multiple times. + It is still the case, though, that the packet is transmitted only on + one PMSI. + + This document provides procedures for supporting this transmission + model using either BGP or PIM as the PE-PE C-multicast control + protocol. + + There are two variants of this transmission model: "without extranet + separation" and "with extranet separation". + +3.1.1. Without Extranet Separation + + In this variant, multicast data traffic from extranet C-sources and + from non-extranet C-sources may be carried in the same P-tunnel. + + This document provides procedures for supporting this variant using + either BGP or PIM as the PE-PE C-multicast control protocol. + +3.1.2. With Extranet Separation + + In this variant, multicast data traffic from extranet C-sources and + from non-extranet C-sources are never carried in the same P-tunnel. + Under certain circumstances, this can reduce the amount of multicast + data traffic that is delivered unnecessarily to certain PE routers. + It also eliminates the ambiguity discussed in Section 2.1. + + By definition, when extranet separation is used, the following rule + MUST be applied: + + Traffic from extranet C-sources MUST NOT be carried in the same + P-tunnel as traffic from non-extranet C-sources. + + This rule does not impact those VRFs that contain only non-extranet + C-sources, nor does it impact those VRFs that contain only extranet + C-sources. However, if a particular VRF contains both kinds of + C-sources, it will need to advertise some P-tunnels that are used for + carrying only extranet C-flows and some that are used only for + carrying non-extranet C-flows. + + This document provides procedures for supporting extranet separation + when BGP is used as the PE-PE C-multicast control protocol. Support + for extranet separation using PIM as the PE-PE C-multicast control + protocol is outside the scope of this document. + + + + + + +Rekhter, et al. Standards Track [Page 22] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +3.2. Transmitting an Extranet C-Flow over Multiple PMSIs + + The second extranet transmission model is called the "transmitting an + extranet C-flow over multiple PMSIs" model or, more simply, the + "multiple PMSIs per C-flow" model. In this model, a PE may transmit + the packets of an extranet C-flow on several different PMSIs. + + Support for extranet separation with this model is outside the scope + of this document. + + This document provides procedures for supporting this transmission + model when PIM is used as the PE-PE C-multicast control protocol. + Support for this transmission model when BGP is used as the PE-PE + C-multicast control protocol is outside the scope of this document. + +4. Distribution of Routes That Match C-S/C-RP Addresses + +4.1. UMH-Eligible Routes + + As described in Section 5.1 of [RFC6513], in order for a C-flow + (C-S,C-G) to be carried across the SP backbone, a VRF that has + multicast receivers for that C-flow must import a route that matches + C-S, and this route must be "eligible for UMH selection". In this + document, we will refer to these routes as "UMH-eligible extranet + C-source routes". + + The UMH-eligible extranet C-source routes do not necessarily have to + be unicast routes; they MAY be SAFI 129 routes (see Section 5.1.1 of + [RFC6513]). For example, suppose that one wants a VPN-R C-receiver + to be able to receive extranet C-flows from C-sources in VPN-S but + does not want any VPN-R system to be able to send unicast traffic to + those C-sources. One can achieve this by using SAFI 129 routes as + the UMH-eligible routes exported from VPN-S and imported by VPN-R. + Since SAFI 129 routes are used only for UMH determination and not for + unicast routing, this allows the multicast traffic to be forwarded + properly but does not create unicast routes to the C-sources. + + If a customer is using PIM-SM in the ASM model and one or more + customer sites have C-receivers that are allowed by policy to join a + (C-*,C-G) tree, where C-G is an extranet C-group, then any VRF with + C-receivers for that group MUST import a UMH-eligible route that + matches C-RP, where C-RP is the Rendezvous Point (RP) address + for C-G. + + The UMH-eligible extranet C-source and C-RP routes do not have to be + "host routes". That is, they can be routes whose IPv4 address + prefixes are not 32 bits in length or whose IPv6 address prefixes are + not 128 bits in length. So, it is possible for a UMH-eligible + + + +Rekhter, et al. Standards Track [Page 23] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + extranet C-source route to match the address of an extranet C-source + and to also match the address of a non-extranet C-source. However, + if such a route is exported from a VPN-S VRF and imported by a VPN-R + VRF, VPN-R receivers will be able to receive C-flows from any + non-extranet C-sources whose addresses match that route. To prevent + this, the VPN-S VRF SHOULD be provisioned such that it will NOT + export a UMH-eligible route that matches (in the context of the VPN-R + VRF) both extranet C-sources and non-extranet C-sources. Failure to + follow this rule may result in a VPN security violation. (See + Section 10.) + + In general, one does not want ALL the routes from the VPN-S VRFs to + be exported to all the VPN-R VRFs, as only a subset of the routes in + the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route + distribution is, as is always the case for a BGP/MPLS IP VPN + [RFC4364], controlled by Route Targets (RTs). A variety of route + distribution policies can be created by appropriately provisioning + the import and export RTs of the various VRFs. + + For example, the VPN-S VRFs that contain extranet C-sources could be + configured to apply an export RT whose value is "RT-A-extranet" to + the routes that match the extranet C-sources. The VPN-R VRFs that + contain extranet C-receivers allowed to receive extranet C-flows + from VPN-S extranet C-sources could then be configured with + "RT-A-extranet" as an import RT. + + Arbitrarily complex policies can be created by suitable manipulation + of the import and export RTs. + +4.1.1. Extranet Separation + + If extranet separation is being used and a given VRF is exporting + UMH-eligible routes for both extranet C-sources and non-extranet + C-sources, then the VRF MUST be configured not only with its + default RD but also with an extranet RD. The exported UMH-eligible + routes MUST contain the extranet RD in their NLRIs. + + + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 24] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +4.2. Distribution of Unicast Routes Matching C-RPs and DRs + + Consider a C-source, C-S, that may transmit to a particular extranet + C-group, C-G. + + In order to follow the procedures of [RFC7761], + + o The "first-hop designated router (DR)" for C-S needs to be able to + unicast PIM Register messages to a C-RP that services C-G. + + o The C-RPs servicing C-G need to be able to unicast PIM + Register-Stop messages to the DR for C-S. + + It follows that if a VRF contains C-S but does not contain a C-RP for + C-G, then the VRF MUST import a unicast route matching a C-RP for + C-G. Note that the unicast route matching the C-RP is needed whether + or not the VRF has also imported a SAFI 129 route matching the C-RP. + (If the VRF also contains receivers for C-G and UMH determination is + being done using SAFI 129 routes, both a unicast route and a SAFI 129 + matching C-RP route are needed.) + + Similarly, if a VRF contains a C-RP for C-G but does not contain C-S, + the VRF MUST import a unicast route matching the DR for C-S. Note + that the unicast route matching the DR for C-S is needed even if UMH + determination is being done using SAFI 129 routes; in that case, if + the VRF also contains receivers for C-G, it needs to import a + SAFI 129 route matching C-S and a unicast route matching the DR + for C-S. + + If, for a particular extranet C-group, C-G, the customer is using + "anycast-RP" [RFC3446] [RFC4610] or the Multicast Source Discovery + Protocol (MSDP) [RFC3618], then all the C-RPs serving C-G need to + send unicast messages to each other. Thus, any VRF that contains a + C-RP for C-G needs to import unicast routes matching ALL the other + C-RPs that serve C-G. + + The need to distribute these unicast routes is usually not a problem + as long as all the C-sources and C-RPs for C-G are in the same MVPN. + If, however, the C-sources are not all in the same MVPN, great care + must be taken to ensure that the unicast routes mentioned above are + properly distributed. + + There may be scenarios in which all the C-sources for C-G are in the + same MVPN, but there are receivers in different VPNs, and some or all + of the VPNs with receivers have their own C-RPs for C-G. In this + case, care must be taken to ensure that the C-RPs can all unicast to + each other. + + + + +Rekhter, et al. Standards Track [Page 25] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +4.3. Route Targets and Ambiguous UMH-Eligible Routes + + This section imposes a constraint on the way RTs are assigned to + (a) UMH-eligible routes and (b) the BGP A-D routes that advertise + P-tunnels (i.e., BGP A-D routes that contain a PTA). The constraint + specified here applies to any extranet for which the ambiguity + described in Section 2.2 is possible. (The conditions under which + such ambiguity is possible are also described in Section 2.2.) + + We want to ensure that, in any given VRF, the UMH-eligible route + matching a given extranet C-source has an RT in common with every BGP + A-D route that advertises a P-tunnel that may be used to carry + extranet multicast traffic from that C-source. We also want to + ensure that the UMH-eligible route matching a given extranet C-source + does not have any RT in common with any BGP A-D route that advertises + a P-tunnel that may be used to carry any multicast traffic from a + different C-source that has the same IP address. This enables us to + determine whether traffic that appears to be from the given C-source + is really arriving on the wrong P-tunnel and hence is really from a + different C-source with the same IP address. + + Suppose that an IP address C-S is used in VPN-A as the address of one + system and used in VPN-B as the address of a different system. In + this case, one or more VPN-A VRFs may export a VPN-IP route whose + NLRI is <RD1,S>, and one or more VPN-B VRFs may export a VPN-IP route + whose NLRI is <RD2,S>, where RD1 != RD2. Consider two routes -- R1 + and R2 -- for which the following conditions all hold: + + o R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or + are unicast routes matching a C-RP. + + o R1 is exported from a VRF of VPN-A, while R2 is exported from a + VRF of a different VPN, say VPN-B. + + o R1's NLRI specifies IP address prefix S/n. + + o R2's NLRI specifies IP address prefix S/m. + + o m >= n (S/m is either the same as or more specific than S/n). + + o There is some host address H such that: + + * H denotes a different system in VPN-A than in VPN-B, and + + * H/m == S/m (so either S/m or S/n might be a longest match for H + in some VRF). + + + + + +Rekhter, et al. Standards Track [Page 26] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + We impose the following constraint: RTs MUST be assigned in such a + way that R1 and R2 do not have any RT in common. + + (This constraint is not as onerous as it may seem. Typically, R1 and + R2 would not have an RT in common, as that might result in their + being imported into the same VRF, making the address H ambiguous in + that VRF.) + + Sections 6 and 7 specify procedures for determining if a received + C-flow has been received over the expected P-tunnel. Those + procedures will not work if this constraint is violated. (The + constraint described in this section is necessary, but not + sufficient, for the procedures of Sections 6 and 7 to work; + additional constraints that cover the assignment of RTs to BGP A-D + routes are given in subsequent sections.) + +4.4. Dynamically Marking Extranet Routes + +4.4.1. The Extranet Source Extended Community + + Sections 4.1, 4.2, and 4.3 place specific requirements on the way in + which certain VPN-IP routes are distributed. In order to ensure that + these requirements are met, a VPN customer must tell its SP which + routes are the matching routes for extranet C-sources and C-RPs. + This may be done as part of the provisioning process. Note that this + does not necessarily require customer/provider interaction every time + the customer adds a new extranet C-source or C-RP, but only when the + IP address of the new C-source or C-RP does not match an existing + route that is already being distributed as a VPN-IP extranet route. + Nevertheless, it seems worthwhile to support an OPTIONAL mechanism + that allows a customer to dynamically mark certain routes as being + extranet routes. + + To facilitate this, we define a new Transitive Opaque Extended + Community (see [RFC4360], [RFC7153], and Section 9 of this document): + the Extranet Source Extended Community. When a Customer Edge (CE) + router advertises (via BGP) a route to a PE router and the AFI/SAFI + of the route is 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4, the Extranet Source + Extended Community MAY be attached to the route. The value field of + the Extended Community MUST be set to zero. By placing this Extended + Community on a particular route, a CE router indicates to a PE router + that the procedures of Sections 4.1, 4.2, and 4.3 are to be applied + to that route. That is, the CE router may use this Extended + Community to indicate to the PE router that a particular route is to + be treated as a route that matches the address of an extranet source + and is to be exported accordingly to other VPNs. A PE router that + interprets this Extended Community MUST ignore the contents of the + value field. + + + +Rekhter, et al. Standards Track [Page 27] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Whether a CE router uses the Extranet Source Extended Community is + determined by the configuration of the CE router. If used, the set + of routes to which the Extended Community is attached is also + determined by configuration of the CE. Note that a particular PE + router may or may not support the use of the Extranet Source Extended + Community by a particular CE router; this is determined by the + service agreement between the SP and its customer. + + If a CE is advertising SAFI 2 routes to the PE as the UMH-eligible + extranet C-source and C-RP routes and the CE is using the Extranet + Source Extended Community, it is important that the CE attach that + Extended Community to the SAFI 2 routes, rather than just to the + corresponding SAFI 1 routes. Otherwise, extranet receivers may not + be able to join the (C-S,C-G) or (C-*,C-G) multicast trees. + + However, if the C-sources and the C-RPs for a given extranet C-group + are not all in the same VPN, the Extended Community would also have + to be attached to the SAFI 1 routes that match the C-RP addresses and + to the SAFI 1 routes that match the addresses of the first-hop + designated routers for all the C-sources. Otherwise, the first-hop + routers might not be able to send PIM Register messages to the C-RPs, + and the C-RPs might not be able to send PIM Register-Stop messages to + the first-hop routers. + + While this Extended Community allows a customer to inform the SP + dynamically that certain routes are "extranet routes", it does not + allow a customer to control the set of RTs that the route will carry + when it is redistributed as a VPN-IP route. Thus, it is only useful + when all the extranet routes from a given VRF are exported with + exactly the same set of RTs. (cf. Section 4.3.1 of [RFC4364], which + does provide a mechanism that, if properly supported by the SP, + allows the customer to determine the set of RTs carried by a VPN-IP + route.) A CE SHOULD NOT attach the Extranet Source Extended + Community to any route for which it uses another method of specifying + the RTs to be carried by that route. A CE SHOULD NOT attach the + Extranet Source Extended Community to a route unless all the extranet + routes from the CE's VPN are intended to carry the same set of RTs. + + A PE SHOULD ignore the Extranet Source Extended Community if it + appears on a route that the CE should not have put it on. A PE that + ignores the Extranet Source Extended Community SHOULD NOT follow the + procedures of Section 4.4.2. + + Note that misconfiguration on the CE router can result in the + Extranet Source Extended Community being mistakenly attached to a + route that is not intended to be exported as an extranet route. This + could result in a VPN security violation. + + + + +Rekhter, et al. Standards Track [Page 28] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +4.4.2. Distribution of Extranet Source Extended Community + + Suppose that a PE receives from a CE a route (call it "R") with the + Extranet Source Extended Community. The PE must determine (via the + considerations discussed in Section 4.4.1) whether it should ignore + that Extended Community on route R; if it should ignore the Extended + Community, the procedures described in this section are not followed. + + Otherwise, when the PE originates a VPN-IP route corresponding to + route R, the PE MUST attach this Extended Community to that route. + + A Route Reflector MUST NOT add or remove the Extranet Source Extended + Community from the VPN-IP routes reflected by the Route Reflector, + including the case where VPN-IP routes received via Internal BGP + (IBGP) are reflected to External BGP (EBGP) peers (inter-AS + option (c); see Section 10 of [RFC4364]). The value of the Extended + Community MUST NOT be changed by the Route Reflector. + + When re-advertising VPN-IP routes, Autonomous System Border Routers + (ASBRs) MUST NOT add/remove the Extranet Source Extended Community + from these routes. This includes inter-AS options (b) and (c) (see + Section 10 of [RFC4364]). The value of the Extended Community + MUST NOT be changed by the ASBRs. + + When a PE advertises (via BGP) IP routes to a CE, these routes + MUST NOT carry the Extranet Source Extended Community unless the + PE-CE connection is actually an inter-AS option (a) connection (see + Section 10 of [RFC4364]). When the PE-CE connection is not an + inter-AS option (a) connection, a CE that receives an IP route with + the Extranet Source Extended Community MUST remove it from the route + before re-advertising the route. + + The rules for attaching the Extranet Source Extended Community to a + VPN-IP route, and the rules for propagating that Extended Community, + are needed in order to support the scenario in which a VPN contains + an option (a) interconnect (see Section 10 of [RFC4364]). At the + option (a) interconnect, the VPN-IP route gets translated back to an + IP route, and the RTs are stripped off before the IP route is + propagated. If the Extranet Source Extended Community has also been + stripped off, there is no way for the router at the other end of the + option (a) interconnect to know that the route represents an extranet + source. Thus, the technique of using the Extranet Source Extended + Community to dynamically signal that a particular route represents an + extranet source will not work correctly across an option (a) + interconnect unless the rules in this section are followed. + + + + + + +Rekhter, et al. Standards Track [Page 29] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +4.5. The Extranet Separation Extended Community + + We define a new Transitive Opaque Extended Community: the Extranet + Separation Extended Community (see [RFC4360], [RFC7153], and + Section 9 of this document). This Extended Community is used only + when extranet separation is being used. Its value field MUST be set + to zero upon origination, MUST be ignored upon reception, and MUST be + passed unchanged by intermediate routers. A Route Reflector MUST NOT + add or remove the Extranet Separation Extended Community from the + routes it reflects, including the case where routes received via IBGP + are reflected to EBGP peers (inter-AS option (c); see Section 10 of + [RFC4364]). + + If a VRF has been provisioned to use extranet separation and that VRF + has been provisioned to transmit any extranet C-flows on a P-tunnel + that it advertises in an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D + route, then any UMH-eligible routes that are exported from that VRF + following the procedures of Sections 4.1, 4.2, and 4.3 MUST carry the + Extranet Separation Extended Community. In addition, if an I-PMSI + A-D route and/or (C-*,C-*) S-PMSI A-D route exported from that VRF is + used to carry extranet traffic, that A-D route MUST also carry the + Extranet Separation Extended Community. Further details may be found + in Sections 7.3, 7.4.4, and 7.4.5. + +5. Origination and Distribution of BGP A-D Routes + + Except where otherwise specified, this section describes procedures + and restrictions that are independent of the PE-PE C-multicast + control protocol. + +5.1. Route Targets of UMH-Eligible Routes and A-D Routes + + Suppose that there is an extranet C-flow such that: + + o The extranet C-source of that C-flow is in VRF A-1. + + o One or more extranet C-receivers of that C-flow are in VRF B-1. + + In this case, VRF A-1 MUST export a UMH-eligible route that matches + the extranet C-source address, and VRF B-1 MUST import that route. + In addition, VRF A-1 MUST export an Intra-AS I-PMSI A-D route or an + S-PMSI A-D route specifying the P-tunnel through which it will send + the data traffic of the given extranet C-flow, and VRF B-1 MUST + import that route. If BGP is the PE-PE C-multicast control protocol, + then under certain conditions (as specified in [RFC6514]), VRF A-1 + may also need to export a Source Active A-D route specifying that it + contains a source of the given C-flow, and VRF B-1 must import that + Source Active A-D route. That is, in order for VRF B-1 to receive a + + + +Rekhter, et al. Standards Track [Page 30] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + C-flow from a given extranet C-source contained in VRF A-1, VRF A-1 + MUST export a set of A-D routes that are "about" that source, and VRF + B-1 MUST import them. + + One way to ensure this is to provision an RT that is carried by all + the routes exported from VRF A-1 that are "about" a given extranet + C-source and also provision this RT as an import RT at any VRF (such + as VRF B-1) that is allowed to receive extranet flows from that + source. + + If the "single PMSI per C-flow" transmission model is being used + (with or without extranet separation), there is an additional + requirement, stated below, regarding the way RTs are provisioned, as + the RTs carried by a UMH-eligible route that matches a given extranet + C-source may need to be used to identify the A-D routes that are + "about" that source. + + Consider the following scenario: + + o IP address S is the address of one system in VPN-A and the address + of a different system in VPN-B. + + o VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching + route for S. + + o VRF A-1 on PE1 exports an A-D route P1 whose PTA identifies a + P-tunnel through which VRF A-1 may send traffic whose C-source is + S, where one of the following conditions holds: + + * P1 is an I-PMSI A-D route, OR + + * P1 is an S-PMSI A-D route whose NLRI contains (C-*,C-*) or + (C-*,C-G), OR + + * P1 is an S-PMSI A-D route whose NLRI contains (C-S,C-G) or + (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) + P-tunnel" policy is not provisioned, OR + + * P1 is a Source Active A-D route whose NLRI contains (C-S,C-G). + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 31] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + o VRF B-1 on PE1 exports a UMH-eligible route R2, which is a + matching route for S. + + o VRF B-1 on PE1 exports an A-D route P2 whose PTA identifies a + P-tunnel on which VRF B-1 may send traffic whose C-source is S, + where one of the following conditions holds: + + * P2 is an I-PMSI A-D route, OR + + * P2 is an S-PMSI A-D route whose NLRI specifies (C-*,C-*) or + (C-*,C-G), OR + + * P2 is an S-PMSI A-D whose NLRI specifies (C-S,C-G) or + (C-S,C-*), BUT the "single C-source per (C-S,C-G) or (C-S,C-*) + P-tunnel" policy is not provisioned, OR + + * P2 is a Source Active A-D route whose NLRI contains (C-S,C-G). + + As implied by the rules of Section 4.1, there MUST NOT be any RT that + is common to both R1 and R2. In addition, the following set of rules + for RT assignment MUST be followed when extranets are supported. + These rules support all the extranet transmission models described in + this specification: + + o There MUST NOT be any RT that is carried by both P1 and P2. + + o The intersection of the set of RTs carried by P1 and the set of + RTs carried by R1 MUST be non-null, and any VRF that imports both + P1 and R1 MUST be configured with an import RT from this + intersection. + + o The intersection of the set of RTs carried by P2 and the set of + RTs carried by R2 MUST be non-null, and any VRF that imports both + P2 and R2 MUST be configured with an import RT from this + intersection. + + + + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 32] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Suppose that VRF C-1 on PE2 imports P1 and R1 from VRF A-1 while also + importing P2 from VRF B-1. Since + + o R1 is VRF C-1's route to S, + + o R1 has an RT in common with P1, and + + o R1 has no RT in common with P2, + + it can be concluded that VRF C-1 should expect that multicast traffic + from S will arrive on the P-tunnel specified in P1. See Sections 6 + and 7 for more details on determining the expected P-tunnel for a + given extranet C-flow. + + While the assignment of import and export RTs to routes is a + deployment and provisioning issue rather than a protocol issue, it + should be understood that failure to follow these rules is likely to + result in VPN security violations. + +5.2. Considerations for Particular Inclusive Tunnel Types + + An Inclusive Tunnel (sometimes referred to as an "Inclusive Tree"; + see Section 2.1.1 of [RFC6513]) is a tunnel that, by default, carries + all the multicast traffic of a given MVPN that enters the backbone + network via a particular PE. An Inclusive Tunnel is advertised in + the PTA of an I-PMSI A-D route. + +5.2.1. RSVP-TE P2MP or Ingress Replication + + This section applies when Inclusive Tunnels are created using either + RSVP-TE P2MP or IR. + + Suppose that a VRF, say VRF-S, contains a given extranet C-source + C-S, and VRF-S advertises in its Intra-AS I-PMSI A-D route either a + P2MP RSVP-TE P-tunnel or an IR P-tunnel to carry extranet traffic. + + In order for VRF-S to set up the P2MP RSVP-TE or IR P-tunnel, it must + know all the PEs that are leaf nodes of the P-tunnel, and to learn + this it must import an Intra-AS I-PMSI A-D route from every VRF that + needs to receive data through that tunnel. + + Therefore, if VRF-R contains an extranet C-receiver that is allowed + by policy to receive extranet flows from C-S, the RT(s) carried by + the Intra-AS I-PMSI A-D routes originated by VRF-R MUST be such that + those Intra-AS I-PMSI A-D routes will be imported into VRF-S. + + + + + + +Rekhter, et al. Standards Track [Page 33] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + In the case of IR, this has the following consequence: if an egress + PE has n VRFs with receivers for a flow that VRF-S transmits on its + I-PMSI, that egress PE will receive n copies of the same packet, one + for each of the n VRFs. + + Note that Section 9.1.1 of [RFC6514] prohibits the "Leaf Information + Required" flag from being set in the PTA of an Intra-AS I-PMSI A-D + route. If this prohibition is ever removed, the requirement of this + section will apply only if VRF-S does not set that flag. + +5.2.2. Ingress Replication + + This section applies only when Inclusive Tunnels are created via IR. + + [RFC6513] and [RFC6514] specify procedures that allow I-PMSIs to be + instantiated by IR. The concept of an IR P-tunnel, and the + procedures for supporting IR P-tunnels, are explained more fully in + [MVPN-IR]. An IR P-tunnel can be thought of as a P2MP tree in which + a packet is transmitted from one node on the tree to another by being + encapsulated and sent through a unicast tunnel. + + As discussed in Section 2, when I-PMSIs are used to support + extranets, egress PEs MUST have the ability to discard customer + multicast data packets that arrive on the wrong P-tunnel. When + I-PMSIs are instantiated by IR, this implies that the following two + procedures MUST be followed: + + 1. One of the following three procedures MUST be followed: + + a. the "Single Forwarder Selection" procedures of Section 9.1.2 + of [RFC6513] + + b. the "native PIM methods" of Section 9.1.3 of [RFC6513] + + c. the unicast encapsulation used to transmit packets along the + IR P-tunnel is such as to enable the receiving node to + identify the transmitting node (note that this would not be + the case if, for example, the unicast tunnels were MP2P LSPs) + + and + + 2. If a PE assigns an MPLS label value in the PTA of an Intra-AS or + Inter-AS I-PMSI A-D route that it originates, that label value + MUST NOT appear in the PTA of any other I-PMSI or S-PMSI A-D + route originated by the same PE. + + + + + + +Rekhter, et al. Standards Track [Page 34] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Failure to follow these procedures would make it impossible to + discard packets that arrive on the wrong P-tunnel and thus could lead + to duplication of data. + + If it is desired to support extranets while also using IR to + instantiate the PMSIs, an alternative is to use (C-*,C-*) S-PMSIs + instead of I-PMSIs. (See [RFC6625], as well as Sections 7.2.2, + 7.3.2, and 7.4.4 of this document.) This has much the same effect in + the data plane, and there are no restrictions on the type of unicast + tunnel that can be used for instantiating S-PMSIs. + + Section 6.4.5 of [RFC6513] describes a way to support VPNs using + I-PMSIs that are instantiated by IR, using no S-PMSIs, but using + "explicit tracking" to ensure that a C-flow goes only to egress PEs + that have receivers for it. This document does not provide + procedures to support extranets using that model. + +6. When PIM Is the PE-PE C-Multicast Control Plane + + As specified in [RFC6513], when PIM is used as the PE-PE C-multicast + control plane for a particular MVPN, there is a "Multidirectional + Inclusive Provider Multicast Service Interface" (MI-PMSI) for that + MVPN, and all the PEs of that MVPN must be able to send and receive + on that MI-PMSI. Associated with each VRF of the MVPN is a PIM + C-instance, and the PIM C-instance treats the MI-PMSI as if it were a + LAN interface. That is, the "ordinary" PIM procedures run over the + MI-PMSI just as they would over a real LAN interface, except that the + data-plane and control-plane "Reverse Path Forwarding (RPF) checks" + need to be modified. Section 5.2 of [RFC6513] specifies the RPF + check modifications for non-extranet MVPN service. + + For example, suppose that there are two VPNs: VPN-S and VPN-R. In + the absence of extranet support, all the VRFs of VPN-S are connected + via one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of + VPN-R are connected via another ("the VPN-R MI-PMSI"). If we want to + provide extranet service in which the extranet C-sources are attached + to some set of VPN-S VRFs while the extranet C-receivers are attached + to some set of VPN-R VRFs, then we have two choices: + + 1. either the VPN-R VRFs need to join the VPN-S MI-PMSI, or + + 2. the VPN-S VRFs need to join the VPN-R MI-PMSI. + + The first choice is used to support the "single PMSI per C-flow" + transmission model. The second choice is used to support the + "multiple PMSIs per C-flow" transmission model. + + + + + +Rekhter, et al. Standards Track [Page 35] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Procedures for both models are described below. + + To support these models, it must be possible to determine which + I-PMSI A-D routes are associated with the VPN-S I-PMSI and which + I-PMSI A-D routes are associated with the VPN-R I-PMSI. Procedures + are given for assigning RTs to these routes in a way that makes this + determination possible. + + Both models allow the use of S-PMSIs to carry multicast data traffic. + If a VRF containing receivers can receive from multiple MI-PMSIs, + each S-PMSI must be uniquely associated with a particular MI-PMSI. + Procedures are given for assigning RTs to these routes in a way that + makes this determination possible. + + All the procedures specified in Sections 3, 4, and 5 still apply. + + Note that there are no special extranet procedures for Inter-AS + I-PMSI A-D routes or for Leaf A-D routes. Source Active A-D routes + are not used when PIM is the PE-PE C-multicast protocol. + +6.1. Provisioning VRFs with RTs + +6.1.1. Incoming and Outgoing Extranet RTs + + In the absence of extranet service, suppose that each VRF of a given + VPN (call it "VPN-S") is configured with RT-S as its import and + export RT, and that each VRF of a second VPN (call it "VPN-R") is + configured with RT-R as its import and export RT. We will refer to + RT-S and RT-R as "non-extranet RTs". + + Now suppose that VPN-S contains some extranet C-sources and VPN-R + contains some extranet C-receivers that are allowed by policy to + receive extranet C-flows from the VPN-S extranet C-sources. + + To set up this S-to-R extranet, provisioning an additional RT (call + it "RT-S-to-R") whose value is, in general, distinct from RT-S and + RT-R is REQUIRED. + + A VPN-S VRF that contains extranet C-sources allowed to transmit to + VPN-R MUST be configured with RT-S-to-R as an "Outgoing Extranet RT". + + A VPN-R VRF that contains extranet C-receivers allowed to receive + packets from VPN-S MUST be configured with RT-S-to-R as an "Incoming + Extranet RT". + + Note that the terms "Incoming" and "Outgoing" in this context refer + to the direction of multicast data packets relative to the VRF. + + + + +Rekhter, et al. Standards Track [Page 36] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + The Incoming Extranet RTs and Outgoing Extranet RTs that are + configured for a given VRF serve as import RTs for that VRF. They + also serve as export RTs, but only for specific routes as specified + in Section 6.1.2 below. + + Note that any VRF that contains both extranet C-sources and extranet + C-receivers MUST be configured with both Outgoing Extranet RTs and + Incoming Extranet RTs. + + A VRF MAY be configured with more than one Incoming Extranet RT + and/or Outgoing Extranet RT. + + If it happens to be the case that all C-sources in VPN-S are extranet + C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be + configured such that RT-S is both a non-extranet RT and an Outgoing + Extranet RT, and VPN-R VRFs MAY be configured such that RT-S is an + Incoming Extranet RT. + +6.1.2. UMH-Eligible Routes and RTs + + Suppose that R1 is a route exported from a VPN-S VRF and matching an + extranet C-source that is allowed by policy to transmit to VPN-R. In + that case, R1 MUST carry the Outgoing Extranet RT used for the S-to-R + extranet. This will cause the route to be imported into the VPN-R + VRFs that have extranet C-receivers that are allowed by policy to + receive from VPN-S. + + The rules of Section 4 regarding RTs and ambiguous addresses still + apply. + +6.1.3. PIM C-Instance Reverse Path Forwarding Determination + + Suppose that a PIM control message (call it "M") is received by a + given VRF (call it "VRF-V") from a particular P-tunnel T. In order + to process control message M, the PIM C-instance associated with + VRF-V may need to do an "RPF determination" (see Section 5.2.2 of + [RFC6513]) for a particular IP prefix S. RPF determination is based + upon the rules for UMH selection as specified in Section 5.1 of + [RFC6513]. + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 37] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + This document specifies an additional constraint on the UMH selection + procedure. When doing RPF determination for a PIM control message + received over a P-tunnel, a route matching prefix S is not considered + to be eligible for UMH selection unless there is an RT (call it + "RT1"), configured as one of VRF-V's Outgoing Extranet RTs, such that + the following two conditions both hold: + + 1. The route matching S is exported from VRF-V carrying RT1, and + + 2. An I-PMSI A-D route advertising P-tunnel T (in its PTA) has been + imported into VRF-V, and that I-PMSI A-D route carries RT1. + +6.2. "Single PMSI per C-Flow" Model + + In this model, if a VPN-S VRF has extranet multicast C-sources and a + VPN-R VRF has extranet multicast C-receivers allowed by policy to + receive from the C-sources in the VPN-S VRF, then the VPN-R VRF joins + the MI-PMSI that VPN-S uses for its non-extranet traffic. + +6.2.1. Forming the MI-PMSIs + + Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], + each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing + a PTA specifying the P-tunnel to be used as part of the VPN-S + MI-PMSI. In the absence of extranet service, this route carries the + VRF's non-extranet RT, RT-S. When extranet service is provided + (using the "single PMSI per C-flow" model), this route MUST also + carry each of the VRF's Outgoing Extranet RTs. + + Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], + each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing + a PTA specifying the P-tunnel to be used as part of the VPN-R + MI-PMSI. This route carries the VRF's non-extranet RT, RT-R. When + extranet service is provided (using the "single PMSI per C-flow" + model), the VPN-R VRF MUST also originate one or more additional + Intra-AS I-PMSI A-D routes. It MUST originate one additional + Intra-AS I-PMSI A-D route for each Incoming Extranet RT with which it + has been configured; each such route will carry exactly one of the + configured Incoming Extranet RTs. + + Note that when a VRF originates more than one Intra-AS I-PMSI A-D + route, each of them MUST contain a different RD in its NLRI. In + addition, we add the requirement that any pair of such routes + MUST NOT contain an RT in common. + + + + + + + +Rekhter, et al. Standards Track [Page 38] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + A VRF with extranet C-sources MUST join the P-tunnels advertised in + the imported I-PMSI A-D routes that carry its non-extranet RT or any + of its Outgoing Extranet RTs. This set of P-tunnels will be treated + as instantiating a single MI-PMSI; the associated PIM C-instance will + treat that MI-PMSI as a single LAN and will run PIM procedures on + that LAN, as specified in [RFC6513]. The fact that the MI-PMSI + attaches to VRFs of different VPNs is not known to the PIM C-instance + of the VRF containing the sources. + + A VRF with extranet C-receivers MUST join the P-tunnels advertised in + all the imported I-PMSI A-D routes. The set of P-tunnels advertised + in the I-PMSI A-D routes that carry a particular Incoming Extranet RT + are treated as instantiating a particular MI-PMSI. So, a VRF with + C-receivers will "see" several MI-PMSIs, one corresponding to the + non-extranet, and as many as one for each configured Incoming + Extranet RT. The PIM C-instance associated with the VRF will treat + each of these MI-PMSIs as a separate LAN interface. + + As an example, suppose that: + + o All VPN-R VRFs are configured with RT-R as a non-extranet import + and export RT, and + + o VPN-R VRFs with extranet receivers are configured with RT-S-to-R + as an Incoming Extranet RT, and + + o VPN-S VRFs with extranet transmitters are configured with: + + * RT-S as a non-extranet import and export RT + + * a list of IP addresses that are the addresses of the extranet + sources + + * RT-S-to-R as an Outgoing Extranet RT + + VPN-S VRFs will then export UMH-eligible routes matching extranet + C-sources, and these routes will carry both RT-S and RT-S-to-R. Each + VPN-S VRF will also export an Intra-AS I-PMSI A-D route that carries + both RT-S and RT-S-to-R. + + VPN-R VRFs will originate and export two Intra-AS I-PMSI A-D routes: + one carrying RT-R and one carrying RT-S-to-R. The Intra-AS I-PMSI + A-D route with RT-S-to-R will be imported into the VPN-S VRFs. + + VPN-R will regard all the I-PMSI A-D routes it has exported or + imported with RT-S-to-R as part of a single MI-PMSI. VPN-R will + regard all the I-PMSI A-D routes it has exported or imported with + RT-R as part of a second MI-PMSI. The PIM C-instance associated with + + + +Rekhter, et al. Standards Track [Page 39] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + a VPN-R VRF will treat the two MI-PMSIs as two separate LAN + interfaces. However, the VPN-S VRFs will regard all the I-PMSI A-D + routes imported with RT-S or RT-S-to-R as establishing only a single + MI-PMSI. One can think of this as follows: the VPN-R VRFs have + joined the VPN-S MI-PMSI as well as the VPN-R MI-PMSI. + + Extranets consisting of more than two VPNs are easily supported as + follows. Suppose that there are three VPNs: VPN-A, VPN-B, and VPN-C. + VPN-A and VPN-B have extranet C-sources, and VPN-C contains receivers + for both VPN-A extranet C-sources and VPN-B extranet C-sources. In + this case, the VPN-C VRFs that have receivers for both VPN-A and + VPN-B sources may be provisioned as follows. These VPN-C VRFs may be + provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and + RT-B-to-C as Incoming Extranet RTs. In this case, the VPN-C VRFs + that are so provisioned will originate three Intra-AS I-PMSI A-D + routes (each with a different RD in its NLRI), each of which carries + exactly one of the three RTs just mentioned. The VPN-B VRFs with + extranet C-sources will be provisioned with RT-B-to-C as an Outgoing + Extranet RT, and the VPN-A VRFs will be provisioned with RT-A-to-C as + an Outgoing Extranet RT. The result will be that the PIM C-instance + associated with a VPN-C VRF will see three LAN interfaces: one for + the non-extranet and one for each of the two extranets. This + generalizes easily to the case where there are VPN-C receivers in + n different extranets (i.e., receiving extranet flows whose sources + are in n different VPNs). + + Suppose again that there are three VPNs -- VPN-A, VPN-B, and VPN-C -- + but in this example VPN-A is the only one with extranet sources while + VPN-B and VPN-C both have receivers for the VPN-A extranet sources. + This can be provisioned as either one extranet or two extranets. + + To provision it as one extranet, the VPN-A VRFs are configured with + one Outgoing Extranet RT (call it "RT-A-extranet"). The VPN-B and + VPN-C VRFs with extranet receivers will be provisioned with + RT-A-extranet as the Incoming Extranet RT. Thus, the VPN-B and VPN-C + VRFs will each originate two Intra-AS I-PMSI A-D routes: one for the + non-extranet and one for the extranet. From a given VRF, the + Intra-AS I-PMSI A-D route for the extranet will carry RT-A-extranet + but will not share any RT with the non-extranet A-D routes exported + from the same VRF. + + The result is that the VPN-B and VPN-C VRFs each belong to two + MI-PMSIs: one for the extranet and one for the intranet. The MI-PMSI + for the extranet attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs. + + + + + + + +Rekhter, et al. Standards Track [Page 40] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Alternatively, one could provision the VPN-A VRFs so that some + UMH-eligible extranet source routes carry an RT that we will call + "RT-A-to-B" and some carry an RT that we will call "RT-A-to-C". The + VPN-A VRFs would be configured with both of these as Outgoing + Extranet RTs. To allow an extranet flow from a VPN-A source to have + both VPN-B and VPN-C receivers, the UMH-eligible route for that + source would carry both RTs. VPN-B VRFs (but not VPN-C VRFs) would + be provisioned with RT-A-to-B as an Incoming Extranet RT. VPN-C VRFs + (but not VPN-B VRFs) would be provisioned with RT-A-to-C as an + Incoming Extranet RT. + + Following the rules above, if any VPN-A extranet source is to have + both VPN-B and VPN-C receivers, the VPN-B and VPN-C VRFs will each + originate two I-PMSI A-D routes: one for the extranet and one for the + non-extranet. The single Intra-AS I-PMSI A-D route originated by the + VPN-A VRFs will have both RT-A-to-B and RT-A-to-C among its RTs (as + well as VPN-A's non-extranet RT). The extranet I-PMSI A-D route + originated from a VPN-B VRF would have RT-A-to-B, and the extranet + I-PMSI A-D route originated from a VPN-C VRF would have RT-A-to-C. + + If a given VRF contains both extranet C-receivers and extranet + C-sources, the procedures described above still work, as the VRF will + be configured with both Incoming Extranet RTs and Outgoing Extranet + RTs; the VRF functions as both a VPN-S VRF and a VPN-R VRF. + +6.2.2. S-PMSIs + + When PIM is used as the PE-PE C-multicast control plane, every S-PMSI + is considered to be part of the "emulated LAN" that "corresponds" to + a particular MI-PMSI. + + When the bindings of C-flows to particular S-PMSIs are announced via + S-PMSI Join messages (Section 7 of [RFC6513]) sent on the MI-PMSI, + the S-PMSI is considered to be part of the same LAN interface as the + corresponding MI-PMSI. + + When the bindings of C-flows to particular S-PMSIs are announced via + S-PMSI A-D routes, any S-PMSI A-D route exported from that VRF MUST + have an RT in common with exactly one of the Intra-AS A-D routes + exported from that VRF, and this MUST be one of the VRF's Outgoing + Extranet RTs. Further, the S-PMSI A-D route MUST NOT have an RT in + common with any other Intra-AS A-D route exported from a VRF on the + same PE. A given S-PMSI A-D route will be considered to "correspond" + to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the + same PE) with which it shares an RT. + + + + + + +Rekhter, et al. Standards Track [Page 41] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + The MI-PMSI that corresponds to a given S-PMSI is determined as + follows: + + o If (1) there is an Intra-AS I-PMSI A-D route originated by the + same PE that originated the S-PMSI A-D route, (2) those two routes + have an RT in common, and (3) that RT is one of the VRF's Incoming + Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated + with that Intra-AS I-PMSI A-D route. + + o Otherwise, if (1) there is an Inter-AS I-PMSI A-D route originated + in the same AS as the S-PMSI A-D route, (2) those two routes have + an RT in common, and (3) that RT is one of the VRF's Incoming + Extranet RTs, then the S-PMSI corresponds to the I-PMSI associated + with that Inter-AS I-PMSI A-D route. + + o Otherwise, there must be a configuration error (a violation of the + requirements of Sections 3, 4, and 5 of this document). + + When wildcard S-PMSIs are used, the rules given in [RFC6625] for + determining whether a given S-PMSI A-D route is a "match for + reception" to a given (C-S,C-G) or (C-*,C-G) are modified as follows: + + A given S-PMSI A-D route MUST NOT be considered to be a "match for + reception" for a given (C-S,C-G) or (C-*,C-G) state UNLESS that + S-PMSI A-D route "corresponds" (as defined above) to the MI-PMSI + that is the incoming interface for the given state. + + The rules given in [RFC6625] for determining whether a given S-PMSI + A-D route is a "match for transmission" are unchanged. + +6.2.3. Sending PIM Control Packets + + Suppose that a PE, say PE1, receives a PIM Join(S,G) from a CE, over + a VRF interface that is associated with a VPN-R VRF. The PE does the + RPF check for S by looking up S in the VPN-R VRF. The PIM C-instance + associated with that VRF must determine the correct P-tunnel over + which to send a PIM Join(S,G) to other PEs. + + To do this, PE1 finds, in the VRF associated with the interface over + which the Join was received, the selected UMH route for S, following + the procedures of Section 5.1 of [RFC6513]. PE1 determines the set + of RTs carried by that route. PE1 then checks to see if there is an + Intra-AS I-PMSI A-D route, currently originated by PE1, that has an + RT in common with the selected UMH route for S. + + + + + + + +Rekhter, et al. Standards Track [Page 42] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + If the rules of Sections 3, 4, and 5 have been followed, each of + PE1's selected UMH routes will share an RT with a single one of PE1's + currently originated Intra-AS I-PMSI A-D routes. If this is so, the + Join is sent on the P-tunnel advertised in the PTA of that route. + Otherwise, the Join MUST NOT be sent. + + In essence, this procedure makes the RPF check for C-S resolve to the + MI-PMSI that is serving as the next-hop "interface" to C-S. + + If a PE receives a PIM Join(*,G) from a CE, the procedure for doing + the RPF check is the same, except that the selected UMH route will be + a route to the C-RP associated with the C-G group. + +6.2.4. Receiving PIM Control Packets + + When a PIM C-instance receives a PIM control message from a P-tunnel, + it needs to identify the message's incoming interface. This incoming + interface is the MI-PMSI of which the P-tunnel is a part. + +6.2.5. Sending and Receiving Data Packets + + The rules for choosing the PMSI on which to send a multicast data + packet are as specified in [RFC6513] and [RFC6625], with one new + restriction: a VPN-S VRF always transmits a multicast data packet + either on the VPN-S MI-PMSI or on an S-PMSI that corresponds to the + VPN-S MI-PMSI. From the perspective of the PIM C-instance, there is + only one outgoing interface. + + When a PIM C-instance receives a multicast data packet from a given + P-tunnel and that P-tunnel is being used to instantiate an MI-PMSI, + the MI-PMSI of which the P-tunnel is a part (see Sections 6.2.1 and + 6.2.2) is considered to be the packet's incoming interface. If the + packet is received on a P-tunnel that was advertised in an S-PMSI A-D + route, the packet's incoming interface is the MI-PMSI to which that + S-PMSI route corresponds, as defined in Section 6.2.2. Ordinary PIM + rules for data-plane RPF checks apply. + + Following ordinary PIM procedures, packets arriving from an + unexpected incoming interface are discarded. This eliminates any + problems due to the ambiguities described in Sections 2.1 and 2.2. + +6.3. "Multiple PMSIs per C-Flow" Model + + In this model, if a VPN-S VRF has extranet multicast C-sources and a + VPN-R VRF has extranet multicast C-receivers allowed by policy to + receive from the C-sources in the VPN-S VRF, then the VPN-S VRF joins + the MI-PMSI that VPN-R uses for its non-extranet traffic. + + + + +Rekhter, et al. Standards Track [Page 43] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + In the "single PMSI per C-flow" transmission model (as described in + Section 6.2), a PE that needs to transmit a multicast data packet to + a set of other PEs transmits the packet on a single PMSI. This means + that if a packet needs to be transmitted from a VPN-A VRF and + received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel + from which the VPN-B and VPN-C VRFs can both receive packets. + + In the "multiple PMSIs per C-flow" transmission model, a PE that + needs to transmit a multicast data packet to a set of other PEs may + transmit the packet on several different PMSIs. (Of course, any + given packet is transmitted only once on a given P-tunnel.) For + example, if a C-flow (C-S,C-G) has a VPN-A C-source, a VPN-B + receiver, and a VPN-C receiver, there could be one PMSI that the + VPN-A VRF uses to transmit the packet to the VPN-B VRFs and + another PMSI that the VPN-A VRF uses to transmit the packet to the + VPN-C VRFs. + +6.3.1. Forming the MI-PMSIs + + Consider a VPN-R VRF that has extranet C-receivers. Per [RFC6513], + each VPN-R VRF must originate an Intra-AS I-PMSI A-D route containing + a PTA specifying the P-tunnel to be used as part of the VPN-R + MI-PMSI. In the absence of extranet service, this route carries the + VRF's non-extranet RT, RT-R. When extranet service is provided + (using the "single PMSI per C-flow" model), this route MUST also + carry each of the VRF's Incoming Extranet RTs. + + Consider a VPN-S VRF that has extranet C-sources. Per [RFC6513], + each VPN-S VRF must originate an Intra-AS I-PMSI A-D route containing + a PTA specifying the P-tunnel to be used as part of the VPN-S + MI-PMSI. This route carries the VRF's non-extranet RT, RT-S. When + extranet service is provided using the "multiple PMSIs per C-flow" + model, the VPN-S VRF MUST also originate one or more additional + Intra-AS I-PMSI A-D routes. It MUST originate one additional + Intra-AS I-PMSI A-D route for each Outgoing Extranet RT with which it + has been configured; each such route will have a distinct RD and will + carry exactly one of the configured Outgoing Extranet RTs. + + As with the "single PMSI per C-flow" transmission model, VRFs + containing extranet C-receivers need to import UMH-eligible extranet + C-source routes from VRFs containing C-sources. This is ensured by + the rules of Sections 3, 4, and 5. + + However, in the "multiple PMSIs per C-flow" model, a VRF containing + only C-receivers originates only a single Intra-AS I-PMSI A-D route + carrying the non-extranet RT and all the Incoming Extranet RTs. + + + + + +Rekhter, et al. Standards Track [Page 44] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + When a VRF containing C-receivers imports Intra-AS I-PMSI A-D routes + that carry the non-extranet RT or one of the Incoming Extranet RTs, + the P-tunnels specified in the PTA of all such routes are considered + to be part of the same MI-PMSI. That is, the associated PIM + C-instance will treat them as part of a single interface. + + In this model, it is the VRF containing extranet C-sources that MUST + originate multiple Intra-AS I-PMSI A-D routes. Each such route MUST + have a distinct RD, and the set of RTs carried by any one of these + routes MUST be disjoint from the set carried by any other. There + MUST be one such route for each of the VRF's Outgoing Extranet RTs, + and each such route MUST carry exactly one of the VRF's Outgoing + Extranet RTs. The VRFs containing extranet C-sources MUST also + import all the A-D routes originated by the VRFs containing extranet + C-receivers. If a set of originated and/or imported Intra-AS I-PMSI + A-D routes have an RT in common and that RT is one of the VRF's + Outgoing Export RTs, then those routes are considered to be "about" + the same MI-PMSI. The PIM C-instance of the VRF treats each MI-PMSI + as a LAN interface. + + In effect, if VPN-S has only extranet C-sources and VPN-R has only + extranet C-receivers, this model has the VPN-S VRFs join the VPN-R + MI-PMSI. The VPN-S VRFs will thus be attached to multiple MI-PMSIs, + while the VPN-R VRFs are attached to only one. The fact that the + VPN-R MI-PMSI is attached to VPN-S VRFs is not known to the PIM + C-instance at the VPN-R VRFs. + + If a VPN-A VRF has extranet C-sources allowed to send to C-receivers + in a VPN-B VRF and the VPN-B VRF has C-sources allowed to send to + C-receivers in the VPN-A VRF, the above procedures still work as + specified. + + Following normal PIM procedures, when the PIM C-instance at a VRF + with extranet C-sources receives a Join(C-S,C-G) or a Join(C-*,C-G) + over an MI-PMSI, it may create (C-S,C-G) or (C-*,C-G) state, and the + MI-PMSI over which the Join was received may be added to the set of + outgoing interfaces for that multicast state. If n MI-PMSIs are + added to the outgoing interface list for a particular multicast + state, a multicast data packet may need to be replicated n times and + transmitted once on each of the n MI-PMSIs. + + Since all of the multicast data packets received from another PE are + received over a single emulated LAN, it is not necessary to have any + special procedures to determine a packet's incoming interface. The + ambiguities described in Sections 2.1 and 2.2 do not occur, because a + VPN-R VRF can only receive multicast data traffic that has been + requested by a VPN-R VRF. + + + + +Rekhter, et al. Standards Track [Page 45] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +7. When BGP Is the PE-PE C-Multicast Control Plane + + This document assumes that if BGP is used as the PE-PE C-multicast + control plane, the "single PMSI per C-flow" model is used. + Procedures for providing the "multiple PMSIs per C-flow" model with + BGP C-multicast are outside the scope of this document. + + When BGP is used as the C-multicast control plane, the "single PMSI + per C-flow" model may be used either with or without extranet + separation. (Recall that "extranet separation" means that no + P-tunnel can carry traffic from both extranet sources and + non-extranet sources.) In either case, the data traffic may be + carried on Inclusive Tunnels only, Selective Tunnels only (known as + the "S-PMSI only" model), or a combination of Inclusive Tunnels and + Selective Tunnels. This is determined by provisioning. The + procedures specified below support all three choices. + + Note that there are no special extranet procedures for Inter-AS + I-PMSI A-D routes or for Leaf A-D routes. + +7.1. Originating C-Multicast Routes + + This section applies whether extranet separation is used or not. + + When it is necessary to originate a C-multicast Source Tree Join for + (C-S,C-G), a PE must follow the procedures of Section 11.1.3 + ("Constructing the Rest of the C-Multicast Route") of [RFC6514] to + find the selected UMH route for C-S. When it is necessary to + originate a C-multicast Shared Tree Join for (C-*,C-G), where C-G is + an ASM group, a PE must follow the procedures of that section to find + the selected UMH route for C-G's C-RP. + + Section 11.1.3 of [RFC6514] specifies how information from the + selected UMH route is used to find an Intra-AS I-PMSI A-D route or an + Inter-AS I-PMSI A-D route. Information from that I-PMSI A-D route is + then used to construct part of the C-multicast route. + + For extranets, the rules given in Section 7.4.5 of this document are + used to find the Inter-AS I-PMSI A-D route or an Intra-AS I-PMSI A-D + route that "corresponds" to the selected UMH route; the rules in + Section 7.4.5 replace the rules given in Section 11.1.3 of [RFC6514] + for finding the Inter-AS or Intra-AS I-PMSI A-D route. + + Information from this I-PMSI A-D route is then used, as specified in + Section 11.1.3 of [RFC6514], to construct the C-multicast route. + + + + + + +Rekhter, et al. Standards Track [Page 46] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +7.2. Originating A-D Routes without Extranet Separation + +7.2.1. Intra-AS I-PMSI A-D Routes + + Consider a VRF (call it "VRF-S") that contains extranet C-sources and + exports UMH-eligible routes matching those C-sources. The VRF may + also originate and export an Intra-AS I-PMSI A-D route. + + As specified in [RFC6514], if exactly one Intra-AS I-PMSI A-D route + is originated by and exported from VRF-S, the RTs carried by that + route MUST be chosen such that every VRF that imports a UMH-eligible + route from VRF-S also imports this Intra-AS I-PMSI A-D route. + + If inclusive P-tunnels are being used to carry extranet C-flows, + there are additional requirements on the way the RTs carried by the + Intra-AS I-PMSI A-D routes must be chosen, as specified in the + following paragraph. + + If VRF-S is using inclusive P-tunnels but is not using extranet + separation, there is one inclusive P-tunnel rooted at VRF-S, and this + tunnel carries both extranet and non-extranet C-flows. This + Inclusive Tunnel is identified in the PTA of the Intra-AS I-PMSI A-D + route originated from VRF-S. The set of RTs carried by this Intra-AS + I-PMSI A-D route MUST be chosen so as to ensure that every VRF that + imports a UMH-eligible route from this VRF-S also imports this + Intra-AS I-PMSI A-D route. Further, the set of RTs carried by this + Intra-AS I-PMSI A-D route MUST be chosen such that it has at least + one RT in common with every UMH-eligible route that is exported from + the VRF. + +7.2.2. S-PMSI A-D Routes + + Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose + that R-SP is used to bind some or all of the extranet C-flows from a + given extranet C-source to a given selective P-tunnel. Let R-UMH be + a UMH-eligible route that is exported from VRF-S and matches the + given extranet C-source. In that case, R-SP and R-UMH MUST have at + least one RT in common. Further, the RTs carried by these two routes + MUST be such that every VRF that imports R-UMH also imports R-SP. + These rules apply whether or not R-SP uses wildcards [RFC6625]. + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 47] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + An implementation MUST allow the set of RTs carried by the S-PMSI A-D + routes to be specified by configuration. In the absence of such + configuration, an S-PMSI A-D route originated by a given VRF, say + VRF-X, MUST carry a default set of RTs, as specified by the following + rules: + + 1. By default, an S-PMSI A-D route originated by VRF-X for a given + (C-S,C-G) or (C-S,C-*) carries the same RT(s) as the UMH-eligible + route originated by VRF-X that matches C-S. + + 2. By default, an S-PMSI A-D route originated by VRF-X for a given + (C-*,C-G) carries as its RTs a set union of all RT(s) of the + UMH-eligible route(s) matching the multicast C-sources contained + in VRF-X that could originate traffic for that C-G. Moreover, if + the VRF contains (as defined in Section 1.1) the C-RP of C-G, + then this set union also includes the RT(s) of the UMH-eligible + route matching C-RP and the RT(s) of the unicast VPN-IP route + matching C-RP. + + 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X + is to be used for both extranet and non-extranet traffic, it + carries the same RTs that would be carried (as specified in + Section 7.2.1) by an I-PMSI A-D route originated by VRF-X if that + I-PMSI A-D route were advertising an inclusive P-tunnel for + carrying both extranet and non-extranet traffic. In general, a + given VRF would not originate both (a) an S-PMSI A-D route + advertising a (C-*,C-*) selective P-tunnel for both extranet and + non-extranet traffic and (b) an I-PMSI A-D route advertising an + inclusive P-tunnel for both extranet and non-extranet traffic, as + the inclusive P-tunnel would not get used in that case. + +7.2.3. Source Active A-D Routes + +7.2.3.1. When Inter-Site Shared Trees Are Used + + This section applies when inter-site shared trees are used, as + specified in Section 13 of [RFC6514]. + + If VRF-S exports a Source Active A-D route that contains C-S in the + Multicast Source field of its NLRI and VRF-S also exports a + UMH-eligible route matching C-S, the Source Active A-D route MUST + carry at least one RT in common with the UMH-eligible route. The RT + MUST be chosen such that the following condition holds: if a VRF, say + VRF-R, contains an extranet C-receiver allowed by policy to receive + extranet traffic from C-S, then VRF-R imports both the UMH-eligible + route and the Source Active A-D route. + + + + + +Rekhter, et al. Standards Track [Page 48] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + By default, a Source Active A-D route for a given (C-S,C-G), exported + by a given VRF, carries the same set of RTs as the UMH-eligible route + matching C-S that is exported from that VRF. + +7.2.3.2. When Inter-Site Shared Trees Are Not Used + + This section applies when inter-site shared trees are not used, as + specified in Section 14 of [RFC6514]. + + Suppose that a VRF, say VRF-X, contains the C-RP for a given extranet + C-group, say C-G. If C-S is an active source for C-G, then, + following the procedures of Section 14.1 of [RFC6514], VRF-X may + export a Source Active A-D route that contains C-S in the Multicast + Source field of its NLRI. With the following text, this document + replaces the rule specified in Section 14.1 of [RFC6514] for + constructing the RT(s) carried by such a route: VRF-X MUST be + configured such that the Source Active A-D route for (C-S,C-G) + carries the same set of RTs as the UMH-eligible route matching C-S + that is exported from the VRF(s) containing C-S. This way, if a VRF, + say VRF-R, contains an extranet C-receiver allowed by policy to + receive extranet traffic from C-S, then VRF-R imports both the + UMH-eligible route and the Source Active A-D route. + +7.3. Originating A-D Routes with Extranet Separation + + If a VRF contains both extranet C-sources and non-extranet C-sources, + it MUST be configured with both a default RD and an extranet RD (see + Section 1.3). The use of these RDs is explained in the following + subsections. + +7.3.1. Intra-AS I-PMSI A-D Routes + + This section applies when VRF-S is using extranet separation AND when + VRF-S is using an inclusive P-tunnel to carry some or all of the + extranet C-flows that it needs to transmit to other VRFs. + + If VRF-S contains both extranet C-sources and non-extranet C-sources, + and inclusive P-tunnels are used to carry both extranet C-flows and + non-extranet C-flows, then there MUST be two Inclusive Tunnels from + VRF-S, one of which is to be used only to carry extranet C-flows (the + "extranet inclusive P-tunnel") and one of which is to be used only to + carry non-extranet C-flows (the "non-extranet inclusive P-tunnel"). + + + + + + + + + +Rekhter, et al. Standards Track [Page 49] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + In this case, the VRF MUST originate two Intra-AS I-PMSI A-D routes. + Their respective NLRIs MUST of course have different RDs. One of the + Intra-AS I-PMSI A-D routes identifies the extranet inclusive P-tunnel + in its PTA. This route MUST have the VRF's extranet RD in its NLRI. + The other route identifies the non-extranet inclusive P-tunnel in its + PTA. This route MUST have the VRF's default RD in its PTA. + + If VRF-S uses an inclusive P-tunnel for carrying extranet traffic but + does not use an inclusive P-tunnel for carrying non-extranet traffic, + then of course only a single Intra-AS I-PMSI A-D route need be + originated. The PTA of this route identifies the "extranet inclusive + P-tunnel". The NLRI of that route MUST contain the VRF's + extranet RD. + + An Intra-AS I-PMSI A-D route whose PTA identifies an extranet + inclusive P-tunnel MUST carry the Extranet Separation Extended + Community defined in Section 4.5. + + The RTs carried by an Intra-AS I-PMSI A-D route whose PTA identifies + the "extranet inclusive P-tunnel" MUST be chosen such that the + following condition holds: if a VRF (call it "VRF-R") imports a + UMH-eligible route from VRF-S and that route matches an extranet + C-source, then VRF-R also imports that Intra-AS I-PMSI A-D route. + + Note that when extranet separation is used, it is possible to use an + inclusive P-tunnel for non-extranet traffic while using only + selective P-tunnels for extranet traffic. It is also possible to use + an inclusive P-tunnel for extranet traffic while using only selective + P-tunnels for non-extranet traffic. + +7.3.2. S-PMSI A-D Routes + + Let R-SP be an S-PMSI A-D route that is exported from VRF-S. Suppose + that R-SP is used to bind some or all of the extranet C-flows from a + given extranet C-source to a given selective P-tunnel. Let R-UMH be + a UMH-eligible route that is exported from VRF-S and matches the + given extranet C-source. In that case, R-SP and R-UMH MUST have at + least one RT in common. Further, the RTs carried by these two routes + MUST be such that every VRF that imports R-UMH also imports R-SP. + These rules apply whether or not R-SP uses wildcards [RFC6625]. + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 50] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + The following rules, specific to the use of extranet separation, + apply: + + o A selective P-tunnel MUST NOT carry C-flows from both extranet and + non-extranet C-sources. + + o If it is desired to use a (C-*,C-*) S-PMSI to carry extranet + traffic and also use a (C-*,C-*) S-PMSI to carry non-extranet + traffic, then two (C-*,C-*) S-PMSI A-D routes MUST be originated. + These two routes MUST have different RDs in their respective NLRI + fields, and their respective PTAs MUST identify different + P-tunnels. If the route advertises a P-tunnel that carries only + non-extranet traffic, the route's NLRI MUST contain the VRF's + default RD. If the route advertises a P-tunnel that carries only + extranet traffic, the route's NLRI MUST contain the VRF's + extranet RD. + + o In the following cases, an S-PMSI A-D route exported from the VRF + MUST have the VRF's extranet RD in its NLRI: + + * The S-PMSI A-D route is a (C-S,C-G) or a (C-S,C-*) S-PMSI A-D + route, and C-S is an extranet C-source. + + * The S-PMSI A-D route is a (C-*,C-G) S-PMSI A-D route, and C-G + is an extranet C-group. + + In all other cases, a (C-S,C-G), (C-S,C-*), or (C-*,C-G) S-PMSI + A-D route MUST have the VRF's default RD in its NLRI. + + o A (C-*,C-*) S-PMSI A-D route advertising a P-tunnel that is used + to carry extranet traffic MUST carry the Extranet Separation + Extended Community defined in Section 4.5. + + An implementation MUST allow the set of RTs carried by the S-PMSI A-D + routes to be specified by configuration. In the absence of such + configuration, an S-PMSI A-D route originated by a given VRF, say + VRF-X, MUST carry a default set of RTs, as specified by the following + rules: + + 1. Rule 1 of Section 7.2.2 applies. + + 2. By default, if C-G is an extranet C-group, rule 2 of + Section 7.2.2 applies. + + 3. By default, if a (C-*,C-*) S-PMSI A-D route originated by VRF-X + is to be used for extranet traffic, it carries the same RTs that + would be carried (as specified in Section 7.3.1) by an I-PMSI A-D + route originated by VRF-X if that I-PMSI A-D route were + + + +Rekhter, et al. Standards Track [Page 51] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + advertising an inclusive P-tunnel for carrying extranet traffic. + In general, a given VRF would not originate both an S-PMSI A-D + route advertising a (C-*,C-*) selective P-tunnel for extranet + traffic and an I-PMSI A-D route advertising an inclusive P-tunnel + for extranet traffic, as the inclusive P-tunnel would not get + used in that case. + +7.3.3. Source Active A-D Routes + + The procedures of Section 7.2.3 apply. + + However, if a Source Active A-D route is exported from a given VRF + and the route contains C-S, where C-S is an extranet C-source, then + the RD of the route's NLRI MUST be the extranet RD of the VRF. + Otherwise, the RD is the default RD of the VRF. + +7.4. Determining the Expected P-Tunnel for a C-Flow + + This section applies whether extranet separation is used or not. + + In the context of a VRF with receivers for a particular C-flow, a PE + must determine the P-tunnel over which packets of that C-flow are + expected to arrive. This is done by finding an I-PMSI or S-PMSI A-D + route that "matches" the flow. The matching A-D route will contain a + PTA that specifies the P-tunnel being used to carry the traffic of + that C-flow. We will refer to this P-tunnel as the "expected + P-tunnel" for the C-flow. (Note that, per [MVPN-IR], if the PTA + specifies a tunnel of type "Ingress Replication" (IR), the identifier + of the P-tunnel is actually the NLRI of the I-PMSI or S-PMSI A-D + route. If the PTA specifies a tunnel type other than IR, the + identifier of the P-tunnel is found in the Tunnel Identifier field of + the PTA.) + + A PE that needs to receive a given (C-S,C-G) or (C-*,C-G) C-flow MUST + join the expected P-tunnel for that C-flow, and the PE MUST remain + joined to the P-tunnel as long as (1) the PE continues to need to + receive the given C-flow and (2) the P-tunnel continues to remain the + expected P-tunnel for that C-flow. Procedures for joining and + leaving a tunnel depend, of course, on the tunnel type. + + If a PTA specifies a non-zero MPLS label for a tunnel that is not an + IR tunnel, then the PE originating the A-D route containing that PTA + is advertising an aggregate P-tunnel. The aggregate P-tunnel can be + thought of as an outer P-tunnel multiplexing some number of inner + P-tunnels. The inner P-tunnels are demultiplexed by means of the + MPLS label in the PTA. In this document, when we talk of the + "expected P-tunnel" in the context of an aggregate P-tunnel, we refer + + + + +Rekhter, et al. Standards Track [Page 52] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + to a particular inner P-tunnel, not to the outer P-tunnel. It is + this "inner P-tunnel" that is the expected P-tunnel for a given + C-flow. + + In order to find the expected P-tunnel for a given C-flow, the + upstream PE of the C-flow is first determined. Then, the S-PMSI A-D + routes originated by that PE are examined, and their NLRIs compared + to the (C-S/C-RP,C-G) of the flow, to see if there is a "match for + reception". (If there is no S-PMSI A-D route that matches a given + C-flow, the expected P-tunnel for that C-flow may have been + advertised in an I-PMSI A-D route; see Section 7.4.5.) + + The rules for determining, in non-extranet cases, whether a given + C-flow is a "match for reception" for a given S-PMSI A-D route are + given in Section 3.2 of [RFC6625]. Note that we use the terms + "installed" and "originated" as they are defined in Section 3.2 of + [RFC6625]. (See also Section 1.1 of this document.) + + This specification provides additional rules for determining whether + a given S-PMSI A-D route is a "match for reception" for a given + (C-S/C-RP,C-G). Note that these rules all assume the context of a + particular VRF into which the A-D route has been imported. + + The rules given in [RFC6625] for determining whether a given S-PMSI + A-D route is a "match for transmission" remain unchanged. + + Suppose that a PE has originated a C-multicast Shared Tree Join for + (C-*,C-G) but has not originated a C-multicast Source Tree Join for + (C-S,C-G). Suppose also that the PE has received and installed a + Source Active A-D route for (C-S,C-G). As described in Section 13.2 + of [RFC6514], the PE must receive the (C-S,C-G) traffic from the + tunnel the originator of the installed Source Active A-D route uses + for sending (C-S,C-G). + + The originator of the installed Source Active A-D route is determined + as follows: + + 1. Look at the "UMH Route Candidate Set" for C-S, as defined in + Section 5.1.3 of [RFC6513]. + + 2. From that set, select a subset of UMH routes to C-S, such that + each route in the subset has at least one RT in common with the + Source Active A-D route and at least one of the RTs in common is + an import RT of the VRF. + + 3. From that subset, find the route whose RD is the same as the RD + from the NLRI of the Source Active A-D route. + + + + +Rekhter, et al. Standards Track [Page 53] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + 4. The upstream PE is the PE identified in the VRF Route Import + Extended Community of that route. + + 5. The upstream AS is the AS identified in the Source AS Extended + Community of that route. + + If step 2 results in an empty set or step 3 fails to find a route, + then the upstream PE of the Source Active A-D route cannot be + determined, and it is necessary to act as if the Source Active A-D + route had not been installed. (A subsequent change to the UMH Route + Candidate Set for C-S may require that a new attempt be made to + determine the upstream PE.) + + Once the upstream PE is determined, the P-tunnel over which the flow + is expected is determined according to the procedures already + described in this section. + +7.4.1. (C-S,C-G) S-PMSI A-D Routes + + When extranet functionality is being provided, an S-PMSI A-D route + whose NLRI contains (C-S,C-G) is NOT considered to be a "match for + reception" for a given C-flow (C-S,C-G) unless one of the following + conditions holds (in addition to the conditions specified in + [RFC6625]): + + o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is + provisioned, or + + o the selected UMH route for C-S has at least one RT in common with + the S-PMSI A-D route, and at least one of the common RTs is an + import RT of the VRF. + +7.4.2. (C-S,C-*) S-PMSI A-D Routes + + When extranet functionality is being provided, an S-PMSI A-D route + whose NLRI contains (C-S,C-*) is NOT considered to be a "match for + reception" for a given C-flow (C-S,C-G) unless one of the following + conditions holds (in addition to the conditions specified in + [RFC6625]): + + o the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is + provisioned, or + + o the selected UMH route for C-S has at least one RT in common with + the S-PMSI A-D route, and at least one of the common RTs is an + import RT of the VRF. + + + + + +Rekhter, et al. Standards Track [Page 54] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +7.4.3. (C-*,C-G) S-PMSI A-D Routes + + When extranet functionality is being provided, an S-PMSI A-D route + whose NLRI contains (C-*,C-G) is NOT considered to be a "match for + reception" for a given C-flow (C-S,C-G) in a given VRF unless either + condition 1 or condition 2 below holds (in addition to the conditions + specified in [RFC6625]): + + 1. The given VRF has currently originated a C-multicast Shared Tree + Join route for (C-*,C-G), and + + a. (C-*,C-G) matches an installed (C-*,C-G) S-PMSI A-D route + (according to [RFC6625]) in the given VRF, and + + b. either + + i. the "single C-group per (C-*,C-G) P-tunnel" policy has + been provisioned, or + + ii. the RTs of that S-PMSI A-D route form a non-empty + intersection with the RTs carried in the VRF's + selected UMH route for C-RP of that C-G, or + + iii. installed in the VRF is at least one (C-S,C-G) Source + Active A-D route that was originated by the same PE as + the (C-*,C-G) S-PMSI A-D route. + + 2. The given VRF does not have a currently originated C-multicast + Shared Tree Join for (C-*,C-G), but + + a. there are one or more values for C-S for which the VRF has a + currently originated Source Tree Join C-multicast route for + (C-S,C-G), and + + b. the (C-* C-G) S-PMSI A-D route matches (according to + [RFC6625]) each such (C-S,C-G), and + + c. either + + i. the "single C-group per (C-*,C-G) P-tunnel" policy has + been provisioned, or + + ii. the RTs of that S-PMSI A-D route form a non-empty + intersection with the RTs carried in the VRF's selected + UMH routes for each such C-S + + + + + + +Rekhter, et al. Standards Track [Page 55] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + If a VRF has an installed (C-*,C-G) S-PMSI A-D route but does not + have a (C-S,C-G) or (C-*,C-G) multicast state that matches that + route for reception, the procedures of Section 12.3 ("Receiving + S-PMSI A-D Routes by PEs") of [RFC6514] are not invoked for that + route. If those multicast states are created at some later time + when the route is still installed, the procedures of Section 12.3 + of [RFC6514] are invoked at that time. + +7.4.4. (C-*,C-*) S-PMSI A-D Routes + + A (C-*,C-*) S-PMSI A-D route (call it "R-AD") is NOT considered to be + a "match for reception" for a given C-flow (C-S,C-G) or (C-*,C-G) + unless the following conditions hold (in addition to the conditions + specified in [RFC6625]): + + o The selected UMH route (call it "R-UMH") for C-S or for C-G's + C-RP, respectively, has at least one RT in common with R-AD, and + at least one of the common RTs is an import RT of the VRF. + + o Either R-AD and R-UMH both carry the Extranet Separation Extended + Community or neither carries the Extranet Separation Extended + Community. + +7.4.5. I-PMSI A-D Routes + + If a particular egress VRF in a particular egress PE contains no + matching S-PMSI A-D routes for a particular C-flow, then the C-flow + is expected to arrive (at that egress VRF) on an inclusive P-tunnel. + + Suppose that an egress PE has originated a (C-S,C-G) C-multicast + Source Tree Join. Let R-UMH be the selected UMH route (in the given + egress VRF) for C-S. As specified in [RFC6514], the selected + upstream PE for (C-S,C-G) is determined from the VRF Route Import + Extended Community of R-UMH, and the "selected upstream AS" for the + flow is determined from the Source AS Extended Community of R-UMH. + + Suppose that an egress PE has originated a (C-*,C-G) C-multicast + Shared Tree Join but has not originated a (C-S,C-G) C-multicast + Source Tree Join. If the egress VRF does not have a (C-S,C-G) Source + Active A-D route installed, the selected upstream PE is determined + from the VRF Route Import Extended Community of the installed + UMH-eligible route matching C-RP, where C-RP is the RP for the group + C-G. The selected upstream AS for the flow is determined from the + Source AS Extended Community of that route. If the egress VRF does + have a (C-S,C-G) Source Active A-D route installed, the selected + upstream PE and upstream AS are determined as specified in + Section 7.4. In either case, let R-UMH be the installed UMH-eligible + route matching C-S. + + + +Rekhter, et al. Standards Track [Page 56] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + The inclusive P-tunnel that is expected to be carrying a particular + C-flow is found as follows: + + o If the selected upstream AS is the local AS or segmented Inter-AS + P-tunnels are not being used to instantiate I-PMSIs, then look in + the VRF for an installed Intra-AS I-PMSI A-D route, R-AD, such + that (a) R-AD is originated by the selected upstream PE, (b) R-AD + has at least one RT in common with R-UMH, (c) at least one of the + common RTs is an import RT of the local VRF, and (d) either R-AD + and R-UMH both carry the Extranet Separation Extended Community or + neither carries the Extranet Separation Extended Community. + + The PTA of R-AD specifies the P-tunnel over which the traffic of + the given C-flow is expected. + + o If the selected upstream AS is not the local AS and segmented + Inter-AS P-tunnels are being used to instantiate I-PMSIs, then + look in the VRF for an installed Inter-AS I-PMSI A-D route, R-AD, + such that (a) the Source AS field of R-AD's NLRI contains the AS + number of the selected upstream AS, (b) R-AD has at least one RT + in common with R-UMH, (c) at least one of the common RTs is an + import RT of the local VRF, and (d) either R-AD and R-UMH both + carry the Extranet Separation Extended Community or neither + carries the Extranet Separation Extended Community. + + The PTA of R-AD specifies the P-tunnel over which the traffic of + the given C-flow is expected. + +7.5. Packets Arriving from the Wrong P-Tunnel + + Any packets that arrive on a P-tunnel other than the expected + P-tunnel (as defined in Section 7.4) MUST be discarded unless it is + known that all the packets carried by both P-tunnels are from the + same ingress VRF. (See Section 2.3.1 for a more detailed discussion + of when to discard packets from other than the expected P-tunnel.) + Note that packets arriving on the wrong P-tunnel are to be discarded + even if they are arriving from the expected PE. + +8. Multiple Extranet VRFs on the Same PE + + When multiple VRFs that contain extranet receivers for a given + extranet source are present on the same PE, this PE becomes a single + leaf of the P-tunnel used for sending (multicast) traffic from that + source to these extranet receivers. The PE MUST be able to replicate + this traffic to the multiple VRFs. Specific procedures for doing so + are local to the PE and are outside the scope of this document. + + + + + +Rekhter, et al. Standards Track [Page 57] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + Two or more VRFs on the same PE may import the same S-PMSI A-D route. + If this S-PMSI A-D route contains a PTA that has its "Leaf + Information Required" flag set, it may be necessary for the PE to + originate a Leaf A-D route whose NLRI is computed from the NLRI of + the S-PMSI A-D route. (Details are provided in [RFC6514].) Note + that for a given S-PMSI A-D route, the PE can originate only one + corresponding Leaf A-D route, even if the S-PMSI A-D route is + imported into multiple VRFs. This Leaf A-D route can thus be thought + of as originating from several VRFs. It MUST NOT be withdrawn by the + PE until there are no longer any VRFs originating it. + + [RFC6514] specifies conditions under which a PE originates a + C-multicast Source Tree Join or a C-multicast Shared Tree Join, based + on the (*,G) and (S,G) states associated with a given VRF. It also + specifies the procedure for computing the NLRI of each such route. + While a given PE may contain two or more VRFs that have (extranet) + receivers for the same extranet C-flow, the PE cannot originate more + than one BGP route with a given NLRI. If there are multiple VRFs, + each of which has state that is sufficient to cause a given + C-multicast route to be originated, the route can be thought of as + originating from several VRFs. It MUST NOT be withdrawn by the PE + until there is no longer any VRF with multicast state sufficient to + cause the route to be originated. + + For a given extranet, the site(s) that contains the extranet + source(s) and the site(s) that contains the extranet receiver(s) may + be connected to the same PE. In this scenario, the procedures by + which (multicast) traffic from these sources is delivered to these + receivers are local to the PE and are outside the scope of this + document. + + An implementation MUST support multiple extranet VRFs on a PE. + +9. IANA Considerations + + IANA has allocated two new codepoints from the "First Come First + Served" [RFC5226] range of the "Transitive Opaque Extended Community + Sub-Types" registry (under the top-level registry "Border Gateway + Protocol (BGP) Extended Communities" registry). + + o Extranet Source Extended Community (0x04) + + o Extranet Separation Extended Community (0x05) + + + + + + + + +Rekhter, et al. Standards Track [Page 58] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +10. Security Considerations + + The security considerations of [RFC6513] and [RFC6514] are + applicable. + + As is the case with any application of technology based upon + [RFC4364], misconfiguration of the RTs may result in VPN security + violations (i.e., may result in a packet being delivered to a VPN + where, according to policy, it is not supposed to go). + + In those cases where the set of extranet sources of a particular VRF + are manually configured, improper configuration of the VRF can result + in VPN security violations -- traffic from a host that is not an + extranet source may be treated as if it were traffic from an extranet + source. + + Section 4.4 specifies the optional use of a new Extended Community -- + the Extranet Source Extended Community. Security considerations + regarding the use and distribution of that Extended Community are + discussed in that section. + + The procedures of this document do not provide encryption of the data + flows that are sent across the SP backbone network. Hence, these + procedures do not by themselves ensure the privacy or integrity of + the data against attacks on the backbone network. + + In general, different VPNs are allowed to have overlapping IP address + spaces; i.e., a host in one VPN may have the same IP address as a + host in another. This is safe because the customer routes from a + given VPN do not pass into other VPNs. Even if there are overlapping + address spaces among VPNs, the routes that are known at any given VPN + site are unambiguous, as long as the address space of that VPN is + unambiguous. However, this is not necessarily true when extranet + service is provided. If an extranet C-receiver in VPN-R is to be + able to receive multicast traffic from an extranet C-source in VPN-S, + then the address of the VPN-S extranet C-source must be imported into + one or more VPN-R VRFs. If that address is also the address of a + VPN-R non-extranet C-source, then a system attempting to receive an + extranet C-flow from the VPN-R extranet C-source may instead receive + a non-extranet C-flow from the VPN-S C-source. Otherwise, a VPN + security violation may result. + + That is, when provisioning an extranet between two VPNs that have + overlapping address spaces, one must ensure that the IP addresses of + the extranet sources and the extranet receivers are not from the + overlapping part of the address space. This document specifies that + if a route is imported into a given VRF, all addresses that match + that route must be unambiguous in the context of that VRF. Improper + + + +Rekhter, et al. Standards Track [Page 59] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + provisioning of the extranet source addresses or improper + provisioning of the RTs may cause this rule to be violated and may + result in a VPN security violation. + + It is possible that a given multicast C-source is the source of + multiple flows, some of which are intended to be extranet C-flows and + some of which are intended to be non-extranet flows. However, the + procedures of this document will allow any C-receiver that is able to + receive the extranet C-flows from a given C-source to also receive + the non-extranet C-flows from that source. As a result, VPN security + violations may result if any system is a C-source for both extranet + and non-extranet C-flows. However, the set of C-flows transmitted by + a given C-source is not under the control of the SP. SPs who offer + the extranet MVPN service must make sure that this potential for VPN + security violations is clearly understood by the customers who + administer the C-sources. + + This specification does not require that UMH-eligible routes be "host + routes"; they may be less specific routes. So, it is possible for + the NLRI of a UMH-eligible route to contain an address prefix that + matches the address of both an extranet C-source and a non-extranet + C-source. If such a route is exported from a VPN-S VRF and imported + by a VPN-R VRF, C-receivers contained in VPN-R will be able to + receive C-flows from the non-extranet C-sources whose addresses match + that route. This may result in VPN security violations. Service + providers who offer the extranet MVPN service must make sure that + this is clearly understood by the customers who administer the + distribution of routes from CE routers to PE routers. + + If the address ambiguities described in Sections 2.1 and 2.2 are not + prohibited by deployment of the policies described in Section 2.3.2, + VRFs must be able to discard traffic that arrives on the wrong + P-tunnel (as specified in Sections 2.3.1 and 7.5). Otherwise, VPN + security violations may occur. + + + + + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 60] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended + Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, + February 2006, <http://www.rfc-editor.org/info/rfc4360>. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, + February 2006, <http://www.rfc-editor.org/info/rfc4364>. + + [RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in + MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, + February 2012, <http://www.rfc-editor.org/info/rfc6513>. + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + <http://www.rfc-editor.org/info/rfc6514>. + + [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. + Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", + RFC 6625, DOI 10.17487/RFC6625, May 2012, + <http://www.rfc-editor.org/info/rfc6625>. + + [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP + Extended Communities", RFC 7153, DOI 10.17487/RFC7153, + March 2014, <http://www.rfc-editor.org/info/rfc7153>. + + [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., + Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent + Multicast - Sparse Mode (PIM-SM): Protocol Specification + (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, + March 2016, <http://www.rfc-editor.org/info/rfc7761>. + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 61] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +11.2. Informative References + + [MVPN-IR] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress + Replication Tunnels in Multicast VPN", Work in Progress, + draft-ietf-bess-ir-03, April 2016. + + [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast + Rendevous Point (RP) mechanism using Protocol Independent + Multicast (PIM) and Multicast Source Discovery Protocol + (MSDP)", RFC 3446, DOI 10.17487/RFC3446, January 2003, + <http://www.rfc-editor.org/info/rfc3446>. + + [RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source + Discovery Protocol (MSDP)", RFC 3618, + DOI 10.17487/RFC3618, October 2003, + <http://www.rfc-editor.org/info/rfc3618>. + + [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol + Independent Multicast (PIM)", RFC 4610, + DOI 10.17487/RFC4610, August 2006, + <http://www.rfc-editor.org/info/rfc4610>. + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, + DOI 10.17487/RFC4875, May 2007, + <http://www.rfc-editor.org/info/rfc4875>. + + [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, + "Bidirectional Protocol Independent Multicast + (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, + October 2007, <http://www.rfc-editor.org/info/rfc5015>. + + [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, + "Bootstrap Router (BSR) Mechanism for Protocol Independent + Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, + January 2008, <http://www.rfc-editor.org/info/rfc5059>. + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 62] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. + Thomas, "Label Distribution Protocol Extensions for Point- + to-Multipoint and Multipoint-to-Multipoint Label Switched + Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, + <http://www.rfc-editor.org/info/rfc6388>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 63] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +Acknowledgments + + The authors wish to thank DP Ayyadevara, Robert Kebler, Padmini + Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt + Windisch for their contributions to this work. + + We also wish to thank Lizhong Jin and Rishabh Parekh for their + reviews and comments. + + Special thanks to Jeffrey (Zhaohui) Zhang for his careful review and + for providing the ASCII art appearing in Section 2. + +Contributors + + Below is a list of other contributing authors, in alphabetical order: + + Wim Henderickx + Nokia + Copernicuslaan 50 + Antwerp 2018 + Belgium + + Email: wim.henderickx@nokia.com + + + Praveen Muley + Nokia + + Email: Praveen.Muley@nokia.com + + + Ray Qiu + Juniper Networks, Inc. + 1194 North Mathilda Avenue + Sunnyvale, CA 94089 + United States + + Email: rqiu@juniper.net + + + IJsbrand Wijnands + Cisco Systems, Inc. + De Kleetlaan 6a + Diegem 1831 + Belgium + + Email: ice@cisco.com + + + + +Rekhter, et al. Standards Track [Page 64] + +RFC 7900 Extranet Multicast in BGP/IP MPLS VPNs June 2016 + + +Authors' Addresses + + Yakov Rekhter (editor) + Juniper Networks, Inc. + 1194 North Mathilda Avenue + Sunnyvale, CA 94089 + United States + + + Eric C. Rosen (editor) + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, Massachusetts 01886 + United States + + Email: erosen@juniper.net + + + Rahul Aggarwal + Arktan + + Email: raggarwa_1@yahoo.com + + + Yiqun Cai + Alibaba Group + 400 S El Camino Real #400 + San Mateo, CA 94402 + United States + + Email: yiqun.cai@alibaba-inc.com + + + Thomas Morin + Orange + 2 Avenue Pierre-Marzin + 22307 Lannion Cedex + France + + Email: thomas.morin@orange.com + + + + + + + + + + + +Rekhter, et al. Standards Track [Page 65] + |