draft-ietf-nvo3-mcast-framework-11.txt   rfc8293.txt 
NVO3 working group A. Ghanwani
Internet Draft Dell
Intended status: Informational L. Dunbar
Expires: November 8, 2018 M. McBride
Huawei
V. Bannai
Google
R. Krishnan
Dell
October 23, 2017
A Framework for Multicast in Network Virtualization Overlays
draft-ietf-nvo3-mcast-framework-11
Status of this Memo
This Internet-Draft is submitted in full conformance with the Internet Engineering Task Force (IETF) A. Ghanwani
provisions of BCP 78 and BCP 79. Request for Comments: 8293 Dell
Category: Informational L. Dunbar
ISSN: 2070-1721 M. McBride
Huawei
V. Bannai
Google
R. Krishnan
Dell
January 2018
This Internet-Draft is submitted in full conformance with the A Framework for Multicast in Network Virtualization over Layer 3
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Abstract
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This document provides a framework for supporting multicast traffic
months and may be updated, replaced, or obsoleted by other documents in a network that uses Network Virtualization over Layer 3 (NVO3).
at any time. It is inappropriate to use Internet-Drafts as Both infrastructure multicast and application-specific multicast are
reference material or to cite them other than as "work in progress." discussed. It describes the various mechanisms that can be used for
delivering such traffic as well as the data plane and control plane
considerations for each of the mechanisms.
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/shadow.html published for informational purposes.
This Internet-Draft will expire on November 8, 2016. This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
Internet-Draft A framework for multicast in NVO3 Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8293.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Abstract
This document provides a framework of supporting multicast traffic
in a network that uses Network Virtualization Overlays (NVO3). Both
infrastructure multicast and application-specific multicast are
discussed. It describes the various mechanisms that can be used for
delivering such traffic as well as the data plane and control plane
considerations for each of the mechanisms.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Infrastructure multicast..................................3 1.1. Infrastructure Multicast . . . . . . . . . . . . . . . . 3
1.2. Application-specific multicast............................4 1.2. Application-Specific Multicast . . . . . . . . . . . . . 4
1.3. Terminology clarification.................................4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
2. Acronyms.......................................................4 3. Multicast Mechanisms in Networks That Use NVO3 . . . . . . . 5
3. Multicast mechanisms in networks that use NVO3.................5 3.1. No Multicast Support . . . . . . . . . . . . . . . . . . 6
3.1. No multicast support......................................6 3.2. Replication at the Source NVE . . . . . . . . . . . . . . 6
3.2. Replication at the source NVE.............................7 3.3. Replication at a Multicast Service Node . . . . . . . . . 8
3.3. Replication at a multicast service node...................9 3.4. IP Multicast in the Underlay . . . . . . . . . . . . . . 10
3.4. IP multicast in the underlay.............................10 3.5. Other Schemes . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Other schemes............................................12 4. Simultaneous Use of More Than One Mechanism . . . . . . . . . 12
4. Simultaneous use of more than one mechanism...................12 5. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Other issues..................................................13 5.1. Multicast-Agnostic NVEs . . . . . . . . . . . . . . . . . 12
5.1. Multicast-agnostic NVEs..................................13 5.2. Multicast Membership Management for DC with VMs . . . . . 13
5.2. Multicast membership management for DC with VMs..........13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Summary.......................................................14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations.......................................14 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations...........................................14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
Internet-Draft A framework for multicast in NVO3 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References....................................................14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References.....................................14
9.2. Informative References...................................15
10. Acknowledgments..............................................16
1. Introduction 1. Introduction
Network virtualization using Overlays over Layer 3 (NVO3)[RFC7365] Network Virtualization over Layer 3 (NVO3) [RFC7365] is a technology
is a technology that is used to address issues that arise in that is used to address issues that arise in building large, multi-
building large, multitenant data centers that make extensive use of tenant data centers (DCs) that make extensive use of server
server virtualization [RFC7364]. virtualization [RFC7364].
This document provides a framework for supporting multicast traffic, This document provides a framework for supporting multicast traffic
in a network that uses Network Virtualization using Overlays over in a network that uses NVO3. Both infrastructure multicast and
Layer 3 (NVO3). Both infrastructure multicast and application- application-specific multicast are considered. It describes various
specific multicast are considered. It describes the various mechanisms, and the considerations of each of them, that can be used
mechanisms and considerations that can be used for delivering such for delivering such traffic in networks that use NVO3.
traffic in networks that use NVO3.
The reader is assumed to be familiar with the terminology as defined The reader is assumed to be familiar with the terminology and
in the NVO3 Framework document [RFC7365] and NVO3 Architecture concepts as defined in the NVO3 Framework [RFC7365] and NVO3
document [RFC8014]. Architecture [RFC8014] documents.
1.1. Infrastructure multicast 1.1. Infrastructure Multicast
Infrastructure multicast is a capability needed by networking Infrastructure multicast refers to networking services that require
services, such as Address Resolution Protocol (ARP), Neighbor multicast or broadcast delivery, such as Address Resolution Protocol
Discovery (ND), Dynamic Host Configuration Protocol (DHCP), (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol
multicast Domain Name Server (mDNS), etc. RFC3819 Section 5 and 6 (DHCP), multicast Domain Name Server (mDNS), etc., some of which are
have detailed description for some of the infrastructure multicast described in Sections 5 and 6 of RFC 3819 [RFC3819]. It is possible
[RFC3819]. It is possible to provide solutions for these that do to provide solutions for these services that do not involve multicast
not involve multicast in the underlay network. In the case of in the underlay network. For example, in the case of ARP/ND, a
ARP/ND, a network virtualization authority (NVA) can be used for Network Virtualization Authority (NVA) can be used for distributing
distributing the mappings of IP address to MAC address to all the IP address to Media Access Control (MAC) address mappings to all
network virtualization edges (NVEs). The NVEs can then trap ARP of the Network Virtualization Edges (NVEs). An NVE can then trap ARP
Request/ND Neighbor Solicitation messages from the TSs (Tenant Request and/or ND Neighbor Solicitation messages from the Tenant
System) that are attached to it and respond to them, thereby Systems (TSs) that are attached to it and respond to them, thereby
eliminating the need to for broadcast/multicast of such messages. eliminating the need for the broadcast/multicast of such messages.
In the case of DHCP, the NVE can be configured to forward these In the case of DHCP, the NVE can be configured to forward these
messages using a helper function. messages using the DHCP relay function [RFC2131].
Of course it is possible to support all of these infrastructure Of course, it is possible to support all of these infrastructure
multicast protocols natively if the underlay provides multicast multicast protocols natively if the underlay provides multicast
transport. However, even in the presence of multicast transport, it transport. However, even in the presence of multicast transport, it
may be beneficial to use the optimizations mentioned above to reduce may be beneficial to use the optimizations mentioned above to reduce
the amount of such traffic in the network. the amount of such traffic in the network.
Internet-Draft A framework for multicast in NVO3 1.2. Application-Specific Multicast
1.2. Application-specific multicast
Application-specific multicast traffic are originated and consumed
by user applications. The Application-specific multicast, which can
be either Source-Specific Multicast (SSM) or Any-Source Multicast
(ASM)[RFC3569], has the following characteristics:
1. Receiver hosts are expected to subscribe to multicast content Application-specific multicast traffic refers to multicast traffic
using protocols such as IGMP [RFC3376] (IPv4) or MLD [RFC2710] that originates and is consumed by user applications. Several such
(IPv6). Multicast sources and listeners participant in these applications are described elsewhere [DC-MC]. Application-specific
protocols using addresses that are in the Tenant System address multicast may be either Source-Specific Multicast (SSM) or Any-Source
domain. Multicast (ASM) [RFC3569] and has the following characteristics:
2. The list of multicast listeners for each multicast group is not 1. Receiver hosts are expected to subscribe to multicast content
known in advance. Therefore, it may not be possible for an NVA using protocols such as IGMP [RFC3376] (IPv4) or Multicast
to get the list of participants for each multicast group ahead Listener Discovery (MLD) [RFC2710] (IPv6). Multicast sources and
of time. listeners participate in these protocols using addresses that are
in the TS address domain.
1.3. Terminology clarification 2. The set of multicast listeners for each multicast group may not
be known in advance. Therefore, it may not be possible or
practical for an NVA to get the list of participants for each
multicast group ahead of time.
2. Acronyms & Terminology 2. Terminology and Abbreviations
In this document, the terms host, tenant system (TS) and virtual In this document, the terms host, Tenant System (TS), and Virtual
machine (VM) are used interchangeably to represent an end station Machine (VM) are used interchangeably to represent an end station
that originates or consumes data packets. that originates or consumes data packets.
ASM: Any-Source Multicast ASM: Any-Source Multicast
IGMP: Internet Group Management Protocol IGMP: Internet Group Management Protocol
LISP: Locator/ID Separation Protocol LISP: Locator/ID Separation Protocol
MSN: Multicast Service Node MSN: Multicast Service Node
RLOC: Routing Locator RLOC: Routing Locator
NVA: Network Virtualization Authority NVA: Network Virtualization Authority
NVE: Network Virtualization Edge
NVGRE: Network Virtualization using GRE NVE: Network Virtualization Edge
Internet-Draft A framework for multicast in NVO3 NVGRE: Network Virtualization using GRE
PIM: Protocol-Independent Multicast PIM: Protocol-Independent Multicast
SSM: Source-Specific Multicast SSM: Source-Specific Multicast
TS: Tenant system
VM: Virtual Machine TS: Tenant System
VN: Virtual Network VM: Virtual Machine
VN: Virtual Network
VTEP: VxLAN Tunnel End Points VTEP: VXLAN Tunnel End Point
VXLAN: Virtual eXtensible LAN VXLAN: Virtual eXtensible LAN
3. Multicast mechanisms in networks that use NVO3 3. Multicast Mechanisms in Networks That Use NVO3
In NVO3 environments, traffic between NVEs is transported using an In NVO3 environments, traffic between NVEs is transported using an
encapsulation such as Virtual eXtensible Local Area Network (VXLAN) encapsulation such as VXLAN [RFC7348] [VXLAN-GPE], Network
[RFC7348,VXLAN-GPE], Network Virtualization Using Generic Routing Virtualization using Generic Routing Encapsulation (NVGRE) [RFC7637],
Encapsulation (NVGRE) [RFC7637], Geneve [Geneve], Generic UDP Geneve [Geneve], Generic UDP Encapsulation [GUE], etc.
Encapsulation (GUE) [GUE], etc.
What makes NVO3 different from any other network is that some NVEs, What makes networks using NVO3 different from other networks is that
especially the NVE implemented on server, might not support PIM or some NVEs, especially NVEs implemented in servers, might not support
other native multicast mechanisms. They might just encapsulate the regular multicast protocols such as PIM. Instead, the only
data packets from VMs with an outer unicast header. Therefore, it is capability they may support would be that of encapsulating data
packets from VMs with an outer unicast header. Therefore, it is
important for networks using NVO3 to have mechanisms to support important for networks using NVO3 to have mechanisms to support
multicast as a network capability for NVEs, to map multicast traffic multicast as a network capability for NVEs, to map multicast traffic
from VMs (users/applications) to an equivalent multicast capability from VMs (users/applications) to an equivalent multicast capability
inside the NVE, or to figure out the outer destination address if inside the NVE, or to figure out the outer destination address if NVE
NVE does not support native multicast (e.g. PIM) or IGMP. does not support native multicast (e.g., PIM) or IGMP.
Besides the need to support ARP and ND, there are several
applications that require the support of multicast and/or broadcast
in data centers [DC-MC]. With NVO3, there are many possible ways
that multicast may be handled in such networks. We discuss some of
the attributes of the following four methods:
1. No multicast support. With NVO3, there are many possible ways that multicast may be handled
in such networks. We discuss some of the attributes of the following
four methods:
2. Replication at the source NVE. 1. No multicast support
3. Replication at a multicast service node. 2. Replication at the source NVE
4. IP multicast in the underlay. 3. Replication at a multicast service node
Internet-Draft A framework for multicast in NVO3 4. IP multicast in the underlay
These methods are briefly mentioned in the NVO3 Framework [RFC7365] These methods are briefly mentioned in the NVO3 Framework [RFC7365]
and NVO3 architecture [RFC8014] document. This document provides and NVO3 Architecture [RFC8014] documents. This document provides
more details about the basic mechanisms underlying each of these more details about the basic mechanisms underlying each of these
methods and discusses the issues and trade-offs of each. methods and discusses the issues and trade-offs of each.
We note that other methods are also possible, such as [EDGE-REP], We note that other methods are also possible, such as [EDGE-REP], but
but we focus on the above four because they are the most common. we focus on the above four because they are the most common.
It worth noting that when selecting a multicast replication It is worth noting that when selecting a multicast mechanism, it is
strategy, it is useful to consider the interaction with any useful to consider the impact of these on any multicast congestion
multicast congestion control that applications may be using to control mechanisms that applications may be using to obtain the
obtain the desired system dynamics. In addition, for multicast we desired system dynamics. In addition, the same rules for Explicit
follow the same rules for ECN as any non-multicast traffic would and Congestion Notification (ECN) would apply to multicast traffic being
be in conformance with the appropriate encap draft [RFC6040] encapsulated, as for unicast traffic [RFC6040].
3.1. No multicast support 3.1. No Multicast Support
In this scenario, there is no support whatsoever for multicast In this scenario, there is no support whatsoever for multicast
traffic when using the overlay. This method can only work if the traffic when using the overlay. This method can only work if the
following conditions are met: following conditions are met:
1. All of the application traffic in the network is unicast 1. All of the application traffic in the network is unicast traffic,
traffic and the only multicast/broadcast traffic is from ARP/ND and the only multicast/broadcast traffic is from ARP/ND
protocols. protocols.
2. An NVA is used by the NVEs to determine the mapping of a given 2. An NVA is used by all of the NVEs to determine the mapping of a
Tenant System's (TS's) MAC/IP address to its NVE. In other given TS's MAC and IP address to the NVE that it is attached to.
words, there is no data plane learning. Address resolution In other words, there is no data-plane learning. Address
requests via ARP/ND that are issued by the TSs must be resolved resolution requests via ARP/ND that are issued by the TSs must be
by the NVE that they are attached to. resolved by the NVE that they are attached to.
With this approach, it is not possible to support application- With this approach, it is not possible to support application-
specific multicast. However, certain multicast/broadcast specific multicast. However, certain multicast/broadcast
applications such as DHCP can be supported by use of a helper applications can be supported without multicast; for example, DHCP,
function in the NVE. which can be supported by use of DHCP relay function [RFC2131].
The main drawback of this approach, even for unicast traffic, is
that it is not possible to initiate communication with a TS for
which a mapping to an NVE does not already exist in the NVA. This
is a problem in the case where the NVE is implemented in a physical
switch and the TS is a physical end station that has not registered
with the NVA.
Internet-Draft A framework for multicast in NVO3 The main drawback of this approach, even for unicast traffic, is that
it is not possible to initiate communication with a TS for which a
mapping to an NVE does not already exist at the NVA. This is a
problem in the case where the NVE is implemented in a physical switch
and the TS is a physical end station that has not registered with the
NVA.
3.2. Replication at the source NVE 3.2. Replication at the Source NVE
With this method, the overlay attempts to provide a multicast With this method, the overlay attempts to provide a multicast service
service without requiring any specific support from the underlay, without requiring any specific support from the underlay, other than
other than that of a unicast service. A multicast or broadcast that of a unicast service. A multicast or broadcast transmission is
transmission is achieved by replicating the packet at the source achieved by replicating the packet at the source NVE and making
NVE, and making copies, one for each destination NVE that the copies, one for each destination NVE that the multicast packet must
multicast packet must be sent to. be sent to.
For this mechanism to work, the source NVE must know, a priori, the For this mechanism to work, the source NVE must know, a priori, the
IP addresses of all destination NVEs that need to receive the IP addresses of all destination NVEs that need to receive the packet.
packet. For the purpose of ARP/ND, this would involve knowing the For the purpose of ARP/ND, this would involve knowing the IP
IP addresses of all the NVEs that have TSs in the virtual network addresses of all the NVEs that have TSs in the VN of the TS that
(VN) of the TS that generated the request. For the support of generated the request.
application-specific multicast traffic, a method similar to that of
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
construct a multicast replication-list inclusive of all NVEs to
which receivers for a particular multicast group are attached. The
replication-list for each specific multicast group is maintained by
the NVA. Note: Using LISP-signal-free does not necessarily mean the
head-end (i.e. NVE) must do replication. If the mapping database
(i.e. NVA) indicates that packets are encapsulated to multicast
RLOCs, then there is no replication happening at the NVE.
The receiver-sites registration is achieved by egress NVEs For the support of application-specific multicast traffic, a method
performing the IGMP/MLD snooping to maintain state for which similar to that of receiver-sites registration for a particular
attached TSs have subscribed to a given IP multicast group. When multicast group, described in [LISP-Signal-Free], can be used. The
the members of a multicast group are outside the NVO3 domain, it is registrations from different receiver sites can be merged at the NVA,
necessary for NVO3 gateways to keep track of the remote members of which can construct a multicast replication list inclusive of all
each multicast group. The NVEs and NVO3 gateways then communicate NVEs to which receivers for a particular multicast group are
the multicast groups that are of interest to the NVA. If the attached. The replication list for each specific multicast group is
membership is not communicated to the NVA, and if it is necessary to maintained by the NVA. Note that using receiver-sites registration
prevent hosts attached to an NVE that have not subscribed to a does not necessarily mean the source NVE must do replication. If the
multicast group from receiving the multicast traffic, the NVE would NVA indicates that multicast packets are encapsulated to multicast
need to maintain multicast group membership information. service nodes, then there would be no replication at the NVE.
The receiver-sites registration is achieved by egress NVEs performing
IGMP/MLD snooping to maintain the state for which attached TSs have
subscribed to a given IP multicast group. When the members of a
multicast group are outside the NVO3 domain, it is necessary for NVO3
gateways to keep track of the remote members of each multicast group.
The NVEs and NVO3 gateways then communicate with the multicast groups
that are of interest to the NVA. If the membership is not
communicated to the NVA, and if it is necessary to prevent TSs
attached to an NVE that have not subscribed to a multicast group from
receiving the multicast traffic, the NVE would need to maintain
multicast group membership information.
In the absence of IGMP/MLD snooping, the traffic would be delivered In the absence of IGMP/MLD snooping, the traffic would be delivered
to all TSs that are part of the VN. to all TSs that are part of the VN.
In multi-homing environments, i.e., in those where a TS is attached In multihoming environments, i.e., in those where a TS is attached to
to more than one NVE, the NVA would be expected to provide more than one NVE, the NVA would be expected to provide information
information to all of the NVEs under its control about all of the to all of the NVEs under its control about all of the NVEs to which
NVEs to which such a TS is attached. The ingress NVE can choose any such a TS is attached. The ingress NVE can then choose any one of
one of the egress NVEs for the data frames destined towards the TS. those NVEs as the egress NVE for the data frames destined towards the
multi-homed TS.
Internet-Draft A framework for multicast in NVO3
This method requires multiple copies of the same packet to all NVEs This method requires multiple copies of the same packet to all NVEs
that participate in the VN. If, for example, a tenant subnet is that participate in the VN. If, for example, a tenant subnet is
spread across 50 NVEs, the packet would have to be replicated 50 spread across 50 NVEs, the packet would have to be replicated 50
times at the source NVE. Obviously, this approach creates more times at the source NVE. Obviously, this approach creates more
traffic to the network that can cause congestion when the network traffic to the network that can cause congestion when the network
load is high. This also creates an issue with the forwarding load is high. This also creates an issue with the forwarding
performance of the NVE. performance of the NVE.
Note that this method is similar to what was used in Virtual Private Note that this method is similar to what was used in Virtual Private
LAN Service (VPLS) [RFC4762] prior to support of Multi-Protocol LAN Service (VPLS) [RFC4762] prior to support of Multiprotocol Label
Label Switching (MPLS) multicast [RFC7117]. While there are some Switching (MPLS) multicast [RFC7117]. While there are some
similarities between MPLS Virtual Private Network (VPN) and NVO3, similarities between MPLS Virtual Private Network (VPN) and NVO3,
there are some key differences: there are some key differences:
- The Customer Edge (CE) to Provider Edge (PE) attachment in VPNs is o The attachment from Customer Edge (CE) to Provider Edge (PE) in
somewhat static, whereas in a DC that allows VMs to migrate VPNs is somewhat static, whereas in a DC that allows VMs to
anywhere, the TS attachment to NVE is much more dynamic. migrate anywhere, the TS attachment to NVE is much more dynamic.
- The number of PEs to which a single VPN customer is attached in
an MPLS VPN environment is normally far less than the number of
NVEs to which a VN's VMs are attached in a DC.
When a VPN customer has multiple multicast groups, "Multicast VPN" o The number of PEs to which a single VPN customer is attached in an
[RFC6513] combines all those multicast groups within each VPN MPLS VPN environment is normally far less than the number of NVEs
client to one single multicast group in the MPLS (or VPN) core. to which a VN's VMs are attached in a DC.
The result is that messages from any of the multicast groups
belonging to one VPN customer will reach all the PE nodes of the
client. In other words, any messages belonging to any multicast
groups under customer X will reach all PEs of the customer X. When
the customer X is attached to only a handful of PEs, the use of
this approach does not result in excessive wastage of bandwidth in
the provider's network.
In a DC environment, a typical server/hypervisor based virtual When a VPN customer has multiple multicast groups, "Multicast VPN"
switch may only support 10's VMs (as of this writing). A subnet [RFC6513] combines all those multicast groups within each VPN client
with N VMs may be, in the worst case, spread across N vSwitches. to one single multicast group in the MPLS (or VPN) core. The result
Using "MPLS VPN multicast" approach in such a scenario would is that messages from any of the multicast groups belonging to one
require the creation of a Multicast group in the core for this VN VPN customer will reach all the PE nodes of the client. In other
to reach all N NVEs. If only small percentage of this client's VMs words, any messages belonging to any multicast groups under customer
participate in application specific multicast, a great number of X will reach all PEs of the customer X. When the customer X is
NVEs will receive multicast traffic that is not forwarded to any attached to only a handful of PEs, the use of this approach does not
of their attached VMs, resulting in considerable wastage of result in an excessive waste of bandwidth in the provider's network.
bandwidth.
Internet-Draft A framework for multicast in NVO3 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 be, in the worst case, spread across N virtual
switches (vSwitches). Using an "MPLS VPN multicast" approach in such
a scenario would require the creation of a multicast group in the
core in order for the VN to reach all N NVEs. If only a small
percentage of this client's VMs participate in application-specific
multicast, a great number of NVEs will receive multicast traffic that
is not forwarded to any of their attached VMs, resulting in a
considerable waste of bandwidth.
Therefore, the Multicast VPN solution may not scale in DC Therefore, the multicast VPN solution may not scale in a DC
environment with dynamic attachment of Virtual Networks to NVEs and environment with the dynamic attachment of VNs to NVEs and a greater
greater number of NVEs for each virtual network. number of NVEs for each VN.
3.3. Replication at a multicast service node 3.3. Replication at a Multicast Service Node
With this method, all multicast packets would be sent using a With this method, all multicast packets would be sent using a unicast
unicast tunnel encapsulation from the ingress NVE to a multicast tunnel encapsulation from the ingress NVE to a Multicast Service Node
service node (MSN). The MSN, in turn, would create multiple copies (MSN). The MSN, in turn, would create multiple copies of the packet
of the packet and would deliver a copy, using a unicast tunnel and would deliver a copy, using a unicast tunnel encapsulation, to
encapsulation, to each of the NVEs that are part of the multicast each of the NVEs that are part of the multicast group for which the
group for which the packet is intended. packet is intended.
This mechanism is similar to that used by the Asynchronous Transfer This mechanism is similar to that used by the Asynchronous Transfer
Mode (ATM) Forum's LAN Emulation (LANE) specification [LANE]. The Mode (ATM) Forum's LAN Emulation (LANE) specification [LANE]. The
MSN is similar to the RP (Rendezvous Point) in PIM SM, but different MSN is similar to the Rendezvous Point (RP) in Protocol Independent
in that the user data traffic are carried by the NVO3 tunnels. Multicast - Sparse Mode (PIM-SM), but different in that the user data
traffic is carried by the NVO3 tunnels.
The following are the possible ways for the MSN to get the
membership information for each multicast group:
- The MSN can obtain this membership information from the IGMP/MLD
report messages sent by TSs 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 TSs attached to
them. An IGMP/MLD query messages sent out by the MSN to an NVE is
encapsulated with the MSN address in the outer source address
field and the address of the NVE in the outer destination address
field. The encapsulated IGMP/MLD query messages also has a VNID
for a virtual network (VN) that TSs belong in the outer header and
a multicast address in the inner destination address field. Upon
receiving the encapsulated IGMP/MLD query message, the NVE
establishes a mapping "MSN address" <-> "multicast address",
decapsulates the received encapsulated IGMP/MLD message, and
multicast the decapsulated query message to TSs that belong to the
VN under the NVE. A IGMP/MLD report message sent by a TS includes
the multicast address and the address of the TS. With the proper
"MSN Address" <-> "Multicast-Address" mapping, the NVEs can
Internet-Draft A framework for multicast in NVO3 The following are possible ways for the MSN to get the membership
information for each multicast group:
encapsulate all multicast data frames to the "Multicast-Address" o The MSN can obtain this membership information from the IGMP/MLD
with the address of the MSN in the outer destination address report messages sent by TSs in response to IGMP/MLD query messages
field. from the MSN. The IGMP/MLD query messages are sent from the MSN
to the NVEs, which then forward the query messages to 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. Upon receiving
the encapsulated IGMP/MLD query message, the NVE 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 obtain the membership information from the NVEs that o The MSN can obtain the membership information from the NVEs that
have the capability to establish multicast groups by snooping have the capability to establish multicast groups by snooping
native IGMP/MLD messages (p.s. the communication must be specific native IGMP/MLD messages (note that the communication must be
to the multicast addresses), or by having the NVA obtain the specific to the multicast addresses) or by having the NVA obtain
information from the NVEs, and in turn have MSN communicate with the information from the NVEs and in turn have MSN communicate
the NVA. This approach requires additional protocol between MSN with the NVA. This approach requires additional protocol between
and NVEs. MSN and NVEs.
Unlike the method described in Section 3.2, there is no performance Unlike the method described in Section 3.2, there is no performance
impact at the ingress NVE, nor are there any issues with multiple impact at the ingress NVE, nor are there any issues with multiple
copies of the same packet from the source NVE to the Multicast copies of the same packet from the source NVE to the MSN. However,
Service Node. However, there remain issues with multiple copies of there remain issues with multiple copies of the same packet on links
the same packet on links that are common to the paths from the MSN that are common to the paths from the MSN to each of the egress NVEs.
to each of the egress NVEs. Additional issues that are introduced Additional issues that are introduced with this method include the
with this method include the availability of the MSN, methods to availability of the MSN, methods to scale the services offered by the
scale the services offered by the MSN, and the sub-optimality of the MSN, and the suboptimality of the delivery paths.
delivery paths.
Finally, the IP address of the source NVE must be preserved in Finally, the IP address of the source NVE must be preserved in packet
packet copies created at the multicast service node if data plane copies created at the multicast service node if data-plane learning
learning is in use. This could create problems if IP source address is in use. This could create problems if IP source address Reverse
reverse path forwarding (RPF) checks are in use. Path Forwarding (RPF) checks are in use.
3.4. IP multicast in the underlay 3.4. IP Multicast in the Underlay
In this method, the underlay supports IP multicast and the ingress In this method, the underlay supports IP multicast and the ingress
NVE encapsulates the packet with the appropriate IP multicast NVE encapsulates the packet with the appropriate IP multicast address
address in the tunnel encapsulation header for delivery to the in the tunnel encapsulation header for delivery to the desired set of
desired set of NVEs. The protocol in the underlay could be any NVEs. The protocol in the underlay could be any variant of PIM, or a
variant of Protocol Independent Multicast (PIM), or protocol protocol-dependent multicast, such as [ISIS-Multicast].
dependent multicast, such as [ISIS-Multicast].
If an NVE connects to its attached TSs via a Layer 2 network, there If an NVE connects to its attached TSs via a Layer 2 network, there
are multiple ways for NVEs to support the application specific are multiple ways for NVEs to support the application-specific
multicast: multicast:
Internet-Draft A framework for multicast in NVO3 o The NVE only supports the basic IGMP/MLD snooping function, while
the "TS routers" handle the application-specific multicast. This
- The NVE only supports the basic IGMP/MLD snooping function, let scheme doesn't utilize the underlay IP multicast protocols.
the TSs routers handling the application specific multicast. This Instead routers, which are themselves TSs attached to the NVE,
scheme doesn't utilize the underlay IP multicast protocols. would handle multicast protocols for the application-specific
multicast. We refer to such routers as TS routers.
- The NVE can act as a pseudo multicast router for the directly o The NVE can act as a pseudo multicast router for the directly
attached VMs and support proper mapping of IGMP/MLD's messages to attached TSs and support the mapping of IGMP/MLD messages to the
the messages needed by the underlay IP multicast protocols. messages needed by the underlay IP multicast protocols.
With this method, there are none of the issues with the methods With this method, there are none of the issues with the methods
described in Sections 3.2. described in Sections 3.2 and 3.3 with respect to scaling and
congestion. Instead, there are other issues described below.
With PIM Sparse Mode (PIM-SM), the number of flows required would be With PIM-SM, the number of flows required would be (n*g), where n is
(n*g), where n is the number of source NVEs that source packets for the number of source NVEs that source packets for the group, and g is
the group, and g is the number of groups. Bidirectional PIM (BIDIR- the number of groups. Bidirectional PIM (BIDIR-PIM) would offer
PIM) would offer better scalability with the number of flows better scalability with the number of flows required being g.
required being g. Unfortunately, many vendors still do not fully Unfortunately, many vendors still do not fully support BIDIR or have
support BIDIR or have limitations on its implementation. RFC6831 limitations on its implementation. [RFC6831] describes the use of
[RFC6831] has good description of using SSM as an alternative to SSM as an alternative to BIDIR, provided that the NVEs have a way to
BIDIR if the VTEP/NVE devices have a way to learn of each other's IP learn of each other's IP addresses so that they can join all of the
address so that they could join all SSM SPT's to create/maintain an SSM Shortest Path Trees (SPTs) to create/maintain an underlay SSM IP
underlay SSM IP Multicast tunnel solution. multicast tunnel solution.
In the absence of any additional mechanism, e.g. using an NVA for In the absence of any additional mechanism (e.g., using an NVA for
address resolution, for optimal delivery, there would have to be a address resolution), for optimal delivery, there would have to be a
separate group for each tenant, plus a separate group for each separate group for each VN for infrastructure multicast plus a
multicast address (used for multicast applications) within a tenant. separate group for each application-specific multicast address within
a tenant.
Additional considerations are that only the lower 23 bits of the IP An additional consideration is that only the lower 23 bits of the IP
address (regardless of whether IPv4 or IPv6 is in use) are mapped to address (regardless of whether IPv4 or IPv6 is in use) are mapped to
the outer MAC address, and if there is equipment that prunes the outer MAC address, and if there is equipment that prunes
multicasts at Layer 2, there will be some aliasing. Finally, a multicasts at Layer 2, there will be some aliasing.
mechanism to efficiently provision such addresses for each group
would be required.
There are additional optimizations which are possible, but they come
with their own restrictions. For example, a set of tenants may 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 sub-optimal delivery (even if a particular tenant within the
group of tenants doesn't have a presence on one of the NVEs which
Internet-Draft A framework for multicast in NVO3 Finally, a mechanism to efficiently provision such addresses for each
group would be required.
another one does, the multicast packets would still be delivered to There are additional optimizations that are possible, but they come
with their own restrictions. For example, a set of tenants may 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 be delivered to
that NVE). It also introduces an additional network management that NVE). It also introduces an additional network management
burden to optimize which tenants should be part of the same tenant burden to optimize which tenants should be part of the same tenant
group (based on the NVEs they share), which somewhat dilutes the group (based on the NVEs they share), which somewhat dilutes the
value proposition of NVO3 which is to completely decouple the value proposition of NVO3 (to completely decouple the overlay and
overlay and physical network design allowing complete freedom of physical network design allowing complete freedom of placement of VMs
placement of VMs anywhere within the data center. anywhere within the DC).
Multicast schemes such as BIER (Bit Indexed Explicit Replication) Multicast schemes such as Bit Indexed Explicit Replication (BIER)
[BIER-ARCH] may be able to provide optimizations by allowing the [RFC8279] may be able to provide optimizations by allowing the
underlay network to provide optimum multicast delivery without underlay network to provide optimum multicast delivery without
requiring routers in the core of the network to maintain per- requiring routers in the core of the network to maintain per-
multicast group state. multicast group state.
3.5. Other schemes 3.5. Other Schemes
There are still other mechanisms that may be used that attempt to There are still other mechanisms that may be used that attempt to
combine some of the advantages of the above methods by offering combine some of the advantages of the above methods by offering
multiple replication points, each with a limited degree of multiple replication points, each with a limited degree of
replication [EDGE-REP]. Such schemes offer a trade-off between the replication [EDGE-REP]. Such schemes offer a trade-off between the
amount of replication at an intermediate node (e.g. router) versus amount of replication at an intermediate node (e.g., router) versus
performing all of the replication at the source NVE or all of the performing all of the replication at the source NVE or all of the
replication at a multicast service node. replication at a multicast service node.
4. Simultaneous use of more than one mechanism 4. Simultaneous Use of More Than One Mechanism
While the mechanisms discussed in the previous section have been While the mechanisms discussed in the previous section have been
discussed individually, it is possible for implementations to rely discussed individually, it is possible for implementations to rely on
on more than one of these. For example, the method of Section 3.1 more than one of these. For example, the method of Section 3.1 could
could be used for minimizing ARP/ND, while at the same time, be used for minimizing ARP/ND, while at the same time, multicast
multicast applications may be supported by one, or a combination of, applications may be supported by one, or a combination, of the other
the other methods. For small multicast groups, the methods of methods. For small multicast groups, the methods of source NVE
source NVE replication or the use of a multicast service node may be replication or the use of a multicast service node may be attractive,
attractive, while for larger multicast groups, the use of multicast while for larger multicast groups, the use of multicast in the
in the underlay may be preferable. underlay may be preferable.
Internet-Draft A framework for multicast in NVO3
5. Other issues 5. Other Issues
5.1. Multicast-agnostic NVEs 5.1. Multicast-Agnostic NVEs
Some hypervisor-based NVEs do not process or recognize IGMP/MLD Some hypervisor-based NVEs do not process or recognize IGMP/MLD
frames; i.e. those NVEs simply encapsulate the IGMP/MLD messages in frames, i.e., those NVEs simply encapsulate the IGMP/MLD messages in
the same way as they do for regular data frames. the same way as they do for regular data frames.
By default, TSs router periodically sends IGMP/MLD query messages to By default, a TS router periodically sends IGMP/MLD query messages to
all the hosts in the subnet to trigger the hosts that are interested all the hosts in the subnet to trigger the hosts that are interested
in the multicast stream to send back IGMP/MLD reports. In order for in the multicast stream to send back IGMP/MLD reports. In order for
the MSN to get the updated multicast group information, the MSN can the MSN to get the updated multicast group information, the MSN can
also send the IGMP/MLD query message comprising a client specific also send the IGMP/MLD query message comprising a client-specific
multicast address, encapsulated in an overlay header to all the NVEs multicast address encapsulated in an overlay header to all of the
to which the TSs in the VN are attached. NVEs to which the TSs in the VN are attached.
However, the MSN may not always be aware of the client specific However, the MSN may not always be aware of the client-specific
multicast addresses. In order to perform multicast filtering, the multicast addresses. In order to perform multicast filtering, the
MSN has to snoop the IGMP/MLD messages between TSs and their MSN has to snoop the IGMP/MLD messages between TSs and their
corresponding routers to maintain the multicast membership. In order corresponding routers to maintain the multicast membership. In order
for the MSN to snoop the IGMP/MLD messages between TSs and their for the MSN to snoop the IGMP/MLD messages between TSs and their
router, the NVA needs to configure the NVE to send copies of the router, the NVA needs to configure the NVE to send copies of the
IGMP/MLD messages to the MSN in addition to the default behavior of IGMP/MLD messages to the MSN in addition to the default behavior of
sending them to the TSs' routers; e.g. the NVA has to inform the sending them to the TSs' routers; e.g., the NVA has to inform the
NVEs to encapsulate data frames with DA being 224.0.0.2 (destination NVEs to encapsulate data frames with the Destination Address (DA)
address of IGMP report) to TSs' router and MSN. being 224.0.0.2 (DA of IGMP report) to the TSs' router and MSN.
This process is similar to "Source Replication" described in Section This process is similar to "Source Replication" described in
3.2, except the NVEs only replicate the message to TSs' router and Section 3.2, except the NVEs only replicate the message to the TSs'
MSN. router and MSN.
5.2. Multicast membership management for DC with VMs 5.2. Multicast Membership Management for DC with VMs
For data centers with virtualized servers, VMs can be added, deleted For DCs with virtualized servers, VMs can be added, deleted, or moved
or moved very easily. When VMs are added, deleted or moved, the NVEs very easily. When VMs are added, deleted, or moved, the NVEs to
to which the VMs are attached are changed. which the VMs are attached are changed.
When a VM is deleted from an NVE or a new VM is added to an NVE, the 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 VM management system should notify the MSN to send the IGMP/MLD query
query messages to the relevant NVEs (as described in Section 3.3), messages to the relevant NVEs (as described in Section 3.3) so that
so that the multicast membership can be updated promptly. the multicast membership can be updated promptly.
Internet-Draft A framework for multicast in NVO3 Otherwise, if there are changes of VMs attachment to NVEs (within the
duration of the configured default time interval that the TSs routers
use for IGMP/MLD queries), multicast data may not reach the VM(s)
that moved.
Otherwise, if there are changes of VMs attachment to NVEs, within 6. Security Considerations
the duration of the configured default time interval that the TSs
routers use for IGMP/MLD queries, multicast data may not reach the
VM(s) that moved.
6. Summary 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 This document has identified various mechanisms for supporting
application specific multicast in networks that use NVO3. It application-specific multicast in networks that use NVO3. It
highlights the basics of each mechanism and some of the issues with highlights the basics of each mechanism and some of the issues with
them. As solutions are developed, the protocols would need to them. As solutions are developed, the protocols would need to
consider the use of these mechanisms and co-existence may be a consider the use of these mechanisms, and coexistence may be a
consideration. It also highlights some of the requirements for consideration. It also highlights some of the requirements for
supporting multicast applications in an NVO3 network. supporting multicast applications in an NVO3 network.
7. Security Considerations 9. References
This draft does not introduce any new security considerations beyond
what is described n NVO3 Architecture (RFC8014).
8. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove
this section before publication.
9. References
9.1. Normative References
[RFC3376] Cain B. et al. "Internet Group Management Protocol,
Version 3", October 2002.
[RFC6513] Rosen, E. et al., "Multicast in MPLS/BGP IP VPNs", 9.1. Normative References
February 2012.
[RFC7364] Narten, T. et al., "Problem statement: Overlays for [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
network virtualization", October 2014. A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>.
[RFC7365] Lasserre, M. et al., "Framework for data center (DC) [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in
network virtualization", October 2014. MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513,
February 2012, <https://www.rfc-editor.org/info/rfc6513>.
Internet-Draft A framework for multicast in NVO3 [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>.
[RFC8014] Narten, T. et al.," An Architecture for Overlay Networks [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and
(NVO3)", RFC8014, Dec. 2016. Y. Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <https://www.rfc-editor.org/info/rfc7365>.
9.2. Informative References [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>.
[RFC2710] S. Deering et al, "Multicast Listener Discovery (MLD) for 9.2. Informative References
IPv6", Oct 1999.
[RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
Multicast (SSM)", July 2003. RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC3819] P. Harn et al., "Advice for Internet Subnetwork [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Designers", July 2004. Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>.
[RFC4762] Lasserre, M., and Kompella, V. (Eds.), "Virtual Private [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
LAN Service (VPLS) using Label Distribution Protocol (LDP) Multicast (SSM)", RFC 3569, DOI 10.17487/RFC3569, July
signaling," January 2007. 2003, <https://www.rfc-editor.org/info/rfc3569>.
[RFC6040] B. Briscoe, "Tunnelling of Explicit Congestion [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Notification", Nov 2010. 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>.
[RFC6831] Farinacci, D. et al., "The Locator/ID Seperation Protocol [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
(LISP) for Multicast Environments", Jan, 2013. LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC7117] Aggarwal, R. et al., "Multicast in VPLS," February 2014. [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[RFC7348] Mahalingam, M. et al., " Virtual eXtensible Local Area [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Network (VXLAN): A Framework for Overlaying Virtualized Locator/ID Separation Protocol (LISP) for Multicast
Layer 2 Networks over Layer 3 Networks", August 2014. Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC7365] M. Lasserre, et al. "Framework for Data Center (DC) [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
Network Virtualization", Oct 2014. C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014,
<https://www.rfc-editor.org/info/rfc7117>.
[RFC7637] Garg P. and Wang, Y. (Eds.), "NVGRE: Network [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
Vvirtualization using Generic Routing Encapsulation", L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
September 2015. 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>.
[BIER-ARCH] Wijnands, IJ. (Ed.) et al., "Multicast using Bit Index [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Explicit Replication," <draft-ietf-bier-architecture-03>, Virtualization Using Generic Routing Encapsulation",
January 2016. RFC 7637, DOI 10.17487/RFC7637, September 2015,
<https://www.rfc-editor.org/info/rfc7637>.
Internet-Draft A framework for multicast in NVO3 [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>.
[DC-MC] McBride, M. and Lui, H., "Multicast in the data center [DC-MC] McBride, M. and H. Liu, "Multicast in the Data Center
overview," <draft-mcbride-armd-mcast-overview-02>, work in Overview", Work in Progress, draft-mcbride-armd-mcast-
progress, July 2012. overview-02, July 2012.
[EDGE-REP] Marques P. et al., "Edge multicast replication for BGP IP [EDGE-REP] Marques, P., Fang, L., Winkworth, D., Cai, Y., and
VPNs," <draft-marques-l3vpn-mcast-edge-01>, work in P. Lapukhov, "Edge multicast replication for BGP IP
progress, June 2012. VPNs.", Work in Progress, draft-marques-l3vpn-
mcast-edge-01, June 2012.
[Geneve] Gross, J. and Ganga, I. (Eds.), "Geneve: Generic Network [Geneve] Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Virtualization Encapsulation", <draft-ietf-nvo3-geneve- Network Virtualization Encapsulation", Work in Progress,
01>, work in progress, January 2016. draft-ietf-nvo3-geneve-05, September 2017.
[GUE] Herbert, T. et al., "Generic UDP Encapsulation", <draft- [GUE] Herbert, T., Yong, L., and O. Zia, "Generic UDP
ietf-nvo3-gue-02>, work in progress, December 2015. Encapsulation", Work in Progress,
draft-ietf-intarea-gue-05, December 2017.
[ISIS-Multicast] Yong, L. et al., "ISIS Protocol Extension for [ISIS-Multicast]
Building Distribution Trees", <draft-yong-isis-ext-4- Yong, L., Weiguo, H., Eastlake, D., Qu, A., Hudson, J.,
distribution-tree-03>, work in progress, October 2014. and U. Chunduri, "IS-IS Protocol Extension For Building
Distribution Trees", Work in Progress,
draft-yong-isis-ext-4-distribution-tree-03, October 2014.
[LANE] "LAN emulation over ATM," The ATM Forum, af-lane-0021.000, [LANE] ATM Forum, "LAN Emulation Over ATM: Version 1.0", ATM
January 1995. Forum Technical Committee, af-lane-0021.000, January 1995.
[LISP-Signal-Free] Moreno, V. and Farinacci, D., "Signal-Free LISP [LISP-Signal-Free]
Multicast", <draft-ietf-lisp-signal-free-multicast-01>, Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
work in progress, April 2016. Work in Progress, draft-ietf-lisp-signal-free-
multicast-07, November 2017.
[VXLAN-GPE] Kreeger, L. and Elzur, U. (Eds.), "Generic Protocol [VXLAN-GPE]
Extension for VXLAN", <draft-ietf-nvo3-vxlan-gpe-02>, work Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
in progress, April 2016. Extension for VXLAN", Work in Progress,
draft-ietf-nvo3-vxlan-gpe-05, October 2017.
10. Acknowledgments Acknowledgments
Many thanks are due to Dino Farinacci, Erik Nordmark, Lucy Yong, Many thanks are due to Dino Farinacci, Erik Nordmark, Lucy Yong,
Nicolas Bouliane, Saumya Dikshit, Joe Touch, Olufemi Komolafe, and Nicolas Bouliane, Saumya Dikshit, Joe Touch, Olufemi Komolafe, and
Matthew Bocci, for their valuable comments and suggestions. Matthew Bocci for their valuable comments and suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Internet-Draft A framework for multicast in NVO3
Authors' Addresses Authors' Addresses
Anoop Ghanwani Anoop Ghanwani
Dell Dell
Email: anoop@alumni.duke.edu Email: anoop@alumni.duke.edu
Linda Dunbar Linda Dunbar
Huawei Technologies Huawei Technologies
5340 Legacy Drive, Suite 1750 5340 Legacy Drive, Suite 1750
Plano, TX 75024, USA Plano, TX 75024
United States of America
Phone: (469) 277 5840 Phone: (469) 277 5840
Email: ldunbar@huawei.com Email: ldunbar@huawei.com
Mike McBride Mike McBride
Huawei Technologies Huawei Technologies
Email: mmcbride7@gmail.com Email: mmcbride7@gmail.com
Vinay Bannai Vinay Bannai
Google Google
Email: vbannai@gmail.com Email: vbannai@gmail.com
Ram Krishnan Ram Krishnan
Dell Dell
Email: ramkri123@gmail.com Email: ramkri123@gmail.com
 End of changes. 143 change blocks. 
494 lines changed or deleted 488 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/