Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures
Extracted elements (27)
ADD-PATH is also insufficient to enable SFS for GTM because limiting advertisement to the n-best paths creates an exponential explosion of paths across AS boundaries, yet still cannot guarantee that every PBR sees at least one path via each candidate Upstream PBR. The path-count explosion in multi-AS scenarios (illustrated with a diagram in Section 2.3.4) makes ADD-PATH+SFS unworkable for GTM.
GTM uses BGP-MVPN procedures so that a single control plane governs both VPN and non-VPN multicast. Most MVPN features carry over automatically to GTM: scaling, aggregation, flexible tunnel technology, segmented/non-segmented tunnels, wildcard support, ASM/SSM/bidir multicast, IPv4/IPv6 over either infrastructure, and support for BSR as an RP-to-group mapping protocol.
RD=0 was chosen as the GTM indicator in MCAST-VPN routes because no VRF may be configured with an RD of zero, providing an unambiguous signal that distinguishes GTM routes from VPN-specific routes without requiring a new SAFI or NLRI format.
Service providers using Inclusive Tunnels for GTM should carefully consider scale: there may be many more PBRs for GTM than PEs for a particular VPN. If the PBR set is large and growing but most flows do not need all PBRs, exclusive use of Selective Tunnels may be preferable to Inclusive Tunnels.
SFS cannot be applied to GTM because GTM UMH-eligible routes are of SAFI 1/2/4 and share the same IP prefix NLRI, so route reflectors may choose only the best path to S and suppress other paths. Unlike VPN context where distinct RDs ensure all PEs see all routes to S, there is no mechanism in GTM to guarantee all PBRs see the same set of candidate routes for deterministic forwarder selection.
The alternative UMH-eligible route procedures in Section 2.3.2 (attaching MVPN ECs to the PBR's self-originated route rather than all UMH-eligible routes) exist because some service providers may find it undesirable or impractical to attach VRF Route Import ECs to all UMH-eligible routes. This procedure is only safe when the Next Hop of distributed routes is known to remain unchanged.
A PBR implementing GTM is NOT required to originate an Intra-AS I-PMSI A-D route if it is not using Inclusive Tunnels for GTM AND the distribution of C-multicast Shared/Source Tree Join routes is done in such a manner that the Next Hop of those routes does not change.
Key differences from RFC 7524's GTM procedures: RFC 7716 uses C-multicast Shared/Source Tree Joins (with RD=0) rather than Leaf A-D routes; uses RFC 6514 Leaf A-D NLRI format rather than the RFC 7524-defined format; uses a single RD value of zero (not two distinct RD values with different semantics as in RFC 7524).
The GTM procedures of RFC 7524 are different from and NOT interoperable with the procedures defined in RFC 7716. The two sets can co-exist in the same network only if they are not applied to the same multicast flows or ASM multicast group addresses.
The RT Constraint procedures of RFC 4684 MAY be used to constrain distribution of MCAST-VPN routes carrying import RTs configured for GTM. If RT Constraint is deployed but MCAST-VPN routes carry no RTs, the 'default behavior' for the MCAST-VPN address family specified in draft-ietf-idr-rtc-no-rt is required for proper operation.
For GTM, the UMH-eligible routes are routes of SAFI 1, SAFI 4, or SAFI 2. If the global table has imported SAFI 2 routes, those are the UMH-eligible routes; otherwise SAFI 1 or SAFI 4 routes are used. The Upstream RD is always considered to be zero and is NOT determined from the Selected UMH Route.
If the global table of a particular PBR is NOT configured with any import RTs, a received MCAST-VPN route is processed in the context of the global table only if it carries no RTs or if it carries an upstream-node-identifying RT whose Global Administrator field identifies that PBR. The use of non-upstream-node-identifying RTs is OPTIONAL for GTM.
In order for both sets of GTM procedures (this document's and RFC 7524's) to co-exist in the same network, the PBRs MUST be provisioned so that for any given IP group address in the global table, all egress PBRs use the same set of procedures for that group address.
In the alternative procedure of Section 2.3.2, each PBR MUST originate a BGP route of SAFI 1, 2, or 4 whose NLRI is an IP address of the PBR itself, carrying a VRF Route Import EC and a Source AS EC. The NLRI address, Global Administrator field of the EC, and Next Hop field MUST all be the same address. This procedure MUST NOT be used in scenarios where the Next Hop may change during route distribution.
The Local Administrator field of the upstream-node-identifying RT MUST always be set to zero for GTM, thereby implicitly identifying the global table rather than a VRF. This applies in exactly the same situations where the upstream-node-identifying RT is used in the MVPN specification.
The procedures in Section 2.3.1 (UMH-eligible routes of SAFI 1, 2, or 4 carrying VRF Route Import EC and/or Source AS EC) MUST be implemented. The procedures in Sections 2.3.2 and 2.3.3 are OPTIONAL to implement, with the caveat that relying on OPTIONAL procedures may cause interoperability problems.
The Single Forwarder Selection (SFS) procedure defined in Section 9.1.2 of RFC 6513 MUST NOT be used for GTM. In GTM, UMH-eligible routes are of SAFI 1, 2, or 4 (not SAFI 128/129) and share the same prefix NLRI, so route reflectors may suppress duplicates, making it impossible to guarantee all PBRs see the same candidate routes for SFS.
When a PBR originates an MCAST-VPN route in support of GTM, the RD field (for those route types where it is defined) of that route's NLRI MUST be set to zero (64 bits of zero). This distinguishes GTM MCAST-VPN routes from VPN-specific MCAST-VPN routes, since no VRF may have an RD of zero.
When a Source Active A-D route is distributed and does not carry a VRF Route Import EC, the BGP speaker distributing the route MUST NOT change the route's Next Hop field. If the route does carry the VRF Route Import EC, the BGP speaker MAY change the Next Hop to itself.
An OPTIONAL mechanism allows PBRs to constrain distribution of Source Active A-D routes to interested parties: a PBR originating a C-multicast Shared Tree Join for (*,G) dynamically creates an import RT with group address G in the Global Administrator field and zero Local Administrator, then uses RT Constraint (RFC 4684) to advertise interest in routes carrying this RT.
For C-Multicast Source/Shared Tree Joins in GTM, the upstream-node-identifying RT is constructed with the IP address of the Upstream PBR (not Upstream PE). In scenarios where it is known a priori that the Next Hop of these routes does not change, the second RT (based on Next Hop of an I-PMSI A-D route) is not needed.
GTM uses the same SAFI 5 (MCAST-VPN) routes and NLRI format as defined in RFC 6514, with the key adaptation that the RD field is always set to zero. All MCAST-VPN route types (I-PMSI A-D, S-PMSI A-D, Leaf A-D, Source Active A-D, C-multicast Shared/Source Tree Joins) are reused with minimal modifications.
Source Active A-D route originator determination in GTM: if the route carries a VRF Route Import EC, the originating PBR is identified by the Global Administrator field of that EC; if not, the originating PBR is the router identified in the route's Next Hop field. This differs from MVPN where the originator is determined by RD uniqueness.
The Protocol Boundary Router (PBR) is the core router at the boundary between the core network and attachment networks. PBRs play the role of PE routers in MVPN, storing GTM routing information in the global table rather than a VRF, and using BGP-MVPN procedures adapted for the global table.
BGP routes for GTM carry IP multicast group addresses that are only valid within a certain scope. If a BGP route containing a group address is distributed outside the boundaries where that group address is meaningful, unauthorized distribution of multicast data flows may occur.
In GTM, some protections present in VPN deployments are lost: import of MCAST-VPN routes is not restricted to authorized VRFs, and the RT infrastructure that controls distribution among VRFs is absent. Care must be taken to avoid deleting or modifying VRF Route Import ECs and Source AS ECs, as incorrect manipulation may cause multicast streams to be lost or misrouted.
MCAST-VPN routes, path attributes (VRF Route Import EC, Source AS EC, Route Target EC) were designed for VPN-only contexts. If these leak into the wider network in a GTM deployment, multicast data flows may be distributed in an unintended and/or unauthorized manner.