RFC 8293

A Framework for Multicast in Network Virtualization over Layer 3

📅 published January 2018, from ietf

RFC 8293: A Framework for Multicast in Network Virtualization over Layer 3 🎀

Request for Comments: 8293
Category: Informational 🦋
ISSN: 2070-1721
Date: January 2018
Authors: A. Ghanwani (Dell), L. Dunbar, M. McBride (Huawei), V. Bannai (Google), R. Krishnan (Dell)
Obsoletes/Updates: The title block doesn't list any RFCs this one obsoletes or updates.

Abstract 💖

okay so this doc gives you a framework for multicast traffic in networks that use Network Virtualization over Layer 3 (NVO3) ✨ it covers both infrastructure multicast and application-specific multicast, bestie. it walks through the different mechanisms you can use to deliver that traffic, and what the data plane and control plane look like for each one 🧚

Status of This Memo 🌸

so this one is NOT an Internet Standards Track spec 🙈 it's just published for informational purposes.

it's still a product of the IETF, and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, though. see Section 2 of RFC 7841 for the deets.

for the current status of this document, any errata, and how to give feedback, check out https://www.rfc-editor.org/info/rfc8293 💅

Copyright Notice 🌈

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 they're in effect on the date of publication. please read these carefully, bestie, because they spell out 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're provided without warranty as described in the Simplified BSD License.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Infrastructure Multicast  . . . . . . . . . . . . . . . .   3
  1.2.  Application-Specific Multicast  . . . . . . . . . . . . .   4
2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   4
3.  Multicast Mechanisms in Networks That Use NVO3  . . . . . . .   5
  3.1.  No Multicast Support  . . . . . . . . . . . . . . . . . .   6
  3.2.  Replication at the Source NVE . . . . . . . . . . . . . .   6
  3.3.  Replication at a Multicast Service Node . . . . . . . . .   8
  3.4.  IP Multicast in the Underlay  . . . . . . . . . . . . . .  10
  3.5.  Other Schemes . . . . . . . . . . . . . . . . . . . . . .  11
4.  Simultaneous Use of More Than One Mechanism . . . . . . . . .  12
5.  Other Issues  . . . . . . . . . . . . . . . . . . . . . . . .  12
  5.1.  Multicast-Agnostic NVEs . . . . . . . . . . . . . . . . .  12
  5.2.  Multicast Membership Management for DC with VMs . . . . .  13
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction ✨

okay so Network Virtualization over Layer 3 (NVO3) [RFC7365] is a technology built to solve problems that show up when you're building big, multi-tenant data centers (DCs) that lean hard on server virtualization [RFC7364]. it's giving scale 👑

this document is a framework for supporting multicast traffic in a network that uses NVO3. both infrastructure multicast and application-specific multicast are in scope 🦋 it describes a bunch of mechanisms you can use to deliver that traffic, plus the considerations for each one, so you can pick your fave 💅

you're expected to already know the terminology and concepts from the NVO3 Framework [RFC7365] and NVO3 Architecture [RFC8014] documents, so go catch up on those first if you need to 🧚

1.1. Infrastructure Multicast

infrastructure multicast is the networking stuff that needs multicast or broadcast delivery, like Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), and so on. some of these are covered in Sections 5 and 6 of RFC 3819 [RFC3819] 🌸 the good news is you can solve these without involving multicast in the underlay network at all.

for example, with ARP/ND, a Network Virtualization Authority (NVA) can hand out the IP address to Media Access Control (MAC) address mappings to all of the Network Virtualization Edges (NVEs). then an NVE can trap ARP Request and/or ND Neighbor Solicitation messages from the Tenant Systems (TSs) attached to it and answer them itself, so you don't need to broadcast or multicast those messages at all. it's so efficient 🙈

for DHCP, the NVE can be configured to forward those messages using the DHCP relay function [RFC2131] 💜

of course, you can support all of these infrastructure multicast protocols natively if the underlay gives you multicast transport. even so, it can still be worth using the optimizations above to cut down how much of this traffic lands in the network 🍓

1.2. Application-Specific Multicast

application-specific multicast is multicast traffic that's created and consumed by user applications 📱 a few of these apps are described elsewhere [DC-MC]. this kind of multicast can be either Source-Specific Multicast (SSM) or Any-Source Multicast (ASM) [RFC3569], and it has the following characteristics:

receiver hosts are expected to subscribe to multicast content using protocols like IGMP [RFC3376] (IPv4) or Multicast Listener Discovery (MLD) [RFC2710] (IPv6). multicast sources and listeners take part in these protocols using addresses that live in the TS address domain 🫶
the set of multicast listeners for each multicast group may not be known in advance. because of that, it may not be possible or practical for an NVA to get the list of participants for each multicast group ahead of time 🌈

2. Terminology and Abbreviations 🎀

in this doc, the terms host, Tenant System (TS), and Virtual Machine (VM) are used interchangeably to mean an end station that originates or consumes data packets. same thing, different names, bestie 💖

here's the abbreviation list, copied exactly:

ASM:  Any-Source Multicast

IGMP: Internet Group Management Protocol

LISP: Locator/ID Separation Protocol

MSN:  Multicast Service Node

RLOC: Routing Locator

NVA:  Network Virtualization Authority

NVE:  Network Virtualization Edge

NVGRE:  Network Virtualization using GRE

PIM:  Protocol-Independent Multicast

SSM:  Source-Specific Multicast

TS:   Tenant System

VM:   Virtual Machine
VN:   Virtual Network

VTEP: VXLAN Tunnel End Point

VXLAN:  Virtual eXtensible LAN

3. Multicast Mechanisms in Networks That Use NVO3 🧚

in NVO3 environments, traffic between NVEs gets carried inside an encapsulation like VXLAN [RFC7348] [VXLAN-GPE], Network Virtualization using Generic Routing Encapsulation (NVGRE) [RFC7637], Geneve [Geneve], Generic UDP Encapsulation [GUE], and so on 🦋

here's the tea ☕ what makes NVO3 networks different from other networks is that some NVEs, especially the ones implemented in servers, might not support regular multicast protocols like PIM. the only thing they might be able to do is encapsulate data packets from VMs with an outer unicast header. so it's really important for NVO3 networks to have ways to support multicast as a network capability for NVEs. you need to map multicast traffic from VMs (users/applications) to an equivalent multicast capability inside the NVE, or figure out the outer destination address if the NVE doesn't support native multicast (e.g., PIM) or IGMP 💅

with NVO3, there are lots of possible ways multicast can get handled. we're going to talk about some of the attributes of these four methods:

no multicast support
replication at the source NVE
replication at a multicast service node
IP multicast in the underlay

these methods are briefly mentioned in the NVO3 Framework [RFC7365] and NVO3 Architecture [RFC8014] documents. this document gives you more details about the basic mechanisms behind each one, and talks about the issues and trade-offs of each 🌸

we know other methods are possible too, like [EDGE-REP], but we're focusing on the above four because they're the most common ones ⭐

also, when you're picking a multicast mechanism, it's useful to think about how it affects any multicast congestion control mechanisms that applications might be using to get the system dynamics they want 🙈 and the same rules for Explicit Congestion Notification (ECN) would apply to multicast traffic being encapsulated as they do to unicast traffic [RFC6040]. no double standards, periodt 💜

3.1. No Multicast Support

in this scenario, there's zero support for multicast traffic when using the overlay 😭 this method can only work if the following conditions are met:

all of the application traffic in the network is unicast traffic, and the only multicast/broadcast traffic is from ARP/ND protocols.
an NVA is used by all of the NVEs to figure out the mapping of a given TS's MAC and IP address to the NVE it's attached to. in other words, there's no data-plane learning. address resolution requests via ARP/ND that are issued by the TSs must be resolved by the NVE they're attached to 🫶

with this approach, it's not possible to support application-specific multicast 💀 however, some multicast/broadcast applications can still work without multicast. DHCP is one example, since it can be supported by using the DHCP relay function [RFC2131] ✨

the main drawback of this approach, even for unicast traffic, is that it's not possible to start communicating with a TS that doesn't already have a mapping to an NVE at the NVA. this is a real problem when the NVE is implemented in a physical switch and the TS is a physical end station that hasn't registered with the NVA 🥺

3.2. Replication at the Source NVE ✨

okay so this is the "make the source do all the work" method 💅 The overlay tries to give you multicast service without asking the underlay for anything beyond plain unicast. 🦋 A multicast or broadcast transmission happens by replicating the packet at the source NVE and making copies, one for each destination NVE the multicast packet needs to reach. 📦

For this to work, the source NVE must know, a priori, the IP addresses of all destination NVEs that need to receive the packet 🔍 For ARP/ND, that means knowing the IP addresses of all the NVEs that have TSs in the VN of the TS that generated the request. 🌸

For application-specific multicast traffic, a method similar to receiver-sites registration for a particular multicast group, described in [LISP-Signal-Free], can be used 💜 The registrations from different receiver sites can be merged at the NVA, which can build a multicast replication list that includes all NVEs with receivers attached for a particular multicast group. 👑 The NVA maintains the replication list for each specific multicast group. 🧚 Also, using receiver-sites registration does not necessarily mean the source NVE has to do replication 🙈 If the NVA indicates that multicast packets are encapsulated to multicast service nodes, then there's no replication at the NVE. 🫶

Receiver-sites registration is achieved by egress NVEs doing IGMP/MLD snooping to keep track of which attached TSs have subscribed to a given IP multicast group. 🎀 When the members of a multicast group are outside the NVO3 domain, the NVO3 gateways need to keep track of the remote members of each multicast group 🌈 The NVEs and NVO3 gateways then communicate the multicast groups that are of interest to the NVA. ✨ If the membership isn't communicated to the NVA, and it's necessary to stop TSs attached to an NVE that haven't subscribed to a multicast group from receiving the multicast traffic, the NVE would need to maintain multicast group membership information. 😭

Without IGMP/MLD snooping, the traffic gets delivered to all TSs that are part of the VN. 💀

In multihoming environments, meaning those where a TS is attached to more than one NVE, the NVA would be expected to give information to all of the NVEs under its control about all of the NVEs that such a TS is attached to 🦋 The ingress NVE can then pick any one of those NVEs as the egress NVE for the data frames heading to the multi-homed TS. 💖

This method needs multiple copies of the same packet to all NVEs that participate in the VN. 🍓 For example, if a tenant subnet is spread across 50 NVEs, the packet would have to be replicated 50 times at the source NVE. 😳 Obviously, this approach creates more traffic on the network, which can cause congestion when the network load is high. 💅 It also creates an issue with the forwarding performance of the NVE. 🔥

Note that this method is similar to what was used in Virtual Private LAN Service (VPLS) [RFC4762] before support of Multiprotocol Label Switching (MPLS) multicast [RFC7117] 🌸 There are some similarities between MPLS Virtual Private Network (VPN) and NVO3, but there are some key differences, bestie:

The attachment from Customer Edge (CE) to Provider Edge (PE) in VPNs is somewhat static, whereas in a DC that allows VMs to migrate anywhere, the TS attachment to NVE is much more dynamic. 🏃‍♀️💨
The number of PEs that a single VPN customer is attached to in an MPLS VPN environment is normally far less than the number of NVEs that a VN's VMs are attached to in a DC. 👀

When a VPN customer has multiple multicast groups, "Multicast VPN" [RFC6513] combines all of those multicast groups within each VPN client into one single multicast group in the MPLS (or VPN) core 🦋 The result is that messages from any of the multicast groups belonging to one VPN customer reach all the PE nodes of that client. 💜 In other words, any messages belonging to any multicast groups under customer X reach all PEs of customer X. 🌈 When customer X is attached to only a handful of PEs, using this approach doesn't result in an excessive waste of bandwidth in the provider's network. 🍓

In a DC environment, a typical hypervisor-based virtual switch may only support on the order of 10's of VMs (as of this writing) 🫠 A subnet with N VMs may, in the worst case, be spread across N virtual switches (vSwitches). 😱 Using an "MPLS VPN multicast" approach in that scenario would require creating a multicast group in the core so the VN can reach all N NVEs. 🧠 If only a small percentage of this client's VMs take part in application-specific multicast, a great number of NVEs will receive multicast traffic that isn't forwarded to any of their attached VMs, which is a considerable waste of bandwidth. 🗑️💀

So yeah, the multicast VPN solution may not scale in a DC environment with dynamic attachment of VNs to NVEs and a greater number of NVEs for each VN. 📉🥺

3.3. Replication at a Multicast Service Node ✨

With this method, all multicast packets get sent using a unicast tunnel encapsulation from the ingress NVE to a Multicast Service Node (MSN) 🎀 The MSN then makes multiple copies of the packet and delivers a copy, using a unicast tunnel encapsulation, to each of the NVEs that are part of the multicast group the packet is meant for. 🧚

This mechanism is similar to the LAN Emulation (LANE) specification from the Asynchronous Transfer Mode (ATM) Forum [LANE] 🦢 The MSN is similar to the Rendezvous Point (RP) in Protocol Independent Multicast - Sparse Mode (PIM-SM), but it's different in that the user data traffic is carried by the NVO3 tunnels. 💖

Here are the possible ways for the MSN to get the membership information for each multicast group:

The MSN can get this membership information from the IGMP/MLD report messages that TSs send in response to IGMP/MLD query messages from the MSN. 📨 The IGMP/MLD query messages are sent from the MSN to the NVEs, which then forward the query messages to the TSs attached to them. 🔁 An IGMP/MLD query message sent out by the MSN to an NVE is encapsulated with the MSN address in the outer IP source address field and the address of the NVE in the outer IP destination address field. 🍰 An encapsulated IGMP/MLD query message also has a virtual network (VN) identifier (corresponding to the VN that the TSs belong to) in the outer header, and a multicast address in the inner IP destination address field. 🪄 When the NVE receives the encapsulated IGMP/MLD query message, it establishes a mapping for "MSN address" to "multicast address", decapsulates the received encapsulated IGMP/MLD message, and multicasts the decapsulated query message to the TSs that belong to the VN attached to that NVE. 🌷 An IGMP/MLD report message sent by a TS includes the multicast address and the address of the TS. 📝 With the proper "MSN address" to "multicast address" mapping, the NVEs can encapsulate all multicast data frames containing the "multicast address" with the address of the MSN in the outer IP destination address field. 🎯
The MSN can get the membership information from the NVEs that have the capability to establish multicast groups, by snooping native IGMP/MLD messages (note that the communication must be specific to the multicast addresses) or by having the NVA get the information from the NVEs and then have the MSN communicate with the NVA. 🕵️‍♀️ This approach requires additional protocol between the MSN and the NVEs. 🧩

Unlike the method described in Section 3.2, there's no performance impact at the ingress NVE, and there aren't any issues with multiple copies of the same packet going from the source NVE to the MSN 🙌 However, there are still issues with multiple copies of the same packet on links that are common to the paths from the MSN to each of the egress NVEs 😤 Additional issues that come with this method include the availability of the MSN, methods to scale the services the MSN offers, and the suboptimality of the delivery paths. 📉

Last but not least, the IP address of the source NVE must be preserved in packet copies created at the multicast service node if data-plane learning is in use 🚨 This could cause problems if IP source address Reverse Path Forwarding (RPF) checks are in use. 🥹💅

3.4. IP Multicast in the Underlay ✨

okay so this one is giving "let the underlay do the heavy lifting" 💅 the ingress NVE slaps the right IP multicast address into the tunnel encapsulation header so the packet can reach the exact set of NVEs that want it. ✨ The underlay protocol could be any flavour of PIM, or a protocol-dependent multicast like [ISIS-Multicast]. 🦋

If an NVE hangs out with its attached TSs over a Layer 2 network, there are a couple of ways it can support application-specific multicast:

The NVE only does basic IGMP/MLD snooping, and the "TS routers" handle the application-specific multicast. 🌸 This scheme doesn't use the underlay IP multicast protocols at all. Instead, routers that are themselves TSs attached to the NVE handle the multicast protocols for the application-specific multicast. We call these routers TS routers. 🧚
The NVE can act as a pseudo multicast router for its directly attached TSs and map IGMP/MLD messages to the messages the underlay IP multicast protocols need. 💖

ngl this is the good part: with this method, none of the scaling and congestion problems from Sections 3.2 and 3.3 show up. 🙈 BUT there are other issues, which we'll get into below. 💀

With PIM-SM, the number of flows needed is (n*g), where n is the number of source NVEs sourcing packets for the group and g is the number of groups. 😭 Bidirectional PIM (BIDIR-PIM) is more scalable, since the number of flows needed is just g. 🫶 Unfortunately, lots of vendors still don't fully support BIDIR or have limits on how they implement it. 🥲 [RFC6831] describes using SSM as an alternative to BIDIR, as long as the NVEs have a way to learn each other's IP addresses so they can join all of the SSM Shortest Path Trees (SPTs) and build an underlay SSM IP multicast tunnel solution. 🎀

Without any extra mechanism (for example, using an NVA for address resolution), optimal delivery would need a separate group for each VN for infrastructure multicast, plus a separate group for each application-specific multicast address within a tenant. 📦

Another thing to keep in mind: only the lower 23 bits of the IP address get mapped to the outer MAC address (whether you're on IPv4 or IPv6), so if there's equipment that prunes multicast at Layer 2, you'll get some aliasing. 👀

Last but not least, you'd need a mechanism to efficiently provision these addresses for each group. 🍓

There are more optimizations possible, but they come with their own restrictions. ✨ For example, a set of tenants might be restricted to some subset of NVEs, and they could all share the same outer IP multicast group address. 🌈 This, however, introduces a problem of suboptimal delivery: even if a particular tenant within the group of tenants doesn't have a presence on one of the NVEs that another one does, the multicast packets would still get delivered to that NVE. 😬 It also adds extra network management burden to figure out which tenants should be part of the same tenant group (based on the NVEs they share). That kind of dilutes the whole value proposition of NVO3, which is to completely decouple the overlay and physical network design so VMs can go anywhere in the DC. 💜

Multicast schemes like Bit Indexed Explicit Replication (BIER) [RFC8279] may be able to optimize things by letting the underlay network provide optimum multicast delivery without requiring routers in the core of the network to keep per-multicast-group state. 🧠✨

3.5. Other Schemes 🌟

There are still other mechanisms that try to combine some of the advantages of the above methods by offering multiple replication points, each with a limited degree of replication [EDGE-REP]. 🦋 These schemes are a trade-off between how much replication happens at an intermediate node (e.g., a router) versus doing all of the replication at the source NVE, or all of the replication at a multicast service node. 💅

4. Simultaneous Use of More Than One Mechanism 🎀

While we've talked about the mechanisms in the previous section one at a time, implementations can totally rely on more than one of them. 🫶 For example, the method of Section 3.1 could be used to minimize ARP/ND, while at the same time, multicast applications may be supported by one, or a combination, of the other methods. 🧚 For small multicast groups, source NVE replication or a multicast service node may be attractive, while for larger multicast groups, using multicast in the underlay may be preferable. 🌸

5. Other Issues 💖

5.1. Multicast-Agnostic NVEs 🙈

Some hypervisor-based NVEs don't process or recognize IGMP/MLD frames. 💀 Those NVEs just encapsulate the IGMP/MLD messages the same way they do regular data frames. 🍓

By default, a TS router periodically sends IGMP/MLD query messages to all the hosts in the subnet, which triggers the hosts that are interested in the multicast stream to send back IGMP/MLD reports. 📣 So that the MSN can get updated multicast group information, the MSN can also send the IGMP/MLD query message, comprising a client-specific multicast address encapsulated in an overlay header, to all of the NVEs that the TSs in the VN are attached to. 🦋

However, the MSN may not always know the client-specific multicast addresses. 🤷‍♀️ To do multicast filtering, the MSN has to snoop the IGMP/MLD messages between TSs and their corresponding routers so it can maintain the multicast membership. 🎀 For the MSN to snoop those messages between TSs and their router, the NVA needs to configure the NVE to send copies of the IGMP/MLD messages to the MSN, in addition to the default behaviour of sending them to the TSs' routers. 🫶 For example, the NVA has to tell the NVEs to encapsulate data frames with the Destination Address (DA) set to 224.0.0.2 (the DA of IGMP report) to the TSs' router and MSN. 🌈

This process is similar to "Source Replication" described in Section 3.2, except the NVEs only replicate the message to the TSs' router and MSN. 💜

5.2. Multicast Membership Management for DC with VMs 🖥️

For DCs with virtualized servers, VMs can be added, deleted, or moved super easily. ✨ When VMs are added, deleted, or moved, the NVEs they're attached to change. 🔄

When a VM is deleted from an NVE, or a new VM is added to an NVE, the VM management system should notify the MSN to send the IGMP/MLD query messages to the relevant NVEs (as described in Section 3.3), so the multicast membership can be updated promptly. 🫶

Otherwise, if VM attachments to NVEs change (within the configured default time interval that the TS routers use for IGMP/MLD queries), multicast data may not reach the VM(s) that moved. 😭💀

6. Security Considerations 🔐

This document does not introduce any new security considerations beyond what is described in the NVO3 Architecture document [RFC8014]. 🛡️

7. IANA Considerations 📋

This document does not require any IANA actions. ✅

8. Summary 🎀

This document has identified various mechanisms for supporting application-specific multicast in networks that use NVO3. 🧚 It highlights the basics of each mechanism and some of the issues with them. 💅 As solutions are developed, the protocols would need to consider the use of these mechanisms, and coexistence may be a consideration. 🌸 It also highlights some of the requirements for supporting multicast applications in an NVO3 network. 🦋

9. References 📚

9.1. Normative References 🌟

[RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
           A. Thyagarajan, "Internet Group Management Protocol,
           Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
           <https://www.rfc-editor.org/info/rfc3376>.

[RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in
           MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
           February 2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC7364]  Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
           Kreeger, L., and M. Napierala, "Problem Statement:
           Overlays for Network Virtualization", RFC 7364,
           DOI 10.17487/RFC7364, October 2014,
           <https://www.rfc-editor.org/info/rfc7364>.

[RFC7365]  Lasserre, M., Balus, F., Morin, T., Bitar, N., and
           Y. Rekhter, "Framework for Data Center (DC) Network
           Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
           2014, <https://www.rfc-editor.org/info/rfc7365>.

[RFC8014]  Black, D., Hudson, J., Kreeger, L., Lasserre, M., and
           T. Narten, "An Architecture for Data-Center Network
           Virtualization over Layer 3 (NVO3)", RFC 8014,
           DOI 10.17487/RFC8014, December 2016,
           <https://www.rfc-editor.org/info/rfc8014>.

9.2. Informative References 📚

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>. DHCP, the classic, still going strong 💖
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>. MLD for IPv6, the multicast group drama starter pack 🧚
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July 2003, <https://www.rfc-editor.org/info/rfc3569>. SSM overview, very clean, very iconic ✨
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, <https://www.rfc-editor.org/info/rfc3819>. BCP 89 is the wise-elder advice column, bestie 👑
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>. VPLS with LDP signalling, a whole mouthful 🍓
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>. ECN tunnelling, the congestion signal that survives the trip 🦋
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>. LISP for multicast, the separation queen 👑
[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <https://www.rfc-editor.org/info/rfc7117>. multicast over VPLS, ngl this one slaps 🔥
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>. VXLAN, the overlay icon of all time 🌈✨
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <https://www.rfc-editor.org/info/rfc7637>. NVGRE, the other overlay in the group chat 💅
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>. BIER, bit index replication, so precise it's giving math 🧮
[DC-MC] McBride, M. and H. Liu, "Multicast in the Data Center Overview", Work in Progress, draft-mcbride-armd-mcast-overview-02, July 2012. an early draft that set the mood 🌸
[EDGE-REP] Marques, P., Fang, L., Winkworth, D., Cai, Y., and P. Lapukhov, "Edge multicast replication for BGP IP VPNs.", Work in Progress, draft-marques-l3vpn-mcast-edge-01, June 2012. edge replication for BGP IP VPNs, the edge is sharp 🦋
[Geneve] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Network Virtualization Encapsulation", Work in Progress, draft-ietf-nvo3-geneve-05, September 2017. Geneve, the newer encapsulation with main character energy 💖
[GUE] Herbert, T., Yong, L., and O. Zia, "Generic UDP Encapsulation", Work in Progress, draft-ietf-intarea-gue-05, December 2017. GUE, UDP encapsulation doing the most ✨
[ISIS-Multicast] Yong, L., Weiguo, H., Eastlake, D., Qu, A., Hudson, J., and U. Chunduri, "IS-IS Protocol Extension For Building Distribution Trees", Work in Progress, draft-yong-isis-ext-4-distribution-tree-03, October 2014. IS-IS building distribution trees, the tree-planting era 🌳
[LANE] ATM Forum, "LAN Emulation Over ATM: Version 1.0", ATM Forum Technical Committee, af-lane-0021.000, January 1995. LAN emulation over ATM, a true vintage moment 🎀
[LISP-Signal-Free] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Work in Progress, draft-ietf-lisp-signal-free-multicast-07, November 2017. signal-free LISP multicast, the quiet flex 🤫
[VXLAN-GPE] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-05, October 2017. VXLAN-GPE, VXLAN but make it extensible 🌈💜

Acknowledgments 🫶

Huge thank-yous to Dino Farinacci, Erik Nordmark, Lucy Yong, Nicolas Bouliane, Saumya Dikshit, Joe Touch, Olufemi Komolafe, and Matthew Bocci for their valuable comments and suggestions. you all are literally the reason this doc is so good 💖

Authors' Addresses 🦋

Anoop Ghanwani, Dell

Email: anoop@alumni.duke.edu

Linda Dunbar, Huawei Technologies

5340 Legacy Drive, Suite 1750
Plano, TX  75024
United States of America

Phone: (469) 277 5840
Email: ldunbar@huawei.com

Mike McBride, Huawei Technologies

Email: mmcbride7@gmail.com

Vinay Bannai, Google

Email: vbannai@gmail.com

Ram Krishnan, Dell

Email: ramkri123@gmail.com

📦 where this page comes from

ietf: rfc8293 2018-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms