RFC 7740

Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication

📅 published January 2016, from ietf

Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication 🎀

okay bestie, the title block is giving serious main character energy 👑. RFC 7740 was written by Z. Zhang and Y. Rekhter (both at Juniper Networks) and A. Dolganow (at Alcatel-Lucent). It's a Standards Track doc, ISSN 2070-1721, dated January 2016. The title block doesn't list anything it obsoletes or updates, so nothing gets replaced or patched here 🫶.

Abstract ✨

okay so [RFC6513] ("Multicast in MPLS/BGP IP VPNs") explains how to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels 🦋. This doc is the one that shows how that partial mesh can be simulated with Ingress Replication 💖. The result is that a service provider can use Ingress Replication to offer transparent bidirectional multicast to its VPN customers, and it's honestly so iconic 💅.

Status of This Memo 📝

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741 🌸.

Info about the current status of this doc, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7740 ✨.

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 🧚. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
  1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Control State . . . . . . . . . . . . . . . . . . . . . .   4
  2.2.  Forwarding State  . . . . . . . . . . . . . . . . . . . .   6
3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  4.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1. Introduction 🌈

okay so Section 11.2 of RFC 6513 ("Partitioned Sets of PEs") describes two ways to carry Bidirectional PIM (BIDIR-PIM) [RFC5015] C-flow traffic over a provider core. The core doesn't get used as the Rendezvous Point Link (RPL), and there's no Designated Forwarder election needed 🦋.

With these two methods, all Provider Edges (PEs) of a particular VPN get split into partitions. Each partition is all the PEs that pick the same PE as their Upstream PE with respect to the C-RPA (the Rendezvous Point Address in the customer's address space) 💅. A PE must discard bidirectional C-flow traffic from PEs that aren't in the same partition as itself. Not me doing the discarding, but the rules are the rules 🙈.

Section 11.2.3 of RFC 6513 ("Partial Mesh of MP2MP P-Tunnels") gets that discard behavior without needing an extra PE Distinguisher Label. How? All PEs in the same partition join one MP2MP tunnel that's dedicated to that partition and use it to send traffic. All traffic arriving on the tunnel comes from PEs in the same partition, so it's always accepted ✨.

RFC 6514 specifies the BGP encodings and procedures used to implement Multicast VPN (MVPN) as specified in RFC 6513. The details about MP2MP tunnels are specified in [RFC7582] 🎀.

RFC 7582 assumes that an MP2MP P-tunnel is realized either via BIDIR-PIM [RFC5015] or via MP2MP mLDP (Multipoint extensions for LDP) [RFC6388]. Both of those need signaling and state not just on PEs, but on the P routers too 😭. This document describes how the MP2MP tunnel can be simulated with a mesh of P2MP tunnels, and each of those is instantiated by Ingress Replication (IR) [RFC6513] [RFC6514] 💖.

The procedures here are different from the ones used to set up the mesh of Ingress Replication tunnels in RFC 6514. The procedures in this document don't require each PE on the MP2MP tunnel to send a Selective P-Multicast Service Interface (S-PMSI) auto-discovery route (A-D route) for the P2MP tunnel that the PE is the root for. They also don't require each PE to send a Leaf A-D route to the root of each P2MP tunnel in the mesh 🧚.

Because it uses Ingress Replication, this scheme has both the advantages and the disadvantages of Ingress Replication in general 🍓.

1.1. Terminology 📖

This document uses terminology from [RFC5015], [RFC6513], [RFC6514], and [RFC7582] 💜.

1.2. Requirements Language 🫶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥.

2. Operation ⚙️

In the following sections, the originator of an S-PMSI A-D route or Leaf A-D route is determined from the "originating router's IP address" field of the corresponding route 🌸.

2.1. Control State 🎀

Here's the big one, iykyk 💅. If a PE, let's call it PEx, is connected to a site of a given VPN, and PEx's next-hop interface to some C-RPA is a VPN Routing and Forwarding (VRF) interface, then PEx MUST advertise a (C-,C--BIDIR) S-PMSI A-D route. This applies regardless of whether PEx has any local BIDIR-PIM join states for that C-RPA learned from its Customer Edges (CEs) 🦋.

PEx MAY also advertise one or more (C-,C-G-BIDIR) S-PMSI A-D routes. It's optional, and only if selective distribution trees are needed for those C-G-BIDIR groups and the corresponding C-RPA is in the site that PEx connects to 🌈. For example, the (C-,C-G-BIDIR) S-PMSI A-D routes could be triggered when the (C-*,C-G-BIDIR) traffic rate goes above a threshold. This may require measuring the traffic in both directions, due to the nature of BIDIR-PIM 🙈. Fan-out could also be taken into account ✨.

The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with the tunnel type set to Ingress Replication and the Leaf Information Required flag set. They also carry a downstream allocated MPLS label that other PEs in the same partition MUST use when sending relevant C-BIDIR flows to this PE. The Tunnel Identifier field in the PTA is set to a routable address of the originator 💖.

This specification doesn't prevent sharing of labels between P-tunnels. For instance, a label could be shared by a (C-,C--BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route originated by a given PE. Note that other specifications put constraints on how that can be done, e.g., [MVPN-EXTRANET] 🧚.

Now, if some other PE, PEy, receives and imports into one of its VRFs any (C-,C--BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, and the VRF has any local BIDIR-PIM join state that PEy has received from its CEs, and PEy chooses PEx as its Upstream PE with respect to the C-RPA for those states, then PEy MUST advertise a Leaf A-D route in response 🔥. Or, if PEy has received and imported into one of its VRFs a (C-,C--BIDIR) S-PMSI A-D route from PEx before, then upon receiving any local BIDIR-PIM join state from its CEs in the VRF, with PEx being the Upstream PE for those states' C-RPA, PEy MUST advertise a Leaf A-D route 🫶.

The encoding of the Leaf A-D route is as specified in RFC 6514, with one exception. The Route Targets are set to the same value as in the corresponding S-PMSI A-D route, so the Leaf A-D route gets imported by all VRFs that import the corresponding S-PMSI A-D route 💅. This holds whether or not the originator of the S-PMSI A-D route is the Upstream PE from a receiving PE's perspective 🌸.

The label in the PTA of the Leaf A-D route originated by PEy MUST be allocated specifically for PEx. That way, when traffic arrives with that label, the traffic can be associated with the partition (represented by PEx) 🍓. This specification doesn't prevent sharing of labels between P-tunnels either. For example, a label could be shared by a (C-,C--BIDIR) and a (C-*,C-G-BIDIR) Leaf A-D route originated by a given PE. Other specifications put constraints on how that can be done, e.g., [MVPN-EXTRANET] 🌈.

Note that RFC 6514 requires that a PE or an ASBR (Autonomous System Border Router) take no action with regard to a Leaf A-D route unless that Leaf A-D route carries an IP-address-specific Route Target identifying the PE/ASBR. This document removes that requirement when the route key of a Leaf A-D route identifies a (C-,C--BIDIR) or a (C-*,C-G-BIDIR) S-PMSI 🦋.

To speed up convergence, PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE with respect to the C-RPA. The point is so PEy starts receiving traffic from its new Upstream PE immediately, instead of waiting until the new Leaf A-D route for that Upstream PE is received by the sending PEs 🚀. With that, PEy receives traffic from all PEs. Some traffic arrives with the label matching PEy's choice of Upstream PE, and some arrives with a different label. The traffic in the latter case gets discarded 🙈.

Similar to the (C-,C--BIDIR) case, if PEy receives and imports into one of its VRFs any (C-,C-G-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, PEy chooses PEx as its Upstream PE with respect to the C-RPA, and PEy has corresponding local (C-,C-G-BIDIR) join state that it received from its CEs in the VRF, then PEy MUST advertise a Leaf A-D route in response 💖. Or, if PEy has received and imported into one of its VRFs a (C-,C-G-BIDIR) S-PMSI A-D route before, then upon receiving its local (C-,C-G-BIDIR) join state from its CEs in the VRF, PEy MUST advertise a Leaf A-D route 👑.

The encoding of the Leaf A-D route is similar to the (C-,C--BIDIR) case. Likewise, PEy MAY advertise a Leaf A-D route even if it does not choose PEx as its Upstream PE with respect to the C-RPA 🧚.

PEy MUST withdraw the corresponding Leaf A-D route if any of the following conditions are true 😭:

  • the (C-,C--BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is withdrawn.
  • PEy no longer chooses the originator PEx as its Upstream PE with respect to C-RPA, and PEy only advertises Leaf A-D routes in response to its Upstream PE's S-PMSI A-D route.
  • if relevant local join state is pruned.
Part 1 ends here, bestie 🫶 Part 2 picks up with the rest of the doc, so stay tuned 💜

2.2. Forwarding State 🦋

Okay so this part is about forwarding state, which is basically what each PE actually does with the traffic 🌸 The vibe is that it copies the "Flat Partitioning" rules from [RFC7582] for "When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is a 'Match for Reception'", with one twist. The (C-,C-) rules don't apply here, because this doc requires that (C-,C--BIDIR) S-PMSI A-D routes are always originated for a VPN that supports C-BIDIR flows. No exceptions, bestie 💅

For the (C-,C-G-BIDIR) S-PMSI A-D route that a PEy receives and imports into one of its VRFs from its Upstream PE with respect to the C-RPA, PEy keeps a (C-,C-G-BIDIR) forwarding state in that VRF if PEy itself advertises the S-PMSI A-D route there ✨ The Ingress Replication provider tunnel leaves are the originators of the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant Leaf A-D routes are the ones whose Route Key field has the same info as the MCAST-VPN Network Layer Reachability Information (NLRI) of the (C-*,C-G-BIDIR) S-PMSI A-D route that the Upstream PE advertised. Main character energy 👑

Now for the (C-,C--BIDIR) S-PMSI A-D route that a PEy receives and imports into one of its VRFs from its Upstream PE with respect to a C-RPA. If PEy itself advertises the S-PMSI A-D route in the VRF, it maintains appropriate forwarding states in that VRF for the ranges of bidirectional groups the C-RPA is responsible for 🍓 The provider tunnel leaves are the originators of the S-PMSI A-D route and all relevant Leaf A-D routes. The relevant Leaf A-D routes are the routes whose Route Key field contains the same information as the MCAST-VPN NLRI of the (C-,C--BIDIR) S-PMSI A-D route advertised by the Upstream PE. This is for the so-called "Sender Only Branches", where a router only has data to send upstream towards the C-RPA but no explicit join state for a particular bidirectional group 🫶

Here's the tea 🍵 The traffic has to be sent to all PEs (not just the Upstream PE) in the partition, because they may have specific (C-,C-G-BIDIR) join states that this PEy isn't aware of, while there are no corresponding (C-,C-G-BIDIR) S-PMSI A-D and Leaf A-D routes. Iconic behaviour, honestly 😭

For a (C-,C-G-BIDIR) join state that a PEy has received from its CEs in a VRF, if there is no corresponding (C-,C-G-BIDIR) S-PMSI A-D route from its Upstream PE in the VRF, PEy keeps a matching forwarding state in the VRF. The provider tunnel leaves are the originators of the (C-,C--BIDIR) S-PMSI A-D route and all relevant Leaf A-D routes, same as the "Sender Only Branches" case above 🧚 The relevant Leaf A-D routes are the routes whose Route Key field contains the same info as the MCAST-VPN NLRI of the (C-,C--BIDIR) S-PMSI A-D route originated by the Upstream PE. And if there is also no (C-,C--BIDIR) S-PMSI A-D route from its Upstream PE, then the provider tunnel has an empty set of leaves, and PEy does not forward relevant traffic across the provider network. Quiet, but make it make sense 🤫

3. Security Considerations 🔐

This document raises no new security issues. Security considerations for the base protocol are covered in [RFC6513] and [RFC6514]. Please go read those two, they're the real security tea 🚨😭

4. References ✨

4.1. Normative References 💜

4.2. Informative References 🌈

  • [MVPN-EXTRANET] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", Work in Progress, draft-ietf-bess-mvpn-extranet-06, January 2016.
  • [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, <http://www.rfc-editor.org/info/rfc5015>.
  • [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.

Acknowledgements 🫶

We would like to thank Eric Rosen for his comments and suggestions for some text used in the document. Shoutout to Eric, the real MVP 👑

Authors' Addresses 🎀

Zhaohui Zhang
Juniper Networks
10 Technology Park Dr.
Westford, MA  01886
United States

Email: zzhang@juniper.net


Yakov Rekhter
Juniper Networks


Andrew Dolganow
Alcatel-Lucent
600 March Rd.
Ottawa, ON  K2K 2E6
Canada

Email: andrew.dolganow@alcatel-lucent.com
📦 where this page comes from