Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes
updates
- rfc-6514 — BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
Extracted elements (14)
MSDP SA messages require an RP address for peer RPF checks, but MVPN SA routes carry only (C-S,C-G). An Extended Community was chosen to carry the RP address alongside the MVPN SA route so that MSDP infrastructure can consume it without changes to the MVPN NLRI encoding.
MVPN SA routes functionally replace MSDP SA messages for inter-PE source discovery in 'spt-only' mode, eliminating the need for VPN-specific MSDP sessions between PEs. This leverages BGP hard state, allows route reflectors, and enables VPN extranet policy mechanisms that MSDP cannot provide.
Although both RFC 6514 Section 13 ('rpt-spt' mode) and Section 14 ('spt-only' mode) define MVPN SA routes, MVPN/MSDP SA interoperation described in this document applies only to 'spt-only' mode; 'rpt-spt' mode interoperation is out of scope.
The procedures apply to Global Table Multicast (GTM) per RFC 7716 as well as VPN routing tables, treating the relevant PEs as a PE mesh group for the global table.
A PE MAY treat only the BGP best-selected MVPN SA route for a given (C-S,C-G) as the source of an MSDP SA. If the best route lacks the EC but another route for the same (C-S,C-G) has it, the next best route with the EC SHOULD be chosen.
An MVPN PE MAY be provisioned to generate MSDP SA messages from received MVPN SA routes, with or without local policy control; if triggered, the MVPN SA route is treated as a corresponding MSDP SA received from within the PE mesh group.
If a received MVPN SA route lacks the RP-address EC (e.g., from a legacy PE), the local RP address for the C-G is used; in this case, the MSDP peer that would receive the generated SA SHOULD use local policy to accept it to avoid RPF failure.
MVPN PEs acting as customer RPs or having MSDP sessions in a VPN MUST NOT include other MSDP speakers in the PE mesh group; the PE mesh group is integrated into the rest of the MSDP infrastructure following normal MSDP rules.
The RP address in the MVPN SA RP-address EC is set to the local RP address for C-G if the (C-S,C-G) was learned via PIM Register, or to the RP address from the selected MSDP SA message if learned via MSDP.
When an MVPN PE advertises an MVPN SA route in 'spt-only' mode per RFC 6514, it MUST attach an 'MVPN SA RP-address Extended Community' carrying the RP address for the multicast group.
The 'MVPN SA RP-address Extended Community' is a Transitive IPv4-Address-Specific Extended Community. The Local Administrator field is set to zero, and the Global Administrator field carries the RP address for the multicast group (C-G).
IANA registered value 0x20 ('MVPN SA RP-address Extended Community') in the 'Transitive IPv4-Address-Specific Extended Community Sub-Types' registry.
The capabilities specified in this document introduce no additional security considerations beyond those in RFC 6514 and RFC 3618. Moreover, eliminating VPN-specific MSDP sessions between PEs actually reduces control message amplification caused by redundant MSDP SA and MVPN SA messages being carried in parallel.
When the best MVPN SA route with EC changes, a new MSDP SA is advertised if the RP address from the newly selected route differs; the MSDP SA state associated with the previously advertised message (with the older RP address) is timed out.