Extranet Multicast in BGP/IP MPLS VPNs
Extracted elements (31)
Extranet separation (Section 3.1.2) is defined to keep extranet and non-extranet traffic on separate P-tunnels. This eliminates the address-ambiguity scenario described in Section 2.1 (mixed extranet/non-extranet flows on the same tunnel) and reduces unnecessary multicast data delivery to PEs that hold only non-extranet VRFs.
UMH-eligible extranet C-source routes MAY be SAFI 129 (multicast-only) routes rather than unicast SAFI 1 routes. This allows a receiver VPN to determine the upstream multicast hop without creating a unicast route to the C-source, preventing unintended unicast traffic flows across the extranet boundary.
RP-to-group mapping discovery protocols such as the Bootstrap Router (BSR) mechanism (RFC 5059) cannot be assumed to operate automatically across extranet VPN boundaries; their use in extranet contexts is outside the scope of this document.
The RFC 6513 procedure 'Discarding Packets from Wrong PE' (Section 9.1.1) does not cause a receiver VRF to discard ambiguous extranet traffic arriving on the wrong P-tunnel when both P-tunnels originate from the same upstream PE; additional per-tunnel expected-P-tunnel checks are required.
A C-source address used as an extranet C-source MUST be unambiguous (denote the same host) across all VPNs whose VRFs contain extranet C-receivers allowed by policy to receive flows from it. Policy MUST ensure this; if ambiguous, that C-source MUST NOT be permitted as an extranet source for the conflicting VPN.
A given VRF containing extranet C-sources or C-receivers MUST use only one extranet transmission model, and a source VRF and a receiver VRF that exchange C-flows MUST use the same model. The model is determined by provisioning.
For the 'single PMSI per C-flow' model, the intersection of the RTs of an A-D route and its corresponding UMH-eligible route MUST be non-null, and there MUST NOT be any RT common to A-D routes from different VPNs advertising P-tunnels for traffic from the same ambiguous C-source address.
If a customer uses PIM-SM in ASM mode and a VRF has C-receivers for an extranet C-group, that VRF MUST import a UMH-eligible route matching the C-RP address for that group.
If a VRF contains a C-source but no C-RP for the extranet C-group, it MUST import a unicast route matching the C-RP. Conversely, if a VRF contains a C-RP but no C-source, it MUST import a unicast route matching the DR for that C-source.
If an egress PE cannot apply the 'expected P-tunnel' check procedures of Section 2.3.1 for a given extranet, the anti-ambiguity policies of Section 2.3.2 MUST be applied at every VRF containing C-sources for that extranet.
Route Reflectors and ASBRs MUST NOT add or remove the Extranet Source Extended Community from VPN-IP routes; its value MUST NOT be changed. When a PE advertises IP routes to a CE (non-option (a) interconnect), those routes MUST NOT carry the Extranet Source Extended Community.
RTs MUST be assigned so that UMH-eligible routes from different VPNs covering an ambiguous IP address have no RT in common, preventing an egress VRF from falsely correlating an A-D route from one VPN with a UMH route from another.
The Extranet Separation Extended Community's value field MUST be set to zero upon origination, MUST be ignored upon reception, and MUST be passed unchanged by intermediate routers, including Route Reflectors.
The 'unique VRF per RD' condition — each Route Distinguisher is associated with one and only one VRF — is REQUIRED by this document as a prerequisite for all extranet MVPN procedures.
The value field of the Extranet Source Extended Community MUST be set to zero upon origination; a receiving PE MUST ignore the contents of the value field.
VPN-S VRFs SHOULD NOT export a UMH-eligible route whose prefix matches both extranet C-sources and non-extranet C-sources in the context of a receiver VRF; failure may result in a VPN security violation.
When extranet separation is in use, traffic from extranet C-sources MUST NOT be carried in the same P-tunnel as traffic from non-extranet C-sources.
When extranet separation is NOT being used, the 'unique RD per VRF' condition is REQUIRED; all local-RD routes exported from a given VRF must share the same RD.
When extranet separation is used, a VRF containing both extranet and non-extranet C-sources MUST be configured with two RDs: a 'default RD' and an 'extranet RD'. The distinction MUST be known by configuration.
When extranet separation is used and a VRF exports UMH-eligible routes for both extranet and non-extranet C-sources, the UMH-eligible routes for extranet C-sources MUST contain the extranet RD in their NLRIs.
When I-PMSIs are instantiated by Ingress Replication in an extranet, if a PE assigns an MPLS label in the PTA of an I-PMSI A-D route, 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.
When Inclusive Tunnels use RSVP-TE P2MP or Ingress Replication, the RT(s) of Intra-AS I-PMSI A-D routes originated by a receiver VRF (VRF-R) MUST be such that those routes will be imported into the source VRF (VRF-S), so VRF-S can build the complete P-tunnel leaf set.
Incoming and Outgoing Extranet RTs govern PIM-based PE-PE extranet control. A source VRF MUST carry RT-S-to-R as an Outgoing Extranet RT; a receiver VRF MUST carry RT-S-to-R as an Incoming Extranet RT. Both serve as import RTs and also as export RTs for specific routes.
The 'extranet RD' is a second Route Distinguisher configured on a VRF that holds both extranet and non-extranet C-sources when extranet separation is used. UMH-eligible routes for extranet C-sources are exported carrying this extranet RD rather than the VRF's default RD.
The Extranet Separation Extended Community is a new Transitive Opaque Extended Community used only when extranet separation is in effect. It is attached to UMH-eligible routes and to I-PMSI A-D or (C-*,C-*) S-PMSI A-D routes exported by VRFs that carry extranet traffic on separate P-tunnels.
The Extranet Source Extended Community is a new Transitive Opaque Extended Community. When a CE attaches it to a BGP route (AFI/SAFI 1/1, 1/2, 1/4, 2/1, 2/2, or 2/4), it signals to the PE that the route represents an extranet C-source and should be exported to other VPNs per the procedures of Sections 4.1–4.3.
Two extranet transmission models are defined: (1) 'single PMSI per C-flow' — each extranet packet is sent on exactly one PMSI (with or without extranet separation), supported for both BGP and PIM PE-PE protocols; and (2) 'multiple PMSIs per C-flow' — a PE may send a packet on several PMSIs, supported only with PIM.
This document requests IANA assign two new codepoints from the BGP Transitive Opaque Extended Community registry: one for the Extranet Source Extended Community and one for the Extranet Separation Extended Community.
If an extranet C-source transmits non-extranet C-flows, extranet C-receivers may inadvertently receive those flows, which is a VPN security violation. Allowing an extranet C-source to transmit non-extranet C-flows is NOT RECOMMENDED, though the SP cannot unilaterally prevent it without customer-coordinated filters.
Misconfiguration of the Extranet Source Extended Community on a CE — attaching it to a route not intended as an extranet route — can trigger unintended cross-VPN route distribution and a VPN security violation. A PE SHOULD ignore the community if it appears on a route the CE should not have tagged.
Provisioning errors in extranet VPN configurations are particularly dangerous because an extranet intentionally cross-connects VPNs; incorrect RT assignments or improperly scoped UMH-eligible routes can deliver multicast traffic to VPNs that should not receive it, constituting a VPN security violation.