RFC 9081

Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes

📅 published July 2021, from ietf

RFC 9081: Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes 🎀

Okay bestie, the quick facts first 💅 This is RFC 9081, written by Z. Zhang and L. Giuliano, both at Juniper Networks. It's a Standards Track document from July 2021 (ISSN 2070-1721), and it updates RFC 6514 🦋

Abstract ✨

This doc explains how MVPN Source-Active (SA) routes and customer Multicast Source Discovery Protocol (MSDP) SA routes can work together 🫶 It's super handy for MVPN provider networks that serve customers who already have an MSDP setup. Without these procedures, the Provider Edge (PE) routers that are customer MSDP peers need VPN-specific MSDP sessions between them, and nobody wants that 😭 This document updates RFC 6514.

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841.

Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9081 🌸

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 💜

Table of Contents 🌈

1.  Introduction
  1.1.  MVPN RPT-SPT Mode
2.  Terminology
  2.1.  Requirements Language
3.  Specification
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay so Section 14 ("Supporting PIM-SM without Inter-Site Shared C-Trees") of [RFC6514] explains how MVPN PEs can discover (C-S,C-G) through MVPN Source-Active A-D routes 👑 Then they send Source Tree Join (C-S,C-G) C-multicast routes toward the ingress PEs to set up shortest path trees (SPTs) for customer Any-Source Multicast (ASM) flows where they have downstream receivers 🌷 (C-*,C-G) C-multicast routes don't get sent among the PEs, so inter-site shared C-Trees aren't used, and this approach is usually called "spt-only" mode 🧚

With this mode, the MVPN Source-Active routes are kinda 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. Either way, PE1 then originates MVPN SA routes so other PEs can learn (C-S,C-G) 🦋

Here's the tea 🍵 [RFC6514] 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 matching (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 [RFC6514] doesn't say PE2 advertises MSDP SA messages to those MSDP peers for the (C-S,C-G) it learns via MVPN SA routes. PE2 would need an MSDP session with PE1 (the one that advertised the MVPN SA messages) to learn the sources via MSDP SA messages so it can 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 it gets 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 🎀 Plus, this MVPN/MSDP SA interoperation has these 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 [RFC2764] mechanisms can be used to propagate (C-S,C-G) information across VPNs with flexible policy control.

Main character energy 👑 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 needs the RP address information to do MSDP peer Reverse Path Forwarding (RPF). So this document describes how to convey the RP address information into the MVPN Source-Active route using an Extended Community, so the info can be shared with an existing MSDP infrastructure 🧚

The procedures also apply to Global Table Multicast (GTM) [RFC7716] 🌈

1.1. MVPN RPT-SPT Mode 🦋

For comparison, another method of supporting customer ASM is generally called "rpt-spt" mode. Section 13 ("Switching from a Shared C-Tree to a Source C-Tree") of [RFC6514] specifies the MVPN SA procedures for that mode, but those SA routes replace PIM-ASM assert and (s,g,rpt) prune mechanisms, not source discovery 🙅‍♀️ MVPN/MSDP SA interoperation for the "rpt-spt" mode is outside the scope of this document. For the rest of the document, the "spt-only" mode is assumed 💅

2. Terminology 💅

Familiarity with MVPN [RFC6513] [RFC6514] and MSDP [RFC3618] protocols and procedures is assumed. Here's some terminology listed for convenience 🫶

ASM:          Any-Source Multicast

SPT:          source-specific Shortest Path Tree

RPT:          Rendezvous Point Tree

C-S:          a multicast source address, identifying a multicast
              source located at a VPN customer site

C-G:          a multicast group address used by a VPN customer

C-RP:         a multicast Rendezvous Point for a VPN customer

C-multicast:  a multicast for a VPN customer

EC:           Extended Community

GTM:          Global Table Multicast, i.e., a multicast in the
              default or global routing table vs. a VPN Routing and
              Forwarding (VRF) table

2.1. Requirements Language 📜

Here's the official key-word fine print, and it's important 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Specification 👑

The MVPN PEs that act as customer RPs, or that have one or more MSDP sessions in a VPN (or the global table in the case of GTM), are treated as an MSDP mesh group for that VPN (or the global table). In the rest of the document, this is referred to as the PE mesh group 🌸 This PE mesh group MUST NOT include other MSDP speakers, and it's integrated into the rest of the MSDP infrastructure for the VPN (or the global table) following normal MSDP rules and practices 💖

When an MVPN PE advertises an MVPN SA route following the procedures in [RFC6514] for the "spt-only" mode, it MUST attach an "MVPN SA RP-address Extended Community" 🎀 This is a Transitive IPv4-Address-Specific Extended Community. The Local Administrator field is set to zero, and the Global Administrator field is set to an RP address determined as follows:

  • If the (C-S,C-G) is learnt as a result of the PIM Register mechanism, the local RP address for the C-G is used.
  • If the (C-S,C-G) is learnt as a result of incoming MSDP SA messages, the RP address in the selected MSDP SA message is used.

In addition to the procedures in [RFC6514], an MVPN PE may be provisioned to generate MSDP SA messages from received MVPN SA routes, with or without local policy control 🦋 If a received MVPN SA route triggers an MSDP SA message, the MVPN SA route is treated as if a corresponding MSDP SA message was received from within the PE mesh group, and normal MSDP procedure is followed (e.g., an MSDP SA message is advertised to other MSDP peers outside the PE mesh group). The (S,G) information comes from the (C-S,C-G) encoding in the MVPN SA Network Layer Reachability Information (NLRI), and the RP address comes from the "MVPN SA RP-address EC" mentioned above. If the received MVPN SA route doesn't have the EC (this could be from a legacy PE that can't attach the EC), the local RP address for the C-G is used. In that case, the RP inserted into the MSDP SA message for the C-G might actually be the MSDP peer that the generated MSDP message is advertised to, which makes the peer discard it due to RPF failure. To get around that problem, the peer SHOULD use local policy to accept the MSDP SA message 🙈

Heads up: this RPF failure case is the reason the peer SHOULD use local policy to accept the MSDP SA message.

An MVPN PE MAY treat only the best MVPN SA route selected by the BGP route selection process (instead of all MVPN SA routes) for a given (C-S,C-G) as a received MSDP SA message, and advertise the corresponding MSDP message 🌈 In that case, if the selected best MVPN SA route doesn't have the "MVPN SA RP-address EC" but another route for the same (C-S, C-G) does, then the next best route with the EC SHOULD be chosen. As a result, if/when the best MVPN SA route with the EC changes, a new MSDP SA message is advertised if the RP address determined according to the newly selected MVPN SA route is different from before. The MSDP SA state associated with the previously advertised MSDP SA message with the older RP address will be timed out ⭐

6.1. Normative References 📚

Okay bestie, these are the must-reads. The spec leans on all of them, so they're basically the homework you can't skip 🫶

6.2. Informative References 🌸

These ones are the cute background reading. Super helpful for context, but the spec doesn't depend on them to work 💅

Acknowledgements 🫶

The authors gave a huge shoutout to Eric Rosen, Vinod Kumar, Yajun Liu, Stig Venaas, Mankamana Mishra, Gyan Mishra, Qin Wu, and Jia He for their reviews, comments, questions, and suggestions on this document. Literally the squad that made it better ✨💖

Authors' Addresses 🎀

Zhaohui Zhang
Juniper Networks

Email: zzhang@juniper.net


Lenny Giuliano
Juniper Networks

Email: lenny@juniper.net
📦 where this page comes from