doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc8293.txt b/doc/rfc/rfc8293.txt
new file mode 100644
index 0000000..4db45d2
--- /dev/null
+++ b/doc/rfc/rfc8293.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       A. Ghanwani
+Request for Comments: 8293                                          Dell
+Category: Informational                                        L. Dunbar
+ISSN: 2070-1721                                               M. McBride
+                                                                  Huawei
+                                                               V. Bannai
+                                                                  Google
+                                                             R. Krishnan
+                                                                    Dell
+                                                            January 2018
+
+
+    A Framework for Multicast in Network Virtualization over Layer 3
+
+Abstract
+
+   This document provides a framework for supporting multicast traffic
+   in a network that uses Network Virtualization over Layer 3 (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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 1]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are 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
+
+
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 2]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+1.  Introduction
+
+   Network Virtualization over Layer 3 (NVO3) [RFC7365] is a technology
+   that is used to address issues that arise in building large, multi-
+   tenant data centers (DCs) that make extensive use of server
+   virtualization [RFC7364].
+
+   This document provides a framework for supporting multicast traffic
+   in a network that uses NVO3.  Both infrastructure multicast and
+   application-specific multicast are considered.  It describes various
+   mechanisms, and the considerations of each of them, that can be used
+   for delivering such traffic in networks that use NVO3.
+
+   The reader is assumed to be familiar with the terminology and
+   concepts as defined in the NVO3 Framework [RFC7365] and NVO3
+   Architecture [RFC8014] documents.
+
+1.1.  Infrastructure Multicast
+
+   Infrastructure multicast refers to networking services that require
+   multicast or broadcast delivery, such as Address Resolution Protocol
+   (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol
+   (DHCP), multicast Domain Name Server (mDNS), etc., some of which are
+   described in Sections 5 and 6 of RFC 3819 [RFC3819].  It is possible
+   to provide solutions for these services that do not involve multicast
+   in the underlay network.  For example, in the case of ARP/ND, a
+   Network Virtualization Authority (NVA) can be used for distributing
+   the IP address to Media Access Control (MAC) address mappings to all
+   of the Network Virtualization Edges (NVEs).  An NVE can then trap ARP
+   Request and/or ND Neighbor Solicitation messages from the Tenant
+   Systems (TSs) that are attached to it and respond to them, thereby
+   eliminating the need for the broadcast/multicast of such messages.
+   In the case of DHCP, the NVE can be configured to forward these
+   messages using the DHCP relay function [RFC2131].
+
+   Of course, it is possible to support all of these infrastructure
+   multicast protocols natively if the underlay provides multicast
+   transport.  However, even in the presence of multicast transport, it
+   may be beneficial to use the optimizations mentioned above to reduce
+   the amount of such traffic in the network.
+
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 3]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+1.2.  Application-Specific Multicast
+
+   Application-specific multicast traffic refers to multicast traffic
+   that originates and is consumed by user applications.  Several such
+   applications are described elsewhere [DC-MC].  Application-specific
+   multicast may be either Source-Specific Multicast (SSM) or Any-Source
+   Multicast (ASM) [RFC3569] and has the following characteristics:
+
+   1.  Receiver hosts are expected to subscribe to multicast content
+       using protocols such as IGMP [RFC3376] (IPv4) or Multicast
+       Listener Discovery (MLD) [RFC2710] (IPv6).  Multicast sources and
+       listeners participate in these protocols using addresses that are
+       in the TS address domain.
+
+   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.  Terminology and Abbreviations
+
+   In this document, the terms host, Tenant System (TS), and Virtual
+   Machine (VM) are used interchangeably to represent an end station
+   that originates or consumes data packets.
+
+   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
+
+
+
+Ghanwani, et al.              Informational                     [Page 4]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   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 is transported using an
+   encapsulation such as VXLAN [RFC7348] [VXLAN-GPE], Network
+   Virtualization using Generic Routing Encapsulation (NVGRE) [RFC7637],
+   Geneve [Geneve], Generic UDP Encapsulation [GUE], etc.
+
+   What makes networks using NVO3 different from other networks is that
+   some NVEs, especially NVEs implemented in servers, might not support
+   regular multicast protocols such as PIM.  Instead, the only
+   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
+   multicast as a network capability for NVEs, to map multicast traffic
+   from VMs (users/applications) to an equivalent multicast capability
+   inside the NVE, or to figure out the outer destination address if NVE
+   does not support native multicast (e.g., PIM) or IGMP.
+
+   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
+
+   2.  Replication at the source NVE
+
+   3.  Replication at a multicast service node
+
+   4.  IP multicast in the underlay
+
+   These methods are briefly mentioned in the NVO3 Framework [RFC7365]
+   and NVO3 Architecture [RFC8014] documents.  This document provides
+   more details about the basic mechanisms underlying each of these
+   methods and discusses the issues and trade-offs of each.
+
+   We note that other methods are also possible, such as [EDGE-REP], but
+   we focus on the above four because they are the most common.
+
+   It is worth noting that when selecting a multicast mechanism, it is
+   useful to consider the impact of these on any multicast congestion
+   control mechanisms that applications may be using to obtain the
+   desired system dynamics.  In addition, the same rules for Explicit
+
+
+
+Ghanwani, et al.              Informational                     [Page 5]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   Congestion Notification (ECN) would apply to multicast traffic being
+   encapsulated, as for unicast traffic [RFC6040].
+
+3.1.  No Multicast Support
+
+   In this scenario, there is no support whatsoever for multicast
+   traffic when using the overlay.  This method can only work if the
+   following conditions are met:
+
+   1.  All of the application traffic in the network is unicast traffic,
+       and the only multicast/broadcast traffic is from ARP/ND
+       protocols.
+
+   2.  An NVA is used by all of the NVEs to determine the mapping of a
+       given TS's MAC and IP address to the NVE that it is attached to.
+       In other words, there is no data-plane learning.  Address
+       resolution requests via ARP/ND that are issued by the TSs must be
+       resolved by the NVE that they are attached to.
+
+   With this approach, it is not possible to support application-
+   specific multicast.  However, certain multicast/broadcast
+   applications can be supported without multicast; for example, DHCP,
+   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 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
+
+   With this method, the overlay attempts to provide a multicast service
+   without requiring any specific support from the underlay, other than
+   that of a unicast service.  A multicast or broadcast transmission is
+   achieved by replicating the packet at the source NVE and making
+   copies, one for each destination NVE that the multicast packet must
+   be sent to.
+
+   For this mechanism to work, the source NVE must know, a priori, the
+   IP addresses of all destination NVEs that need to receive the packet.
+   For the purpose of ARP/ND, this would involve knowing the IP
+   addresses of all the NVEs that have TSs in the VN of the TS that
+   generated the request.
+
+
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 6]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   For the support of 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 that using receiver-sites registration
+   does not necessarily mean the source NVE must do replication.  If the
+   NVA indicates that multicast packets are encapsulated to multicast
+   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
+   to all TSs that are part of the VN.
+
+   In multihoming environments, i.e., in those where a TS is attached to
+   more than one NVE, the NVA would be expected to provide information
+   to all of the NVEs under its control about all of the NVEs to which
+   such a TS is attached.  The ingress NVE can then choose any one of
+   those NVEs as the egress NVE for the data frames destined towards the
+   multi-homed TS.
+
+   This method requires multiple copies of the same packet to all NVEs
+   that participate in the VN.  If, for example, 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 to the network that can cause congestion when the network
+   load is high.  This also creates an issue with the forwarding
+   performance of the NVE.
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 7]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   Note that this method is similar to what was used in Virtual Private
+   LAN Service (VPLS) [RFC4762] prior to support of Multiprotocol Label
+   Switching (MPLS) multicast [RFC7117].  While there are some
+   similarities between MPLS Virtual Private Network (VPN) and NVO3,
+   there are some key differences:
+
+   o  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.
+
+   o  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"
+   [RFC6513] combines all those multicast groups within each VPN client
+   to 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 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 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 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 a DC
+   environment with the 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 would be sent using a unicast
+   tunnel encapsulation from the ingress NVE to a Multicast Service Node
+   (MSN).  The MSN, in turn, would create multiple copies of the packet
+   and would deliver a copy, using a unicast tunnel encapsulation, to
+   each of the NVEs that are part of the multicast group for which the
+   packet is intended.
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 8]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   This mechanism is similar to that used by the Asynchronous Transfer
+   Mode (ATM) Forum's LAN Emulation (LANE) specification [LANE].  The
+   MSN is similar to the Rendezvous Point (RP) in Protocol Independent
+   Multicast - Sparse Mode (PIM-SM), but different in that the user data
+   traffic is carried by the NVO3 tunnels.
+
+   The following are possible ways for the MSN to get the membership
+   information for each multicast group:
+
+   o  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 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.
+
+   o  The MSN can obtain 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 obtain
+      the information from the NVEs and in turn have MSN communicate
+      with the NVA.  This approach requires additional protocol between
+      MSN and NVEs.
+
+   Unlike the method described in Section 3.2, there is no performance
+   impact at the ingress NVE, nor are there any issues with multiple
+   copies of the same packet from the source NVE to the MSN.  However,
+   there remain 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 are introduced with this method include the
+   availability of the MSN, methods to scale the services offered by the
+   MSN, and the suboptimality of the delivery paths.
+
+
+
+
+Ghanwani, et al.              Informational                     [Page 9]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   Finally, 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 create problems if IP source address Reverse
+   Path Forwarding (RPF) checks are in use.
+
+3.4.  IP Multicast in the Underlay
+
+   In this method, the underlay supports IP multicast and the ingress
+   NVE encapsulates the packet with the appropriate IP multicast address
+   in the tunnel encapsulation header for delivery to the desired set of
+   NVEs.  The protocol in the underlay could be any variant of PIM, or a
+   protocol-dependent multicast, such as [ISIS-Multicast].
+
+   If an NVE connects to its attached TSs via a Layer 2 network, there
+   are multiple ways for NVEs to support the application-specific
+   multicast:
+
+   o  The NVE only supports the basic IGMP/MLD snooping function, while
+      the "TS routers" handle the application-specific multicast.  This
+      scheme doesn't utilize the underlay IP multicast protocols.
+      Instead routers, which are themselves TSs attached to the NVE,
+      would handle multicast protocols for the application-specific
+      multicast.  We refer to such routers as TS routers.
+
+   o  The NVE can act as a pseudo multicast router for the directly
+      attached TSs and support the mapping of IGMP/MLD messages to the
+      messages needed by the underlay IP multicast protocols.
+
+   With this method, there are none of the issues with the methods
+   described in Sections 3.2 and 3.3 with respect to scaling and
+   congestion.  Instead, there are other issues described below.
+
+   With PIM-SM, the number of flows required would be (n*g), where n is
+   the number of source NVEs that source packets for the group, and g is
+   the number of groups.  Bidirectional PIM (BIDIR-PIM) would offer
+   better scalability with the number of flows required being g.
+   Unfortunately, many vendors still do not fully support BIDIR or have
+   limitations on its implementation.  [RFC6831] describes the use of
+   SSM as an alternative to BIDIR, provided that the NVEs have a way to
+   learn of each other's IP addresses so that they can join all of the
+   SSM Shortest Path Trees (SPTs) to create/maintain an underlay SSM IP
+   multicast tunnel solution.
+
+   In the absence of any additional mechanism (e.g., using an NVA for
+   address resolution), for optimal delivery, there would have to be a
+   separate group for each VN for infrastructure multicast plus a
+   separate group for each application-specific multicast address within
+   a tenant.
+
+
+
+Ghanwani, et al.              Informational                    [Page 10]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   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
+   the outer MAC address, and if there is equipment that prunes
+   multicasts at Layer 2, there will be some aliasing.
+
+   Finally, a mechanism to efficiently provision such addresses for each
+   group would be required.
+
+   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
+   burden to optimize which tenants should be part of the same tenant
+   group (based on the NVEs they share), which somewhat dilutes the
+   value proposition of NVO3 (to completely decouple the overlay and
+   physical network design allowing complete freedom of placement of VMs
+   anywhere within the DC).
+
+   Multicast schemes such as Bit Indexed Explicit Replication (BIER)
+   [RFC8279] may be able to provide optimizations by allowing the
+   underlay network to provide optimum multicast delivery without
+   requiring routers in the core of the network to maintain per-
+   multicast group state.
+
+3.5.  Other Schemes
+
+   There are still other mechanisms that may be used that attempt to
+   combine some of the advantages of the above methods by offering
+   multiple replication points, each with a limited degree of
+   replication [EDGE-REP].  Such schemes offer a trade-off between the
+   amount of replication at an intermediate node (e.g., router) versus
+   performing all of the replication at the source NVE or all of the
+   replication at a multicast service node.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 11]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+4.  Simultaneous Use of More Than One Mechanism
+
+   While the mechanisms discussed in the previous section have been
+   discussed individually, it is possible for implementations to rely on
+   more than one of these.  For example, the method of Section 3.1 could
+   be used for minimizing 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, the methods of source NVE
+   replication or the use of a multicast service node may be attractive,
+   while for larger multicast groups, the use of multicast in the
+   underlay may be preferable.
+
+5.  Other Issues
+
+5.1.  Multicast-Agnostic NVEs
+
+   Some hypervisor-based NVEs do not process or recognize IGMP/MLD
+   frames, i.e., those NVEs simply encapsulate the IGMP/MLD messages in
+   the same way as they do for regular data frames.
+
+   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
+   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
+   also send the IGMP/MLD query message comprising a client-specific
+   multicast address encapsulated in an overlay header to all of the
+   NVEs to which the TSs in the VN are attached.
+
+   However, the MSN may not always be aware of the client-specific
+   multicast addresses.  In order to perform multicast filtering, the
+   MSN has to snoop the IGMP/MLD messages between TSs and their
+   corresponding routers to maintain the multicast membership.  In order
+   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
+   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
+   NVEs to encapsulate data frames with the Destination Address (DA)
+   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 3.2, except the NVEs only replicate the message to the TSs'
+   router and MSN.
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 12]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+5.2.  Multicast Membership Management for DC with VMs
+
+   For DCs with virtualized servers, VMs can be added, deleted, or moved
+   very easily.  When VMs are added, deleted, or moved, the NVEs to
+   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
+   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 that
+   the multicast membership can be updated promptly.
+
+   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.
+
+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>.
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 13]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
+              Notification", RFC 6040, DOI 10.17487/RFC6040, November
+              2010, <https://www.rfc-editor.org/info/rfc6040>.
+
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 14]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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 H. Liu, "Multicast in the Data Center
+              Overview", Work in Progress, draft-mcbride-armd-mcast-
+              overview-02, July 2012.
+
+   [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.
+
+   [Geneve]   Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
+              Network Virtualization Encapsulation", Work in Progress,
+              draft-ietf-nvo3-geneve-05, September 2017.
+
+   [GUE]      Herbert, T., Yong, L., and O. Zia, "Generic UDP
+              Encapsulation", Work in Progress,
+              draft-ietf-intarea-gue-05, December 2017.
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 15]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+   [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.
+
+   [LANE]     ATM Forum, "LAN Emulation Over ATM: Version 1.0", ATM
+              Forum Technical Committee, af-lane-0021.000, January 1995.
+
+   [LISP-Signal-Free]
+              Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
+              Work in Progress, draft-ietf-lisp-signal-free-
+              multicast-07, November 2017.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 16]
+
+RFC 8293            A Framework for Multicast in NVO3       January 2018
+
+
+Acknowledgments
+
+   Many thanks are due to Dino Farinacci, Erik Nordmark, Lucy Yong,
+   Nicolas Bouliane, Saumya Dikshit, Joe Touch, Olufemi Komolafe, and
+   Matthew Bocci for their valuable comments and suggestions.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Ghanwani, et al.              Informational                    [Page 17]
+