RFC 7900
Extranet Multicast in BGP/IP MPLS VPNs
Extranet Multicast in BGP/IP MPLS VPNs ✨
- RFC: 7900 🎀
- Stream: Internet Engineering Task Force (IETF) 🌸
- Category: Standards Track 👑
- Date: June 2016 🦋
- ISSN: 2070-1721 💜
- Authors: Y. Rekhter, Ed. and E. Rosen, Ed. (Juniper Networks, Inc.), R. Aggarwal (Arktan), Y. Cai (Alibaba Group), and T. Morin (Orange) 🫶
- Updates: RFCs 6513, 6514, and 6625 🔥
- Obsoletes: nothing listed 💅
Abstract
okay so bestie, previous RFCs already nailed down how IP multicast traffic gets from one site to another inside a BGP/MPLS IP VPN (Virtual Private Network) 🌈 but sometimes you want multicast traffic that starts in one VPN to be received by systems sitting in a different VPN ✨ that's called a "Multicast VPN (MVPN) extranet" 🦋 and this document is the one that updates RFCs 6513, 6514, and 6625 by spelling out the procedures you need to actually get extranet MVPN service working 💖
Status of This Memo
this is an Internet Standards Track document 👑
it's a product of the Internet Engineering Task Force (IETF) 🌸 and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅 if you want more on Internet Standards, check out Section 2 of RFC 7841 📚
info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7900 🧚
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) as in effect on the date of publication 📜 please read these carefully, bestie, because they spell out your rights and restrictions for this document 🙈 and any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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
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 ................................................651. Introduction ✨
okay so previous RFCs [RFC6513] [RFC6514] already lay out the procedures for letting IP multicast traffic travel from one site to another inside a BGP/MPLS IP VPN (Virtual Private Network) 🌸 but sometimes it's highkey desirable for multicast traffic whose source is in one VPN to be received by systems in another VPN 🫶 this is known as an "extranet Multicast VPN (MVPN)" 💅 and this document specifies the procedures you need to make extranet MVPN functionality happen 🔥
and bestie, this document updates RFCs 6513, 6514, and 6625 by specifying those same procedures so that extranet MVPN service can be provided 💖 it's literally the whole point of the doc, no cap ✨
1.1. Terminology
Okay so this doc borrows a bunch of terms from [RFC6513], especially the "C-" and "P-" prefixes from Section 3.1 of [RFC6513] 💖 and "A-D routes," which is short for "auto-discovery routes" 🦋
The term "Upstream Multicast Hop" (UMH) means what it means in [RFC6513] 🧚
A "UMH-eligible route" is just a "route eligible for UMH determination," as defined in Section 5.1.1 of [RFC6513] ✨ Now here's the fun part: a given UMH-eligible route or unicast route "matches" a given IP address, in a given Virtual Routing and Forwarding table (VRF), if the address prefix of that route is the longest match in that VRF for that IP address 👑 We'll sometimes say a route "matches" a particular host if the route matches one of the host's IP addresses 💅
We follow the terminology from Section 3.2 of [RFC6625] when we talk about a "Selective Provider Multicast Service Interface" (S-PMSI) A-D route being "installed" 🌸 So an S-PMSI A-D route is "installed" (in a given VRF) if the BGP decision process picked it as the preferred route for its Network Layer Reachability Information (NLRI) 😭 We also use Section 3.2 of [RFC6625] when we say an S-PMSI A-D route has been "originated by a given PE" 🫶 That just means the given Provider Edge's (PE's) IP address is inside the Originating Router's IP Address field in the route's NLRI 💜
Here are some extra terms and notation we're using too 🌈
- Extranet C-source: a multicast source, in a given VPN, that policy allows to send multicast traffic to receivers in other VPNs. 🔥
- Extranet C-receiver: a multicast receiver, in a given VPN, that policy allows to receive multicast traffic from extranet C-sources in other VPNs. 🎀
- Extranet C-flow: a multicast flow (with a specified C-source address and C-group address) whose source is an extranet C-source, and that policy allows to have extranet C-receivers. 🦋
- Extranet C-group: a multicast group address that's in the "Any-Source Multicast" (ASM) group address range, and that policy allows to have extranet C-sources and extranet C-receivers that aren't all in the same VPN. 💖 We'll sometimes talk about "Source-Specific Multicast (SSM) C-group addresses" (so, C-group addresses in the SSM group address range), but we'll never call those "extranet C-groups" 🙈
- N.B.: Any source of traffic for an extranet C-group counts as an extranet C-source, and any receiver of traffic addressed to an extranet C-group counts as an extranet C-receiver. 👑
- Extranet C-RP: a multicast Rendezvous Point (RP) for an extranet C-group. It's 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. 🧚
- 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. 🌸
- "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." ✨
- PTA: PMSI Tunnel Attribute [RFC6514]. 💅
Quick heads up: a given extranet C-source isn't automatically allowed to transmit to every extranet C-receiver 🙃 Policy decides which extranet C-sources can transmit to which extranet C-receivers. BUT for an extranet (ASM) C-group, all the 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 the transmitters to the group 😭🫶
We say 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 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 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 address prefixes respectively match the C-RP address 🌈
Now, [RFC6513] lets a set of "P-tunnels" (defined in Section 3.2 of [RFC6513]) get aggregated together and carried through an outer P-tunnel. In other words, it lets you use hierarchical Label Switched Paths (LSPs) as P-tunnels 🧚 A two-level hierarchical LSP, for example, can be thought of as a bunch of "inner tunnels" rolled up into one outer tunnel 🎀 In this doc, when we say P-tunnel, we ALWAYS mean the innermost one, which is the P-tunnel at the lowest hierarchical level. Hmm, wait, let me say that calmly: we always mean the innermost P-tunnel, the one 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. So two PTAs with the same Tunnel Type and Tunnel Identifier fields but different MPLS label fields count as identifying two different P-tunnels 🌸 (Basically, for this doc, the MPLS label in the PTA, if there is one, is treated as part of the tunnel identifier.) 🫶
We say 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 those fields are encoded as a wildcard, we'll say the NLRI contains (C-,C-) (both fields wildcards), (C-,C-G) (Multicast Source field as a wildcard), or (C-S,C-) (Multicast Group field as a wildcard) 🦋
A "VPN security violation" is any situation where a packet gets delivered to a particular VPN even though policy says it shouldn't be delivered there 😭🚨 This one is serious, bestie 💀
And 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 read as described in [RFC2119] 👑 Those are the official key words, so when you see them in caps, they're carrying real weight 🫶
1.2. Scope
1.2.1. Customer Multicast Control Protocols
This doc assumes the VPN customer is using PIM - Sparse Mode (PIM-SM) [RFC7761] as the multicast control protocol at the customer sites 💖 PIM-SM can be used in either the ASM service model or the SSM service model, and this doc covers both cases 🌈 Support for other customer IP multicast control protocols (e.g., [RFC5015], PIM - Dense Mode) is out of scope here 🙅♀️ Support for MPLS multicast control protocols (e.g., [RFC6388] [RFC4875]) used by customer sites is also out of scope 🧚
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 🎀 Those mappings can be provisioned into each router, or discovered dynamically through protocols like the Bootstrap Router (BSR) mechanism [RFC5059] ✨ BUT it can't be assumed that those protocols will automatically work in the context of an extranet 😬 Talking about using them in an extranet is out of scope for this doc 🌸
1.2.2. Provider Multicast Control Protocols
[RFC6513] lets either PIM or BGP be used as the protocol for distributing customer multicast routing information 🦋 Except where otherwise specified (like in Sections 6 and 7), the procedures in this doc cover both cases 💜
1.3. Clarification on Use of Route Distinguishers 💖
okay so [RFC4364] says every VRF has to be associated with one or more Route Distinguishers (RDs) 🎀. Every VPN-IPv4 or VPN-IPv6 route that gets exported from a particular VRF carries an RD tied to that VRF in its NLRI ✨.
[RFC4364] lets a given RD be associated with more than one VRF, as long as all the VRFs tied to that RD belong to the same VPN. But in the most common deployment model, each RD is associated with one and only one VRF 💅. [RFC6513] and [RFC6514] presuppose this model. That is, [RFC6513] and [RFC6514] presuppose that every RD is associated with one and only one VRF. We're gonna call this the "unique VRF per RD" condition 🦋.
[RFC6514] defines the MCAST-VPN address family, which has a bunch 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, has an RD tied to that VRF in its NLRI. [RFC6513] and [RFC6514] also talk about a class of routes called "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 they were exported from: the C-multicast Join routes and the Leaf A-D routes 🙈.
Routes that, when exported from a given VRF, contain (in their NLRIs) an RD of that VRF are going to be called "local-RD routes" in this document 🌈.
Given the "unique VRF per RD" condition, if you see two local-RD routes with the same RD, you can infer that they came from the same VRF 🕵️♀️. This inference works even if the two routes don't have the same SAFI, as long as both of them are local-RD routes.
This document builds upon [RFC6513] and [RFC6514], so the "unique VRF per RD" condition is REQUIRED 🫶.
[RFC6514] presupposes one more requirement on how RDs get used in the local-RD routes exported from a given VRF 👑. Say 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.
In most cases, it's not just that a given RD is tied to only a single VRF, but also that a given VRF is tied to only a single RD. We'll call this the "unique RD per VRF" condition ✨. When this holds, all the local-RD routes exported from a given VRF will have the same RD. This makes sure the presupposition in the previous paragraph holds, i.e., that the RD in a Source Active A-D route exported from a given VRF will match the RD of the corresponding UMH-eligible route exported from that 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 makes sure 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'll 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. You can find the details about the exported routes that contain the extranet RD 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. No sharing, bestie 🫶.
1.4. Overview 🌍
Picture two VPNs, VPN-S and VPN-R, and each one supports MVPN functionality as specified in [RFC6513] and/or [RFC6514] ✨. In the simplest setup, VPN-S is a collection of VRFs, and each of them is configured with a particular Route Target (RT) value (let's call it "RT-S") as its import RT and as its export RT. VPN-R is similar: a collection of VRFs, each configured with a particular RT value (let's call it "RT-R") as its import RT and as its export RT 💖.
In this setup, multicast C-receivers inside a VPN-R VRF cannot receive multicast data traffic from multicast C-sources inside a VPN-S VRF 🙅♀️. If you want that to be possible, you need to create an MVPN "extranet". Creating an extranet requires procedures on top of the ones specified in [RFC6513], [RFC6514], and [RFC6625], and this document specifies those extra procedures 🎀.
In the example above, the extra procedures let a selected set of routes exported from the VPN-S VRFs (i.e., from the VRFs containing extranet C-sources) get imported into the VPN-R VRFs (i.e., into the VRFs containing extranet C-receivers) 🦋. These routes include the ones that are eligible for use as UMH routes (see Section 5.1 of [RFC6513]) in the extranet, plus 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 figure out, from 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 figure out, from the context of a VPN-R VRF, the P-tunnel through which that VPN-S VRF sends a particular C-flow 🧚.
Depending on the type of P-tunnel in use, Leaf A-D routes may also need 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. That way 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 containing extranet C-sources and one containing extranet C-receivers. But the procedures in this document allow for way 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 two. 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. Likewise, extranet C-sources in VPN-S may be allowed to send multicast traffic to multicast C-receivers in VPN-A, VPN-B, VPN-C, and so on 🍓.
A given VPN customer might want only some of its multicast C-sources treated as extranet C-sources. This can be done by provisioning the import and export RTs of that customer's VRFs properly (as well as the VRFs of other VPNs that contain extranet C-receivers for that customer's extranet C-flows) 💜.
A given VPN customer might also want some of its extranet C-sources to transmit only to a certain set of VPNs, while other extranet C-sources transmit only to a different set of VPNs. This can be done 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 those policies through the way it provisions the import and export RTs of the VRFs 🌷. It's assumed that the customer tells the SP the set of extranet C-source addresses and the set of VPNs each C-source can transmit to. (Recall that every C-source that can transmit to an extranet C-group is an extranet C-source, and it 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's 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 transmitted by C-S. So allowing an extranet C-source to transmit non-extranet C-flows is NOT RECOMMENDED. The catch is that the SP has no control over the set of C-flows a given C-source transmits, so all it can do is pass this recommendation along 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's a risk that provisioning errors could result in an unintended cross-connection of VPNs. That would be a security problem for the customers 😭. When provisioning an extranet, attention to detail is especially important, because an extranet intentionally cross-connects VPNs. Care must always be taken to make sure the cross-connections follow the policy agreed upon by the SP and its customers 🫶.
Also, if you're connecting two VPNs that have overlapping address spaces, you have to make sure the inter-VPN traffic neither originates from nor is destined to the part of the address space that's in the overlap ✨. Other problems that can come up due to overlapping address spaces are discussed in Section 2 🌈.
2. Extranets and Overlapping Address Spaces ✨
okay bestie, this is where things get spicy 🌶️💅 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 gets combined into an extranet, it is no longer enough for an address to be unambiguous only inside a single VPN. Literally a whole new level 😭
- 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. 💜
- 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. Not me hitting the brakes 🙈
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 apply to all extranets; these are specified in Section 4. Sections 6 and 7 list additional rules and restrictions that apply 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.) 🦋
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:
- C-G is an SSM C-group used in VPN-A and VPN-B. 🌈
- 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. 💅
- 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. 🫶
- 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. ✨
- 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. 😭
- 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. 🧚
- VRF A-1 responds to VRF B-2's request for (C-S1,C-G) traffic by transmitting that traffic on P-tunnel P1. 🍓
- VRF B-2 joins P-tunnel P1 in order to receive the (C-S1,C-G) traffic. 🎀
- 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. 👑
- VRF A-1 responds to VRF A-2's request for (C-S2,C-G) traffic by transmitting that traffic on P-tunnel P1. 🦋
- VRF A-2 joins P-tunnel P1 in order to receive the (C-S2,C-G) traffic. 💜
- 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. 🌸
- VRF B-1 responds to VRF B-2's request for (C-S2,C-G) traffic by transmitting that traffic on P-tunnel P2. 🙈
- 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. 🔥
2.2. Ambiguity: P-Tunnel with Multiple Extranet Flows ✨
Okay bestie, so Figure 2 shows another way overlapping address spaces can cause a mess 🦋
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 AddressesSuppose that:
- C-G is an SSM C-group address that is used in VPN-A, VPN-B, VPN-C, and VPN-D. 🌸
- 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. 💅
- 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. 🎀
- 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. 🫶
- 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. 🙈
- 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. 🧚
- VRF A-1 responds to VRF C-1's request for (C-S1,C-G) traffic by transmitting that traffic on P-tunnel P1. 🦋
- VRF C-1 joins P-tunnel P1 in order to receive the (C-S1,C-G) traffic. 🌈
- 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. ✨
- VRF B-1 responds by transmitting its (C-S2,C-G) traffic on P-tunnel P2. 💜
- VRF C-1 joins P-tunnel P2 in order to receive the (C-S2,C-G) traffic. 🍓
- 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. 👑
- VRF A-1 responds by transmitting its (C-S2,C-G) traffic on P-tunnel P1. ⭐
- 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. 🔥
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. 🍓
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:
- 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"). 👑
- Tunnel T2 is a P2MP mLDP or RSVP-TE P-tunnel advertised in an S-PMSI A-D route (call it "R2"). 🌸
- The respective NLRIs of R1 and R2 contain the same RD value. 💜
- 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:
- Tunnel T3 is a P2MP mLDP or RSVP-TE P-tunnel advertised in a (C-,C-) S-PMSI A-D route (call it "R3"). 🌈
- 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"). ✨
- The respective NLRIs of R3 and R4 contain the same RD value. 🎀
- 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. 🧚
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 🎀
okay so, for P-tunnels advertised in S-PMSI A-D routes whose NLRI contains (C-S,C-G) or (C-S,C-*), the ambiguities from Sections 2.1 and 2.2 can be prevented by provisioning a policy that assigns only flows from the same C-source to that P-tunnel 💖
BUT here's the tea 🍵: you can't always tell from the control messages whether this policy was actually deployed. Say a given VRF imported a set of S-PMSI A-D routes, where (1) each route bound only one (C-S1,C-G1) to one P-tunnel, and (2) each route's PTA pointed to a different P-tunnel than every other route in that set. You still can't conclude there's no ambiguity 😭 The same P-tunnel might also have been advertised in an S-PMSI A-D route that this VRF never imported, and that route could have bound (C-S2,C-G2) to it, where C-S1 != C-S2. Yikes.
So, to know that a given P-tunnel (advertised in a (C-S,C-G) or (C-S,C-) S-PMSI A-D route) carries C-flows from only one C-source, a PE has to already know, through provisioning, that this policy is in place. For the rest of this document, we'll call this the "single C-source per (C-S,C-G) or (C-S,C-) P-tunnel" policy 🦋 Also, this policy only applies to P-tunnels that are advertised only in (C-S,C-G) or (C-S,C-*) S-PMSI A-D routes. Not the same thing, bestie!
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's always possible for that P-tunnel to carry traffic from multiple C-sources. No policy can stop that 🙈
However, if a P-tunnel advertised in a (C-,C-G) S-PMSI A-D route carries only traffic addressed to a single C-G, the address uniqueness rules of Section 2 keep the C-source addresses from being ambiguous. The set of C-sources sending to a particular extranet C-group address has to be unambiguous across the set of MVPNs that have receivers for that C-group. Iconic, right? ✨ So for P-tunnels advertised in (C-,C-G) S-PMSI A-D routes, the ambiguities from Sections 2.1 and 2.2 can be prevented by provisioning a policy that assigns only flows to the same extranet C-group to that P-tunnel. We'll call this the "single C-group per (C-*,C-G) P-tunnel" policy 👑
Here's the summary, lowkey the most important bit 🫶 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:
- the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" policy is provisioned,
- 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,
- no P-tunnels are advertised in I-PMSI A-D routes, and
- no (C-,C-) S-PMSI A-D routes are advertised.
Section 3 of this document describes a procedure called "extranet separation" 🌈 When extranet separation is used, the ambiguity from Section 2.1 is prevented. The ambiguity from Section 2.2, though, is NOT prevented by extranet separation. So using extranet separation isn't enough on its own to skip the procedures in Section 2.3.1 💅 That said, extranet separation is implied by the policies 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. Also, if VRF-S contains extranet C-sources, VRF-R contains extranet C-receivers, and policy allows 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. Which model a VRF uses is decided 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 sends a packet of an extranet C-flow on only a single PMSI. If that PMSI is instantiated by a multicast P-tunnel, this means the PE sends the packet on a single P-tunnel. Of course, if the PE is a replication point for that multicast P-tunnel, the packet gets transmitted more than once by the PE 🙌 Similarly, if the PMSI is instantiated by IR, each packet may be transmitted multiple times. The packet still goes out on only one PMSI, though 💜
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. Mixing is allowed, bestie 🦋
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. In certain circumstances, this can cut down on the multicast data traffic that gets delivered unnecessarily to certain PE routers 🍓 It also gets rid of the ambiguity from Section 2.1. Clean!
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 doesn't affect VRFs that contain only non-extranet C-sources, and it doesn't affect VRFs that contain only extranet C-sources either. But if one VRF has both kinds of C-sources, it'll need to advertise some P-tunnels used only for extranet C-flows and some used only for 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 🙈
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 send 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], 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 that route must be "eligible for UMH selection". In this document, we'll call these routes "UMH-eligible extranet C-source routes" 🌈
The UMH-eligible extranet C-source routes don't have to be unicast routes. They MAY be SAFI 129 routes (see Section 5.1.1 of [RFC6513]). For example, say you want a VPN-R C-receiver to be able to get extranet C-flows from C-sources in VPN-S, but you don't want any VPN-R system to be able to send unicast traffic to those C-sources. You can do that by using SAFI 129 routes as the UMH-eligible routes exported from VPN-S and imported by VPN-R. Since SAFI 129 routes are only used for UMH determination and not for unicast routing, the multicast traffic still gets forwarded properly, but no unicast routes to the C-sources get created 🧚
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 don't have to be "host routes". That means they can be routes whose IPv4 address prefixes aren't 32 bits long, or whose IPv6 address prefixes aren't 128 bits long. So a UMH-eligible extranet C-source route could match the address of an extranet C-source and also match the address of a non-extranet C-source. However, if a route like that 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 so 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. Failing to follow this rule may result in a VPN security violation 🚨 (See Section 10.)
In general, you don't want ALL the routes from the VPN-S VRFs getting exported to all the VPN-R VRFs, since only a subset of the routes in the VPN-S VRFs will be UMH-eligible extranet C-source routes. Route distribution is controlled by Route Targets (RTs), same as always for a BGP/MPLS IP VPN [RFC4364] 💖 You can build a bunch of different route distribution policies by provisioning the import and export RTs on 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 suitably manipulating the import and export RTs. Literally endless possibilities 🦋
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 💜
4.2. Distribution of Unicast Routes Matching C-RPs and DRs
Okay bestie, let's talk about a C-source, C-S 👀, that might transmit to a particular extranet C-group, C-G 💖. To follow the procedures of [RFC7761] 🦋, we need two things:
- 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. ✨
- The C-RPs servicing C-G need to be able to unicast PIM Register-Stop messages to the DR for C-S. 🫶
So if a VRF contains C-S but not a C-RP for C-G, then the VRF MUST import a unicast route matching a C-RP for C-G 🌸. Note that this unicast route 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. 🧚
4.3. Route Targets and Ambiguous UMH-Eligible Routes
Okay, so this section puts a constraint on how RTs get 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 here applies to any extranet where the ambiguity described in Section 2.2 is possible. (The conditions under which that ambiguity is possible are also described in Section 2.2. 🙃)
We want to make sure 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 the UMH-eligible route matching a given extranet C-source to 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 lets us tell whether traffic that appears to be from the given C-source is really arriving on the wrong P-tunnel, and is therefore 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 all of the following conditions hold:
- R1 and R2 are UMH-eligible extranet C-source or C-RP routes, or are unicast routes matching a C-RP.
- R1 is exported from a VRF of VPN-A, while R2 is exported from a VRF of a different VPN, say VPN-B.
- R1's NLRI specifies IP address prefix
S/n. - R2's NLRI specifies IP address prefix
S/m. m >= n(S/mis either the same as or more specific thanS/n).- 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 eitherS/morS/nmight be a longest match for H in some VRF).
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, since 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 certain VPN-IP routes are distributed. 🍓 To make sure those requirements are met, a VPN customer has to tell its SP which routes are the matching routes for extranet C-sources and C-RPs. This can be done as part of the provisioning process. Note that this doesn't necessarily mean customer/provider interaction every time the customer adds a new extranet C-source or C-RP. It only comes up when the IP address of the new C-source or C-RP doesn't match an existing route that is already being distributed as a VPN-IP extranet route. Still, it seems worthwhile to support an OPTIONAL mechanism that lets a customer dynamically mark certain routes as extranet routes. ✨
So, to make this happen, 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. 💅
Whether a CE router uses the Extranet Source Extended Community is determined by the configuration of the CE router. If it is used, the set of routes to which the Extended Community is attached is also determined by the 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 lets a customer inform the SP dynamically that certain routes are "extranet routes", it does not let a customer control the set of RTs that the route will carry when it is redistributed as a VPN-IP route. So 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. 🚨💀
4.4.2. Distribution of Extranet Source Extended Community 💖
okay so picture this 🎀 a PE gets a route from a CE called "R", and R is carrying the Extranet Source Extended Community. the PE first has to figure out (using everything from Section 4.4.1) whether it should just ignore that Extended Community on R 🙈 if it should ignore it, none of the stuff in this section applies.
otherwise, when the PE originates a VPN-IP route corresponding to R, it MUST attach this Extended Community to that route. no skipping!! 💅
next up, Route Reflectors. a Route Reflector MUST NOT add or remove the Extranet Source Extended Community from the VPN-IP routes it reflects. that still holds when IBGP-learned VPN-IP routes get reflected out to EBGP peers, which is the inter-AS option (c) situation (see Section 10 of [RFC4364]) 🦋 and the value of the Extended Community MUST NOT be changed by the Route Reflector either. hands off! ✋
ASBRs get the same energy. when they re-advertise VPN-IP routes, they MUST NOT add/remove the Extranet Source Extended Community from those routes. that covers inter-AS options (b) and (c) (see Section 10 of [RFC4364]) ✨ and yep, the value MUST NOT be changed by the ASBRs either.
now the PE-to-CE side, which is kinda the strict one 👑 when a PE advertises IP routes to a CE over BGP, those 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]). if the PE-CE connection isn't an option (a) connection, then a CE that receives an IP route with the Extranet Source Extended Community MUST remove it from the route before re-advertising the route. 🧹
why does all this matter so much? 😭 the rules for attaching the Extranet Source Extended Community to a VPN-IP route, and for propagating it, exist so that a VPN with an option (a) interconnect still works (see Section 10 of [RFC4364]). at an option (a) interconnect, the VPN-IP route gets translated back to an IP route, and the RTs get stripped off before that IP route moves on. if the Extranet Source Extended Community got stripped too, the router on the other end has literally no way to know the route represents an extranet source 💀 so using this Extended Community to dynamically signal an extranet source just won't work correctly across an option (a) interconnect unless the rules in this section are followed. ngl that's the whole point 🫶
4.5. The Extranet Separation Extended Community 🌈
we define a brand new Transitive Opaque Extended Community: the Extranet Separation Extended Community (see [RFC4360], [RFC7153], and Section 9 of this document). it only gets used when extranet separation is in play. 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]). 🌸
here's the trickier bit ✨ 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 exported from that VRF (following the procedures of Sections 4.1, 4.2, and 4.3) MUST carry the Extranet Separation Extended Community. on top of that, if an I-PMSI A-D route and/or a (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. more details live 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 there's an extranet C-flow where:
- The extranet C-source of that C-flow is in VRF A-1.
- 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. VRF A-1 MUST also export an Intra-AS I-PMSI A-D route or an S-PMSI A-D route that specifies the P-tunnel it will send the data traffic of the given extranet C-flow through, and VRF B-1 MUST import that route too. 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 saying it contains a source of the given C-flow, and VRF B-1 must import that Source Active A-D route. 🫶 basically, for VRF B-1 to receive a C-flow from an 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 make sure this happens is to provision an RT that's carried by all the routes exported from VRF A-1 that are "about" a given extranet C-source, and then provision this same RT as an import RT at any VRF (like VRF B-1) that's 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's one more requirement about how RTs get provisioned. 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. here's the scenario:
- IP address S is the address of one system in VPN-A and the address of a different system in VPN-B.
- VRF A-1 on PE1 exports UMH-eligible route R1, which is a matching route for S.
- 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).
- VRF B-1 on PE1 exports a UMH-eligible route R2, which is a matching route for S.
- 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. on top of that, the following set of RT assignment rules MUST be followed when extranets are supported. these rules support all the extranet transmission models described in this specification: 🌈
- There MUST NOT be any RT that is carried by both P1 and P2.
- 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.
- 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.
now let's say VRF C-1 on PE2 imports P1 and R1 from VRF A-1, while also importing P2 from VRF B-1. since:
- R1 is VRF C-1's route to S,
- R1 has an RT in common with P1, and
- R1 has no RT in common with P2,
it can be concluded that VRF C-1 should expect multicast traffic from S to arrive on the P-tunnel specified in P1. see Sections 6 and 7 for more details on figuring out the expected P-tunnel for a given extranet C-flow. 🕵️♀️
while assigning import and export RTs to routes is a deployment and provisioning issue rather than a protocol issue, it should be understood that failing to follow these rules is likely to result in VPN security violations. 🚨 this one is serious, bestie.
5.2. Considerations for Particular Inclusive Tunnel Types 🌸
an Inclusive Tunnel (sometimes called 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 a VRF, let's call it 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 that it must import an Intra-AS I-PMSI A-D route from every VRF that needs to receive data through that tunnel. so, 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. 🔑
in the case of IR, this has a consequence worth knowing 👀 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 🌸
bestie, this part is only for Inclusive Tunnels that get built via IR 🦋
[RFC6513] and [RFC6514] lay out how I-PMSIs can be instantiated by IR 💖 The IR P-tunnel idea and how to support it get the full tea in [MVPN-IR]. Quick vibe check: an IR P-tunnel is basically a P2MP tree, but a packet hops from one node on the tree to the next by getting encapsulated and shipped through a unicast tunnel 🧚
As we talked about 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, that means the following two procedures MUST be followed 👑
- 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
- 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 🙅♀️
If you skip these, packets that show up on the wrong P-tunnel can't get discarded, and that could lead to data duplication. Not it 💀
If you want extranets AND you're using IR to instantiate the PMSIs, there's another option: use (C-,C-) S-PMSIs instead of I-PMSIs ✨ (See [RFC6625], plus Sections 7.2.2, 7.3.2, and 7.4.4 of this document.) It has pretty much the same effect in the data plane, and there are no restrictions on which type of unicast tunnel you can use to instantiate S-PMSIs. Iconic 🎀
Section 6.4.5 of [RFC6513] describes a way to support VPNs using I-PMSIs instantiated by IR, with no S-PMSIs, using "explicit tracking" so a C-flow only goes to egress PEs that actually have receivers for it 🌈 This document does not provide procedures to support extranets with that model, so no extranet glow-up here 🙈
6. When PIM Is the PE-PE C-Multicast Control Plane 🦋
As [RFC6513] specifies, when PIM is 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 💜 Each VRF of the MVPN has a PIM C-instance, and that PIM C-instance treats the MI-PMSI like it's a LAN interface. So the "ordinary" PIM procedures run over the MI-PMSI just like they would over a real LAN interface, EXCEPT the data-plane and control-plane "Reverse Path Forwarding (RPF) checks" need a little glow-up 💅 Section 5.2 of [RFC6513] specifies the RPF check modifications for non-extranet MVPN service.
Let's make it concrete 🍓 Say there are two VPNs: VPN-S and VPN-R. Without extranet support, all the VRFs of VPN-S hang out on one MI-PMSI (call it "the VPN-S MI-PMSI"), and all the VRFs of VPN-R hang out on another ("the VPN-R MI-PMSI"). Now, if we want extranet service where the extranet C-sources live on some set of VPN-S VRFs and the extranet C-receivers live on some set of VPN-R VRFs, we've got two choices:
- either the VPN-R VRFs need to join the VPN-S MI-PMSI, or
- the VPN-S VRFs need to join the VPN-R MI-PMSI.
Choice one is for the "single PMSI per C-flow" transmission model 🌸 Choice two is for the "multiple PMSIs per C-flow" transmission model ✨
Procedures for both models are coming up below 👀
To make these models work, you need to be able to tell which I-PMSI A-D routes belong to the VPN-S I-PMSI and which belong to the VPN-R I-PMSI. The spec gives procedures for assigning RTs to these routes so that determination is possible 🧚
Both models let you use S-PMSIs to carry multicast data traffic 🦋 If a VRF with receivers can receive from multiple MI-PMSIs, each S-PMSI must be uniquely associated with one particular MI-PMSI. Again, there are procedures for assigning RTs so that this is possible 💖
All the procedures in Sections 3, 4, and 5 still apply, no exceptions 🫶
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
Without extranet service, say each VRF of a given VPN (call it "VPN-S") is configured with RT-S as its import and export RT, and each VRF of a second VPN (call it "VPN-R") is configured with RT-R as its import and export RT. We'll call RT-S and RT-R "non-extranet RTs" 💅
Now imagine VPN-S has some extranet C-sources, and VPN-R has some extranet C-receivers that policy says can receive extranet C-flows from those VPN-S sources 👑
To set up this S-to-R extranet, you REQUIRED-ly need to provision an extra RT (call it "RT-S-to-R"). Its value is, in general, different from RT-S and RT-R 🌈
A VPN-S VRF that holds 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 holds extranet C-receivers allowed to receive packets from VPN-S MUST be configured with RT-S-to-R as an "Incoming Extranet RT" 🌸
Quick reminder: "Incoming" and "Outgoing" here are about which way multicast data packets flow relative to the VRF ✨
The Incoming Extranet RTs and Outgoing Extranet RTs configured for a given VRF act as import RTs for that VRF 🦋 They also act as export RTs, but only for specific routes, as spelled out in Section 6.1.2 below 💖
Any VRF with 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 just so happens that all C-sources in VPN-S are extranet C-sources allowed to transmit to VPN-R, then VPN-S VRFs MAY be configured so that RT-S is both a non-extranet RT and an Outgoing Extranet RT, and VPN-R VRFs MAY be configured so that RT-S is an Incoming Extranet RT 🧚
6.1.2. UMH-Eligible Routes and RTs
Say R1 is a route exported from a VPN-S VRF that matches an extranet C-source 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 🎀 That makes the route get imported into the VPN-R VRFs that have extranet C-receivers allowed by policy to receive from VPN-S ✨
The rules of Section 4 about RTs and ambiguous addresses still apply 🙈
6.1.3. PIM C-Instance Reverse Path Forwarding Determination
Say a PIM control message (call it "M") gets received by a given VRF (call it "VRF-V") from a particular P-tunnel T 🦋 To process 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 on the UMH selection rules in Section 5.1 of [RFC6513] 🌈
This document adds an extra constraint to 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 eligible for UMH selection unless there is an RT (call it "RT1") configured as one of VRF-V's Outgoing Extranet RTs, such that both of these conditions hold:
- The route matching S is exported from VRF-V carrying RT1, and
- 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 that policy allows to receive from the C-sources in that VPN-S VRF, then the VPN-R VRF joins the MI-PMSI that VPN-S uses for its non-extranet traffic 🫶 Main character energy 👑
6.2.1. Forming the MI-PMSIs 🎀
Okay so picture 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 that specifies the P-tunnel to be used as part of the VPN-S MI-PMSI. Without extranet service, this route just carries the VRF's non-extranet RT, RT-S. But when extranet service is happening (the "single PMSI per C-flow" model), this route MUST also carry each of the VRF's Outgoing Extranet RTs ✨
Now the VPN-R side 🦋. Say a VPN-R VRF has extranet C-receivers. Per [RFC6513], each VPN-R VRF must originate an Intra-AS I-PMSI A-D route with a PTA that specifies the P-tunnel for the VPN-R MI-PMSI. This route carries the VRF's non-extranet RT, RT-R. When extranet service is provided (again, the "single PMSI per C-flow" model), the VPN-R VRF MUST also originate one or more extra Intra-AS I-PMSI A-D routes. It MUST originate one extra route for each Incoming Extranet RT it's configured with, and each of those routes carries exactly one of the configured Incoming Extranet RTs 🌸
Quick but important: 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. We also add the rule that no pair of those routes MUST NOT contain an RT in common. Sooo, no two of them can share an RT 🙈
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. That whole set of P-tunnels counts as one single MI-PMSI. The associated PIM C-instance treats that MI-PMSI as one LAN and runs PIM procedures on it, as specified in [RFC6513]. The source VRF's PIM C-instance doesn't know the MI-PMSI attaches to VRFs from different VPNs. Iconic, honestly 👑
A VRF with extranet C-receivers MUST join the P-tunnels advertised in all of the imported I-PMSI A-D routes. The P-tunnels in the I-PMSI A-D routes that carry a particular Incoming Extranet RT get treated as one particular MI-PMSI. So a receiver VRF will "see" several MI-PMSIs: one for the non-extranet, plus as many as one for each configured Incoming Extranet RT. The PIM C-instance treats each of these MI-PMSIs as its own separate LAN interface 🧚
Here's an example, bestie 💜. Suppose that:
- All VPN-R VRFs are configured with
RT-Ras a non-extranet import and export RT, and - VPN-R VRFs with extranet receivers are configured with
RT-S-to-Ras an Incoming Extranet RT, and - VPN-S VRFs with extranet transmitters are configured with:
RT-Sas a non-extranet import and export RT- a list of IP addresses that are the addresses of the extranet sources
RT-S-to-Ras an Outgoing Extranet RT
So the VPN-S VRFs export UMH-eligible routes matching the extranet C-sources, and those routes carry both RT-S and RT-S-to-R. Each VPN-S VRF also exports an Intra-AS I-PMSI A-D route carrying both RT-S and RT-S-to-R 🎀
The VPN-R VRFs originate and export two Intra-AS I-PMSI A-D routes: one carrying RT-R and one carrying RT-S-to-R. The RT-S-to-R route gets imported into the VPN-S VRFs. VPN-R counts all the I-PMSI A-D routes it has exported or imported with RT-S-to-R as one MI-PMSI, and all the ones with RT-R as a second MI-PMSI. The PIM C-instance of a VPN-R VRF treats those two MI-PMSIs as two separate LAN interfaces. The VPN-S VRFs, though, regard all the I-PMSI A-D routes imported with RT-S or RT-S-to-R as a single MI-PMSI. Think of it like this: the VPN-R VRFs have joined the VPN-S MI-PMSI as well as their own VPN-R MI-PMSI 🦋
Extranets with more than two VPNs are totally supported too 🌈 Say there are three VPNs: VPN-A, VPN-B, and VPN-C. VPN-A and VPN-B have extranet C-sources, and VPN-C has receivers for both the VPN-A and VPN-B extranet C-sources. The VPN-C VRFs that have receivers for both can be set up like this: they're provisioned with RT-C as a non-extranet RT, and with RT-A-to-C and RT-B-to-C as Incoming Extranet RTs. These provisioned VPN-C VRFs will originate three Intra-AS I-PMSI A-D routes (each with a different RD in its NLRI), and each one carries exactly one of those three RTs. The VPN-B VRFs with extranet C-sources get RT-B-to-C as an Outgoing Extranet RT, and the VPN-A VRFs get RT-A-to-C as an Outgoing Extranet RT. The result is that a VPN-C VRF's PIM C-instance sees three LAN interfaces: one for the non-extranet and one for each of the two extranets. This generalizes easily to VPN-C receivers in n different extranets (so, receiving extranet flows whose sources are in n different VPNs) 💖
Now, same three VPNs, but this time VPN-A is the only one with extranet sources, while VPN-B and VPN-C both have receivers for the VPN-A extranet sources. You can set this up as either one extranet or two 💅
To do it as one extranet, the VPN-A VRFs get configured with one Outgoing Extranet RT (let's call it "RT-A-extranet", aka RT-A-extranet). The VPN-B and VPN-C VRFs with extranet receivers are provisioned with RT-A-extranet as their Incoming Extranet RT. So the VPN-B and VPN-C VRFs 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 extranet route carries RT-A-extranet but doesn't share any RT with the non-extranet A-D routes exported from that same VRF 🌸
The result? The VPN-B and VPN-C VRFs each belong to two MI-PMSIs: one for the extranet and one for the intranet. The extranet MI-PMSI attaches VPN-A VRFs, VPN-B VRFs, and VPN-C VRFs 🫶
Alternatively, you could set up the VPN-A VRFs so some UMH-eligible extranet source routes carry an RT called RT-A-to-B and some carry one called RT-A-to-C. The VPN-A VRFs get both of these as Outgoing Extranet RTs. So an extranet flow from a VPN-A source can have both VPN-B and VPN-C receivers, the UMH-eligible route for that source carries both RTs. VPN-B VRFs (but not VPN-C VRFs) get RT-A-to-B as an Incoming Extranet RT, and VPN-C VRFs (but not VPN-B VRFs) get RT-A-to-C as an Incoming Extranet RT 🦋
Following the rules above, if any VPN-A extranet source is supposed 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 has both RT-A-to-B and RT-A-to-C among its RTs (along with VPN-A's non-extranet RT). The extranet I-PMSI A-D route from a VPN-B VRF carries RT-A-to-B, and the extranet I-PMSI A-D route from a VPN-C VRF carries RT-A-to-C 🍓
And if a given VRF has both extranet C-receivers and extranet C-sources? Totally fine. The procedures above still work, because the VRF gets configured with both Incoming Extranet RTs and Outgoing Extranet RTs. That VRF functions as both a VPN-S VRF and a VPN-R VRF. Main character energy 👑
6.2.2. S-PMSIs 🌷
When PIM is the PE-PE C-multicast control plane, every S-PMSI is considered part of the "emulated LAN" that "corresponds" to a particular MI-PMSI 💜
When the bindings of C-flows to particular S-PMSIs get announced via S-PMSI Join messages (Section 7 of [RFC6513]) sent on the MI-PMSI, the S-PMSI counts as part of the same LAN interface as its corresponding MI-PMSI 🎀
When the bindings of C-flows to particular S-PMSIs get 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 that shared RT 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 "corresponds" to the MI-PMSI of the Intra-AS I-PMSI A-D route (originated from the same PE) that it shares an RT with 🧚
Here's how the MI-PMSI that corresponds to a given S-PMSI gets figured out:
- 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.
- 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.
- 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 in [RFC6625] for deciding whether a given S-PMSI A-D route is a "match for reception" for a given (C-S,C-G) or (C-*,C-G) get modified like so 🙈
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 in [RFC6625] for deciding whether a given S-PMSI A-D route is a "match for transmission" are unchanged ✨
6.2.3. Sending PIM Control Packets 💌
Let's say a PE (we'll call it PE1) receives a PIM Join(S,G) from a CE, over a VRF interface that's 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 😭
So to do that, PE1 finds, in the VRF associated with the interface the Join came in on, the selected UMH route for S, following the procedures of Section 5.1 of [RFC6513]. PE1 figures out the set of RTs carried by that route. Then PE1 checks whether there's 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 🦋
If the rules of Sections 3, 4, and 5 have been followed, each of PE1's selected UMH routes shares an RT with exactly one of PE1's currently originated Intra-AS I-PMSI A-D routes. If that's the case, the Join gets sent on the P-tunnel advertised in the PTA of that route. Otherwise, the Join MUST NOT be sent 🚫
Essentially, this procedure makes the RPF check for C-S resolve to the MI-PMSI that's serving as the next-hop "interface" to C-S 🌈
And if a PE receives a PIM Join(*,G) from a CE, the RPF check works the same way, except the selected UMH route is a route to the C-RP associated with the C-G group 💖
6.2.4. Receiving PIM Control Packets ✨
okay so bestie 💖 when a PIM C-instance gets a PIM control message off a P-tunnel, it has to figure out which incoming interface the message came in on 🎀 and the answer is the MI-PMSI that the P-tunnel is part of. ngl that's giving clean and simple vibes 🦋
6.2.5. Sending and Receiving Data Packets 💅
the rules for picking which PMSI to send a multicast data packet on come from [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 PIM C-instance's point of view there is only one outgoing interface, so it's all very chill 🌸
now for receiving 🧚. when a PIM C-instance gets a multicast data packet from a P-tunnel that's being used to instantiate an MI-PMSI, the MI-PMSI that P-tunnel belongs to (see Sections 6.2.1 and 6.2.2) counts as the packet's incoming interface. if the packet arrived on a P-tunnel that was advertised in an S-PMSI A-D route, the incoming interface is the MI-PMSI that S-PMSI route corresponds to, as defined in Section 6.2.2. then the ordinary PIM data-plane RPF checks apply 💜
following ordinary PIM procedures, packets that show up from an unexpected incoming interface get discarded 🗑️ and that clears up any problems from the ambiguities in Sections 2.1 and 2.2. literally so iconic 👑
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 that policy allows to receive from those C-sources, then the VPN-S VRF joins the MI-PMSI that VPN-R uses for its non-extranet traffic 🦋
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 sends the packet on a single PMSI. so if a packet needs to go from a VPN-A VRF and get received at a VPN-B VRF and a VPN-C VRF, there must be some P-tunnel that both the VPN-B and VPN-C VRFs can receive packets from 🎀
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 send 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 send the packet to the VPN-B VRFs, and another PMSI that the VPN-A VRF uses to send the packet to the VPN-C VRFs. two lanes, no traffic jams 🚗💨
6.3.1. Forming the MI-PMSIs 🍓
okay so picture 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 that specifies the P-tunnel to be used as part of the VPN-R MI-PMSI. without 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 💖
now picture 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 that specifies 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 it has been configured with, and each of those routes 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. the rules in Sections 3, 4, and 5 make sure that happens ✨
however, in the "multiple PMSIs per C-flow" model, a VRF containing only C-receivers originates just one Intra-AS I-PMSI A-D route, carrying the non-extranet RT and all of the Incoming Extranet RTs 🌸
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 those routes count as part of the same MI-PMSI. that means the associated PIM C-instance treats them as part of a single interface 🧁
in this model, the VRF containing extranet C-sources is the one that MUST originate multiple Intra-AS I-PMSI A-D routes 😭. each of those routes 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. that means the VPN-S VRFs end up attached to multiple MI-PMSIs, while the VPN-R VRFs are attached to only one. the PIM C-instance at the VPN-R VRFs doesn't know that the VPN-R MI-PMSI is attached to VPN-S 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 exactly 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 the Join was received over may be added to the set of outgoing interfaces for that multicast state. if n MI-PMSIs get added to the outgoing interface list for a particular multicast state, a multicast data packet may need to be replicated n times and sent once on each of the n MI-PMSIs 🌈
since all of the multicast data packets received from another PE come in over a single emulated LAN, there's no need for any special procedures to figure out a packet's incoming interface. the ambiguities described in Sections 2.1 and 2.2 don't happen, because a VPN-R VRF can only receive multicast data traffic that a VPN-R VRF has requested 👑
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. provisioning decides which one it is, and 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 a PE needs to originate a C-multicast Source Tree Join for (C-S,C-G), it 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 needs 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] explains 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 build part of the C-multicast route ✨
for extranets, the rules in Section 7.4.5 of this document are used to find the Inter-AS I-PMSI A-D route or the 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 🎀
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 how 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. and 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 💖
Okay so let R-SP be an S-PMSI A-D route that gets exported from VRF-S 🦋. Say R-SP is binding some or all of the extranet C-flows from a given extranet C-source to a given selective P-tunnel. Then let R-UMH be a UMH-eligible route that's exported from VRF-S and matches that same extranet C-source. In that situation, R-SP and R-UMH MUST have at least one RT in common, and the RTs on those two routes MUST be set up so that every VRF that imports R-UMH also imports R-SP. These rules apply whether or not R-SP uses wildcards [RFC6625] ✨
An implementation MUST allow the set of RTs carried by the S-PMSI A-D routes to be specified by configuration 🎀 If there's no such configuration, an S-PMSI A-D route originated by a given VRF (call it VRF-X) MUST carry a default set of RTs. The default is decided by these rules:
- 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. 💅 - 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. 🌈 - 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, because 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 has C-S in the Multicast Source field of its NLRI, and VRF-S also exports a UMH-eligible route matching C-S, then the Source Active A-D route MUST carry at least one RT in common with the UMH-eligible route. That RT MUST be picked so the following condition holds: if a VRF (say VRF-R) contains an extranet C-receiver that policy allows to receive extranet traffic from C-S, then VRF-R imports both the UMH-eligible route and the Source Active A-D route. 🫶
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 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 has C-S in the Multicast Source field of its NLRI. This document replaces the rule in Section 14.1 of [RFC6514] for building the RT(s) carried by such a route, with the following text: VRF-X MUST be configured so 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. That way, if a VRF (say VRF-R) contains an extranet C-receiver that policy allows 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 subsections below explain how these RDs get used 🦋
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 them is used only to carry extranet C-flows (the "extranet inclusive P-tunnel"), and the other is used only to carry non-extranet C-flows (the "non-extranet inclusive P-tunnel") ✨
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, and 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, and 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 needs to be originated. The PTA of this route identifies the "extranet inclusive P-tunnel", and 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 so 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's possible to use an inclusive P-tunnel for non-extranet traffic while using only selective P-tunnels for extranet traffic. It's 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 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] 👑
The following rules, specific to the use of extranet separation, apply 🌷
- A selective P-tunnel MUST NOT carry C-flows from both extranet and non-extranet C-sources. 🙈
- 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. 🦋 - 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.
- The S-PMSI A-D route is a
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. 🧚
- 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. If there's no such configuration, an S-PMSI A-D route originated by a given VRF (call it VRF-X) MUST carry a default set of RTs, based on the following rules:
- Rule 1 of Section 7.2.2 applies. 💖
- By default, if C-G is an extranet C-group, rule 2 of Section 7.2.2 applies. 🌈
- 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 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, because 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 ✨
Okay bestie, this part applies whether extranet separation is used or not 🫶
So picture a VRF with receivers for a particular C-flow. A PE needs to figure out which P-tunnel that C-flow's packets are supposed to arrive on 🦋. It does this by hunting for an I-PMSI or S-PMSI A-D route that "matches" the flow. The matching A-D route has a PTA that names the P-tunnel carrying that C-flow's traffic, and we call that the "expected P-tunnel" for the C-flow 💅. Quick aside, per [MVPN-IR]: if the PTA says the tunnel is type "Ingress Replication" (IR), then the P-tunnel's identifier is actually the NLRI of the I-PMSI or S-PMSI A-D route. If the PTA uses any other tunnel type, the identifier is 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. It also MUST stay joined for as long as (1) it still needs to receive that C-flow and (2) that P-tunnel is still the expected P-tunnel for it 🔥. How you join and leave depends, of course, on the tunnel type.
If a PTA specifies a non-zero MPLS label for a tunnel that isn't an IR tunnel, then the PE that originated that A-D route is advertising an aggregate P-tunnel 🌸. Think of the aggregate as an outer P-tunnel that multiplexes a bunch of inner P-tunnels, and the MPLS label in the PTA is how the inner ones get demultiplexed. In this document, when we say "expected P-tunnel" for an aggregate, we mean that particular inner P-tunnel, not the outer one. The inner P-tunnel is the one that's the expected P-tunnel for a given C-flow 🎀
To find the expected P-tunnel for a C-flow, first figure out the upstream PE of that flow. Then look at the S-PMSI A-D routes that PE originated and compare their NLRIs to the flow's (C-S/C-RP,C-G), to see if there's a "match for reception". (If no S-PMSI A-D route matches the C-flow, the expected P-tunnel may have been advertised in an I-PMSI A-D route instead. See Section 7.4.5.)
The rules for deciding whether a given C-flow is a "match for reception" for a given S-PMSI A-D route, in non-extranet cases, are in Section 3.2 of [RFC6625]. Note that "installed" and "originated" mean what they're defined to mean in Section 3.2 of [RFC6625] (see also Section 1.1 of this document) 📚
This spec adds extra rules for deciding whether a given S-PMSI A-D route is a "match for reception" for a given (C-S/C-RP,C-G). Every one of these rules assumes the context of a particular VRF that the A-D route was imported into 💖
The rules in [RFC6625] for deciding whether an S-PMSI A-D route is a "match for transmission" stay unchanged ✨
Now, suppose a PE has originated a C-multicast Shared Tree Join for (C-*,C-G) but hasn't originated a C-multicast Source Tree Join for (C-S,C-G). Also suppose it has received and installed a Source Active A-D route for (C-S,C-G). As Section 13.2 of [RFC6514] describes, the PE has to receive the (C-S,C-G) traffic from whatever tunnel the originator of that installed Source Active A-D route uses for sending (C-S,C-G) 🫠
To figure out who that originator is, do this:
- Look at the "UMH Route Candidate Set" for C-S, as defined in Section 5.1.3 of [RFC6513].
- From that set, pick a subset of UMH routes to C-S, where each route in the subset has at least one RT in common with the Source Active A-D route, and at least one of those common RTs is an import RT of the VRF.
- From that subset, find the route whose RD is the same as the RD from the NLRI of the Source Active A-D route.
- The upstream PE is the PE identified in the VRF Route Import Extended Community of that route.
- The upstream AS is the AS identified in the Source AS Extended Community of that route.
If step 2 gives you an empty set, or step 3 can't find a route, then the upstream PE of the Source Active A-D route can't be determined. In that case you have to act as if the Source Active A-D route had never been installed 😭 (A later change to the UMH Route Candidate Set for C-S might mean you need to try figuring out the upstream PE again.)
Once the upstream PE is known, the P-tunnel the flow is expected on gets figured out using the procedures already covered 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 (on top of the conditions in [RFC6625]) 🙈
- the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is provisioned, or
- 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 (on top of the conditions in [RFC6625]) 💅
- the "single C-source per (C-S,C-G) or (C-S,C-*) P-tunnel" is provisioned, or
- 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.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 (on top of the conditions in [RFC6625]) 👑
- The given VRF currently has 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.
- a.
- The given VRF does not currently have an 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 currently has an originated Source Tree Join C-multicast route for
(C-S,C-G), - 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.
- a. there are one or more values for C-S for which the VRF currently has an originated Source Tree Join C-multicast route for
If a VRF has an installed (C-*,C-G) S-PMSI A-D route but doesn't have a (C-S,C-G) or (C-*,C-G) multicast state that matches that route for reception, then 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 get created at some later time while the route is still installed, then the procedures of Section 12.3 of [RFC6514] get invoked at that point 🦋
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 all of these conditions hold (on top of the conditions in [RFC6625]) 🧚
- 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.
- 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 has no matching S-PMSI A-D routes for a particular C-flow, then that C-flow is expected to arrive (at that egress VRF) on an inclusive P-tunnel 🍓
Now suppose 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 [RFC6514] specifies, 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 💜
Next, suppose an egress PE has originated a (C-*,C-G) C-multicast Shared Tree Join but hasn't originated a (C-S,C-G) C-multicast Source Tree Join. If the egress VRF doesn't have a (C-S,C-G) Source Active A-D route installed, then 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, then the selected upstream PE and upstream AS are determined as specified in Section 7.4. Either way, let R-UMH be the installed UMH-eligible route matching C-S 🌸
Here's how you find the inclusive P-tunnel expected to carry a particular C-flow:
- If the selected upstream AS is the local AS, or segmented Inter-AS P-tunnels aren't 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 🎀
- 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 🦋
Okay bestie, so any packet that shows up on a P-tunnel that isn't the expected one (the one from Section 7.4) MUST be discarded, unless it's known that all the packets carried by both P-tunnels come from the same ingress VRF. 😭 Section 2.3.1 has the deeper dive on when to toss packets from a P-tunnel other than the expected one.
Lowkey the big deal here: a packet on the wrong P-tunnel gets discarded even if it's coming from the expected PE. no exceptions 💅
8. Multiple Extranet VRFs on the Same PE ✨
Okay, so when multiple VRFs on the same PE hold extranet receivers for a given extranet source, this PE becomes a single leaf of the P-tunnel used to send that source's (multicast) traffic to those receivers. 🌸 The PE MUST be able to replicate this traffic to the multiple VRFs. How it does that is local to the PE and outside the scope of this document, so that's a "not my problem" moment 🙈
Two or more VRFs on the same PE may import the same S-PMSI A-D route. If that route contains a PTA with its "Leaf Information Required" flag set, the PE may need to originate a Leaf A-D route whose NLRI is computed from the NLRI of the S-PMSI A-D route. (The details are in [RFC6514], bestie 📖.) Note that for a given S-PMSI A-D route, the PE can originate only one corresponding Leaf A-D route, even if that S-PMSI route is imported into multiple VRFs. So this Leaf A-D route can be thought of as coming from several VRFs at once 🧚 It MUST NOT be withdrawn by the PE until there are no longer any VRFs originating it.
[RFC6514] specifies the 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. Even when a PE has two or more VRFs with (extranet) receivers for the same extranet C-flow, the PE cannot originate more than one BGP route with a given NLRI. If multiple VRFs each have state that's 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) containing the extranet source(s) and the site(s) containing the extranet receiver(s) may be connected to the same PE. In this scenario, the procedures for delivering (multicast) traffic from these sources to these receivers are local to the PE and 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).
- Extranet Source Extended Community (0x04)
- Extranet Separation Extended Community (0x05)
10. Security Considerations 💀
Bestie, this section is SERIOUS 💀 Read every line.
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 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 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 with 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 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 intended to be extranet C-flows and some 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. 💀💜
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>.11.2. Informative References ✨
Okay bestie, now we're in the "extra reading" zone 📚 These are the refs the spec leans on for background, not the must-reads. Here's the lineup 💅
[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>.
[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>.
Acknowledgments 🫶
The authors want to give a huge shoutout to DP Ayyadevara, Robert Kebler, Padmini Misra, Rayen Mohanty, Maria Napierala, Karthik Subramanian, and Kurt Windisch for their contributions to this work. 🌸
We also want 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. He absolutely ate the ASCII art 🎀
Contributors 🦋
Below is a list of other contributing authors, in alphabetical order. The squad is iconic 👑
Wim Henderickx
Nokia
Copernicuslaan 50
Antwerp 2018
Belgium
Email: wim.henderickx@nokia.comPraveen Muley
Nokia
Email: Praveen.Muley@nokia.comRay Qiu
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089
United States
Email: rqiu@juniper.netIJsbrand Wijnands
Cisco Systems, Inc.
De Kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.comAuthors' Addresses 🌈
Here's where to find the main authors, the real ones who made this whole thing happen ✨
Yakov Rekhter (editor)
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089
United StatesEric C. Rosen (editor)
Juniper Networks, Inc.
10 Technology Park Drive
Westford, Massachusetts 01886
United States
Email: erosen@juniper.netRahul Aggarwal
Arktan
Email: raggarwa_1@yahoo.comYiqun Cai
Alibaba Group
400 S El Camino Real #400
San Mateo, CA 94402
United States
Email: yiqun.cai@alibaba-inc.comThomas Morin
Orange
2 Avenue Pierre-Marzin
22307 Lannion Cedex
France
Email: thomas.morin@orange.com📦 where this page comes from
- ietf: rfc7900 2016-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms