of [RFC 6514
] specifies the procedures for MVPN PEs to discover (C-S,C-G) via MVPN Source-Active A-D routes and then send Source Tree Join (C-S,C-G) C-multicast routes towards the ingress PEs to establish shortest path trees (SPTs) for customer Any-Source Multicast (ASM) flows for which they have downstream receivers. (C-*,C-G) C-multicast routes are not sent among the PEs, so inter-site shared C-Trees are not used, and the method is generally referred to as "spt-only" mode.
With this mode, the MVPN Source-Active routes are functionally similar to MSDP Source-Active messages. For a VPN, one or more of the PEs, say PE1, either acts as a C-RP and learns of (C-S,C-G) via PIM Register messages or has MSDP sessions with some MSDP peers and learns of (C-S,C-G) via MSDP SA messages. In either case, PE1 will then originate MVPN SA routes for other PEs to learn (C-S,C-G).
] only specifies that a PE receiving the MVPN SA routes, say PE2, will advertise Source Tree Join (C-S,C-G) C-multicast routes if it has corresponding (C-*,C-G) state learnt from its Customer Edge (CE). PE2 may also have MSDP sessions for the VPN with other C-RPs at its site, but [RFC 6514
] does not specify that PE2 advertises MSDP SA messages to those MSDP peers for the (C-S,C-G) that it learns via MVPN SA routes. PE2 would need to have an MSDP session with PE1 (that advertised the MVPN SA messages) to learn the sources via MSDP SA messages for it to advertise the MSDP SA to its local peers. To make things worse, unless blocked by policy control, PE2 would in turn advertise MVPN SA routes because of those MSDP SA messages that it receives from PE1, which are redundant and unnecessary. Also notice that the PE1-PE2 MSDP session is VPN specific (i.e., only for a single VPN), while the BGP sessions over which the MVPN routes are advertised are not.
If a PE does advertise MSDP SA messages based on received MVPN SA routes, the VPN-specific MSDP sessions with other PEs are no longer needed. Additionally, this MVPN/MSDP SA interoperation has the following inherent benefits for a BGP-based solution.
MSDP SA refreshes are replaced with BGP hard state.
Route reflectors can be used instead of having peer-to-peer sessions.
VPN extranet [RFC 2764] mechanisms can be used to propagate (C-S,C-G) information across VPNs with flexible policy control.
While MSDP Source-Active routes contain the source, group, and RP addresses of a given multicast flow, MVPN Source-Active routes only contain the source and group. MSDP requires the RP address information in order to perform MSDP peer Reverse Path Forwarding (RPF). Therefore, this document describes how to convey the RP address information into the MVPN Source-Active route using an Extended Community so this information can be shared with an existing MSDP infrastructure.
The procedures apply to Global Table Multicast (GTM) [RFC 7716
] as well.
For comparison, another method of supporting customer ASM is generally referred to as "rpt-spt" mode. Section 13
of [RFC 6514
] specifies the MVPN SA procedures for that mode, but those SA routes are a replacement for PIM-ASM assert and (s,g,rpt) prune mechanisms, not for source discovery purposes. MVPN/MSDP SA interoperation for the "rpt-spt" mode is outside the scope of this document. In the rest of the document, the "spt-only" mode is assumed.