Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication
Extracted elements (20)
Label sharing between P-tunnels is explicitly permitted (e.g., a single label shared by a (C-*,C-*-BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route from the same PE), though other specifications such as MVPN-EXTRANET may impose additional constraints on how sharing is done.
MP2MP tunnels realized via BIDIR-PIM or mLDP (as assumed by RFC 7582) require signaling and state on both PEs and P routers. This document instead simulates the MP2MP tunnel with a mesh of P2MP Ingress Replication tunnels, which confines state to PEs only and avoids any P-router involvement.
The MP2MP partial-mesh approach (Section 11.2.3 of RFC 6513) guarantees that a PE discards bidirectional C-flow traffic from PEs not in the same partition without needing an extra PE Distinguisher Label, by having all PEs in a partition join a single dedicated MP2MP tunnel.
The procedures in this document are intentionally simpler than the IR mesh described in RFC 6514: they do not require each PE on the MP2MP tunnel to send a Selective P-Multicast Service Interface (S-PMSI) A-D route for the P2MP tunnel it roots, nor do they require each PE to send a Leaf A-D route to each P2MP root in the mesh.
To speed up convergence, PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE; it will then receive traffic from all PEs, discarding those whose label does not correspond to its chosen Upstream PE, but avoids waiting for new Leaf A-D routes to propagate when the Upstream PE changes.
The forwarding state specification in Section 2.2 matches the 'When an S-PMSI is a Match for Transmission' and 'Match for Reception' rules for the 'Flat Partitioning' method in RFC 7582, except that rules about (C-*,C-*) are not applicable since this document always requires (C-*,C-*-BIDIR) S-PMSI A-D routes for VPNs supporting C-BIDIR flows.
For a (C-*,C-G-BIDIR) S-PMSI A-D route received from PEy's Upstream PE, if PEy itself also advertises the route, PEy maintains a (C-*,C-G-BIDIR) forwarding state with IR provider tunnel leaves being the originators of the S-PMSI A-D route and all relevant Leaf A-D routes (those whose Route Key matches the MCAST-VPN NLRI of the Upstream PE's S-PMSI).
For (C-*,C-*-BIDIR) 'Sender Only Branches' where a PE only has data to send upstream toward C-RPA with no explicit join state for a bidirectional group, traffic MUST be sent to all PEs in the partition (not just the Upstream PE), because they may have specific (C-*,C-G-BIDIR) join states that the sending PE is unaware of.
If a PE (PEx) is connected to a VPN site and its next-hop interface to a C-RPA is a VRF interface, PEx MUST advertise a (C-*,C-*-BIDIR) S-PMSI A-D route regardless of whether it has any local BIDIR-PIM join states corresponding to the C-RPA learned from its CEs.
Other PEs in the same partition MUST use the downstream-allocated MPLS label carried in PEx's S-PMSI A-D route PTA when sending relevant C-BIDIR flows to PEx.
PEx MAY also advertise one or more (C-*,C-G-BIDIR) S-PMSI A-D routes if selective distribution trees are needed for those groups and the corresponding C-RPA is in the site PEx connects to; this may be triggered when C-*,C-G-BIDIR traffic rate exceeds a threshold.
PEy MUST advertise a Leaf A-D route in response to receiving and importing a (C-*,C-*-BIDIR) S-PMSI A-D route with IR PTA from PEx when PEy chooses PEx as its Upstream PE for the C-RPA and has relevant local BIDIR-PIM join states received from its CEs.
PEy MUST withdraw the corresponding Leaf A-D route if: (a) the S-PMSI A-D route is withdrawn, (b) PEy no longer chooses PEx as its Upstream PE and only advertises Leaf A-D routes in response to its Upstream PE's S-PMSI, or (c) relevant local join state is pruned.
Similar to the (C-*,C-*-BIDIR) case, PEy MUST advertise a Leaf A-D route in response to receiving a (C-*,C-G-BIDIR) S-PMSI A-D route with IR PTA from its Upstream PE when it has corresponding local (C-*,C-G-BIDIR) join state from its CEs.
The label in the PTA of the Leaf A-D route originated by PEy MUST be allocated specifically for PEx so that arriving traffic labeled with it can be associated with PEx's partition.
This document removes the RFC 6514 requirement that a PE or ASBR take no action on a Leaf A-D route unless it carries an IP-address-specific Route Target identifying that PE/ASBR, when the route key of the Leaf A-D route identifies a (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI.
If PEy has a (C-*,C-G-BIDIR) join state from its CEs but no corresponding S-PMSI A-D route from its Upstream PE, PEy uses the (C-*,C-*-BIDIR) tunnel instead; if no (C-*,C-*-BIDIR) S-PMSI A-D route exists either, the provider tunnel has an empty set of leaves and PEy does not forward relevant traffic across the provider network.
The Leaf A-D route encoding follows RFC 6514 except that Route Targets are set to the same values as in the corresponding S-PMSI A-D route, ensuring the Leaf A-D route is imported by all VRFs that import the S-PMSI A-D route, irrespective of whether the S-PMSI originator is the receiving PE's Upstream PE.
The S-PMSI A-D route advertised by PEx includes a PMSI Tunnel Attribute (PTA) with tunnel type set to Ingress Replication, Leaf Information Required flag set, a downstream-allocated MPLS label that peer PEs in the same partition MUST use when sending C-BIDIR flows to PEx, and the Tunnel Identifier set to a routable address of the originator.
RFC 7740 raises no new security issues. Security considerations for the base MVPN protocol are covered in RFC 6513 and RFC 6514.