draft-ietf-nvo3-mcast-framework-10.txt   draft-ietf-nvo3-mcast-framework-11.txt 
NVO3 working group A. Ghanwani NVO3 working group A. Ghanwani
Internet Draft Dell Internet Draft Dell
Intended status: Informational L. Dunbar Intended status: Informational L. Dunbar
Expires: November 8, 2018 M. McBride Expires: November 8, 2018 M. McBride
Huawei Huawei
V. Bannai V. Bannai
Google Google
R. Krishnan R. Krishnan
Dell Dell
October 5, 2017 October 23, 2017
A Framework for Multicast in Network Virtualization Overlays A Framework for Multicast in Network Virtualization Overlays
draft-ietf-nvo3-mcast-framework-10 draft-ietf-nvo3-mcast-framework-11
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, 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 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. as an RFC and to translate it into languages other than English.
skipping to change at page 2, line 40 skipping to change at page 2, line 40
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 1.3. Terminology clarification.................................4
2. Acronyms.......................................................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...................9 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............................................12 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..................................13 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. Summary.......................................................14 6. Summary.......................................................14
7. Security Considerations.......................................14 7. Security Considerations.......................................14
8. IANA Considerations...........................................14 8. IANA Considerations...........................................14
Internet-Draft A framework for multicast in NVO3 Internet-Draft A framework for multicast in NVO3
9. References....................................................14 9. References....................................................14
9.1. Normative References.....................................14 9.1. Normative References.....................................14
skipping to change at page 6, line 15 skipping to change at page 6, line 15
Internet-Draft A framework for multicast in NVO3 Internet-Draft A framework for multicast in NVO3
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] document. 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 we focus on the above four because they are the most common. but we focus on the above four because they are the most common.
It worth noting that when selecting a multicast replication
strategy, it is useful to consider the interaction with any
multicast congestion control that applications may be using to
obtain the desired system dynamics. In addition, for multicast we
follow the same rules for ECN as any non-multicast traffic would and
be in conformance with the appropriate encap draft [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 and the only multicast/broadcast traffic is from ARP/ND traffic and the only multicast/broadcast traffic is from ARP/ND
protocols. protocols.
skipping to change at page 6, line 43 skipping to change at page 7, line 5
applications such as DHCP can be supported by use of a helper applications such as DHCP can be supported by use of a helper
function in the NVE. function in the NVE.
The main drawback of this approach, even for unicast traffic, is The main drawback of this approach, even for unicast traffic, is
that it is not possible to initiate communication with a TS for 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 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 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 switch and the TS is a physical end station that has not registered
with the NVA. with the NVA.
Internet-Draft A framework for multicast in NVO3
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 without requiring any specific support from the underlay, service without requiring any specific support from the underlay,
other than that of a unicast service. A multicast or broadcast other than that of a unicast service. A multicast or broadcast
transmission is achieved by replicating the packet at the source transmission is achieved by replicating the packet at the source
Internet-Draft A framework for multicast in NVO3
NVE, and making copies, one for each destination NVE that the NVE, and making copies, one for each destination NVE that the
multicast packet must be sent to. multicast packet must 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. For the purpose of ARP/ND, this would involve knowing the packet. For the purpose of ARP/ND, this would involve knowing the
IP addresses of all the NVEs that have TSs in the virtual network IP addresses of all the NVEs that have TSs in the virtual network
(VN) of the TS that generated the request. For the support of (VN) of the TS that generated the request. For the support of
application-specific multicast traffic, a method similar to that of application-specific multicast traffic, a method similar to that of
receiver-sites registration for a particular multicast group receiver-sites registration for a particular multicast group
skipping to change at page 7, line 48 skipping to change at page 8, line 5
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 multi-homing environments, i.e., in those where a TS is attached
to more than one NVE, the NVA would be expected to provide 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 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 choose any NVEs to which such a TS is attached. The ingress NVE can choose any
one of the egress NVEs for the data frames destined towards the TS. one of the egress NVEs for the data frames destined towards the 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
Internet-Draft A framework for multicast in NVO3
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 Multi-Protocol
Label Switching (MPLS) multicast [RFC7117]. While there are some Label 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 - The Customer Edge (CE) to Provider Edge (PE) attachment in VPNs is
skipping to change at page 8, line 46 skipping to change at page 9, line 5
switch may only support 10's VMs (as of this writing). A subnet switch may only support 10's VMs (as of this writing). A subnet
with N VMs may be, in the worst case, spread across N vSwitches. with N VMs may be, in the worst case, spread across N vSwitches.
Using "MPLS VPN multicast" approach in such a scenario would Using "MPLS VPN multicast" approach in such a scenario would
require the creation of a Multicast group in the core for this VN require the creation of a Multicast group in the core for this VN
to reach all N NVEs. If only small percentage of this client's VMs to reach all N NVEs. If only small percentage of this client's VMs
participate in application specific multicast, a great number of participate in application specific multicast, a great number of
NVEs will receive multicast traffic that is not forwarded to any NVEs will receive multicast traffic that is not forwarded to any
of their attached VMs, resulting in considerable wastage of of their attached VMs, resulting in considerable wastage of
bandwidth. bandwidth.
Internet-Draft A framework for multicast in NVO3
Therefore, the Multicast VPN solution may not scale in DC Therefore, the Multicast VPN solution may not scale in DC
environment with dynamic attachment of Virtual Networks to NVEs and environment with dynamic attachment of Virtual Networks to NVEs and
greater number of NVEs for each virtual network. greater number of NVEs for each virtual network.
Internet-Draft A framework for multicast in NVO3
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 tunnel encapsulation from the ingress NVE to a multicast unicast tunnel encapsulation from the ingress NVE to a multicast
service node (MSN). The MSN, in turn, would create multiple copies service node (MSN). The MSN, in turn, would create multiple copies
of the packet and would deliver a copy, using a unicast tunnel of the packet and would deliver a copy, using a unicast tunnel
encapsulation, to each of the NVEs that are part of the multicast encapsulation, to each of the NVEs that are part of the multicast
group for which the packet is intended. group for which the 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
skipping to change at page 9, line 41 skipping to change at page 10, line 4
field. The encapsulated IGMP/MLD query messages also has a VNID field. The encapsulated IGMP/MLD query messages also has a VNID
for a virtual network (VN) that TSs belong in the outer header and for a virtual network (VN) that TSs belong in the outer header and
a multicast address in the inner destination address field. Upon a multicast address in the inner destination address field. Upon
receiving the encapsulated IGMP/MLD query message, the NVE receiving the encapsulated IGMP/MLD query message, the NVE
establishes a mapping "MSN address" <-> "multicast address", establishes a mapping "MSN address" <-> "multicast address",
decapsulates the received encapsulated IGMP/MLD message, and decapsulates the received encapsulated IGMP/MLD message, and
multicast the decapsulated query message to TSs that belong to the 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 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 the multicast address and the address of the TS. With the proper
"MSN Address" <-> "Multicast-Address" mapping, the NVEs can "MSN Address" <-> "Multicast-Address" mapping, the NVEs can
Internet-Draft A framework for multicast in NVO3
encapsulate all multicast data frames to the "Multicast-Address" encapsulate all multicast data frames to the "Multicast-Address"
with the address of the MSN in the outer destination address with the address of the MSN in the outer destination address
field. field.
Internet-Draft A framework for multicast in NVO3
- The MSN can obtain the membership information from the NVEs that - 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 (p.s. the communication must be specific
to the multicast addresses), or by having the NVA obtain the to the multicast addresses), or by having the NVA obtain the
information from the NVEs, and in turn have MSN communicate with information from the NVEs, and in turn have MSN communicate with
the NVA. This approach requires additional protocol between MSN the NVA. This approach requires additional protocol between MSN
and NVEs. 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
skipping to change at page 10, line 43 skipping to change at page 11, line 5
NVE encapsulates the packet with the appropriate IP multicast NVE encapsulates the packet with the appropriate IP multicast
address in the tunnel encapsulation header for delivery to the address in the tunnel encapsulation header for delivery to the
desired set of NVEs. The protocol in the underlay could be any desired set of NVEs. The protocol in the underlay could be any
variant of Protocol Independent Multicast (PIM), or protocol variant of Protocol Independent Multicast (PIM), or 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
- The NVE only supports the basic IGMP/MLD snooping function, let - The NVE only supports the basic IGMP/MLD snooping function, let
the TSs routers handling the application specific multicast. This the TSs routers handling the application specific multicast. This
scheme doesn't utilize the underlay IP multicast protocols. scheme doesn't utilize the underlay IP multicast protocols.
Internet-Draft A framework for multicast in NVO3
- The NVE can act as a pseudo multicast router for the directly - 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 VMs and support proper mapping of IGMP/MLD's messages to
the messages needed by the underlay IP multicast protocols. the 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.
With PIM Sparse Mode (PIM-SM), the number of flows required would be With PIM Sparse Mode (PIM-SM), the number of flows required would be
(n*g), where n is the number of source NVEs that source packets for (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- the group, and g is the number of groups. Bidirectional PIM (BIDIR-
skipping to change at page 11, line 43 skipping to change at page 12, line 4
multicasts at Layer 2, there will be some aliasing. Finally, a multicasts at Layer 2, there will be some aliasing. Finally, a
mechanism to efficiently provision such addresses for each group mechanism to efficiently provision such addresses for each group
would be required. would be required.
There are additional optimizations which are possible, but they come There are additional optimizations which are possible, but they come
with their own restrictions. For example, a set of tenants may be 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 restricted to some subset of NVEs and they could all share the same
outer IP multicast group address. This however introduces a problem outer IP multicast group address. This however introduces a problem
of sub-optimal delivery (even if a particular tenant within the 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 group of tenants doesn't have a presence on one of the NVEs which
Internet-Draft A framework for multicast in NVO3
another one does, the multicast packets would still be delivered to 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
Internet-Draft A framework for multicast in NVO3
value proposition of NVO3 which is to completely decouple the value proposition of NVO3 which is to completely decouple the
overlay and physical network design allowing complete freedom of overlay and physical network design allowing complete freedom of
placement of VMs anywhere within the data center. placement of VMs anywhere within the data center.
Multicast schemes such as BIER (Bit Indexed Explicit Replication) Multicast schemes such as BIER (Bit Indexed Explicit Replication)
[BIER-ARCH] may be able to provide optimizations by allowing the [BIER-ARCH] 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.
skipping to change at page 12, line 39 skipping to change at page 13, line 5
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 more than one of these. For example, the method of Section 3.1 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, could be used for minimizing ARP/ND, while at the same time,
multicast applications may be supported by one, or a combination of, multicast applications may be supported by one, or a combination of,
the other methods. For small multicast groups, the methods of the other methods. For small multicast groups, the methods of
source NVE replication or the use of a multicast service node may be source NVE replication or the use of a multicast service node may be
attractive, while for larger multicast groups, the use of multicast attractive, while for larger multicast groups, the use of multicast
in the underlay may be preferable. in the underlay may be preferable.
5. Other issues
Internet-Draft A framework for multicast in NVO3 Internet-Draft A framework for multicast in NVO3
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, TSs 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
skipping to change at page 13, line 45 skipping to change at page 14, line 4
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 data centers with virtualized servers, VMs can be added, deleted
or moved very easily. When VMs are added, deleted or moved, the NVEs or moved very easily. When VMs are added, deleted or moved, the NVEs
to which the VMs are attached are changed. 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 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 messages to the relevant NVEs (as described in Section 3.3), query messages to the relevant NVEs (as described in Section 3.3),
so that the multicast membership can be updated promptly. so that 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 Otherwise, if there are changes of VMs attachment to NVEs, within
the duration of the configured default time interval that the TSs the duration of the configured default time interval that the TSs
routers use for IGMP/MLD queries, multicast data may not reach the routers use for IGMP/MLD queries, multicast data may not reach the
VM(s) that moved. VM(s) that moved.
Internet-Draft A framework for multicast in NVO3
6. Summary 6. 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 co-existence 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.
skipping to change at page 14, line 43 skipping to change at page 15, line 5
[RFC6513] Rosen, E. et al., "Multicast in MPLS/BGP IP VPNs", [RFC6513] Rosen, E. et al., "Multicast in MPLS/BGP IP VPNs",
February 2012. February 2012.
[RFC7364] Narten, T. et al., "Problem statement: Overlays for [RFC7364] Narten, T. et al., "Problem statement: Overlays for
network virtualization", October 2014. network virtualization", October 2014.
[RFC7365] Lasserre, M. et al., "Framework for data center (DC) [RFC7365] Lasserre, M. et al., "Framework for data center (DC)
network virtualization", October 2014. network virtualization", October 2014.
Internet-Draft A framework for multicast in NVO3
[RFC8014] Narten, T. et al.," An Architecture for Overlay Networks [RFC8014] Narten, T. et al.," An Architecture for Overlay Networks
(NVO3)", RFC8014, Dec. 2016. (NVO3)", RFC8014, Dec. 2016.
Internet-Draft A framework for multicast in NVO3
9.2. Informative References 9.2. Informative References
[RFC2710] S. Deering et al, "Multicast Listener Discovery (MLD) for [RFC2710] S. Deering et al, "Multicast Listener Discovery (MLD) for
IPv6", Oct 1999. IPv6", Oct 1999.
[RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific [RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
Multicast (SSM)", July 2003. Multicast (SSM)", July 2003.
[RFC3819] P. Harn et al., "Advice for Internet Subnetwork [RFC3819] P. Harn et al., "Advice for Internet Subnetwork
Designers", July 2004. Designers", July 2004.
[RFC4762] Lasserre, M., and Kompella, V. (Eds.), "Virtual Private [RFC4762] Lasserre, M., and Kompella, V. (Eds.), "Virtual Private
LAN Service (VPLS) using Label Distribution Protocol (LDP) LAN Service (VPLS) using Label Distribution Protocol (LDP)
signaling," January 2007. signaling," January 2007.
[RFC6040] B. Briscoe, "Tunnelling of Explicit Congestion
Notification", Nov 2010.
[RFC6831] Farinacci, D. et al., "The Locator/ID Seperation Protocol [RFC6831] Farinacci, D. et al., "The Locator/ID Seperation Protocol
(LISP) for Multicast Environments", Jan, 2013. (LISP) for Multicast Environments", Jan, 2013.
[RFC7117] Aggarwal, R. et al., "Multicast in VPLS," February 2014. [RFC7117] Aggarwal, R. et al., "Multicast in VPLS," February 2014.
[RFC7348] Mahalingam, M. et al., " Virtual eXtensible Local Area [RFC7348] Mahalingam, M. et al., " Virtual eXtensible Local Area
Network (VXLAN): A Framework for Overlaying Virtualized Network (VXLAN): A Framework for Overlaying Virtualized
Layer 2 Networks over Layer 3 Networks", August 2014. Layer 2 Networks over Layer 3 Networks", August 2014.
[RFC7365] M. Lasserre, et al. "Framework for Data Center (DC) [RFC7365] M. Lasserre, et al. "Framework for Data Center (DC)
Network Virtualization", Oct 2014. Network Virtualization", Oct 2014.
[RFC7637] Garg P. and Wang, Y. (Eds.), "NVGRE: Network [RFC7637] Garg P. and Wang, Y. (Eds.), "NVGRE: Network
Vvirtualization using Generic Routing Encapsulation", Vvirtualization using Generic Routing Encapsulation",
September 2015. September 2015.
[BIER-ARCH] [BIER-ARCH] Wijnands, IJ. (Ed.) et al., "Multicast using Bit Index
Wijnands, IJ. (Ed.) et al., "Multicast using Bit Index
Explicit Replication," <draft-ietf-bier-architecture-03>, Explicit Replication," <draft-ietf-bier-architecture-03>,
January 2016. January 2016.
Internet-Draft A framework for multicast in NVO3
[DC-MC] McBride, M. and Lui, H., "Multicast in the data center [DC-MC] McBride, M. and Lui, H., "Multicast in the data center
overview," <draft-mcbride-armd-mcast-overview-02>, work in overview," <draft-mcbride-armd-mcast-overview-02>, work in
progress, July 2012. progress, July 2012.
[EDGE-REP] [EDGE-REP] Marques P. et al., "Edge multicast replication for BGP IP
Internet-Draft A framework for multicast in NVO3
Marques P. et al., "Edge multicast replication for BGP IP
VPNs," <draft-marques-l3vpn-mcast-edge-01>, work in VPNs," <draft-marques-l3vpn-mcast-edge-01>, work in
progress, June 2012. progress, June 2012.
[Geneve] [Geneve] Gross, J. and Ganga, I. (Eds.), "Geneve: Generic Network
Gross, J. and Ganga, I. (Eds.), "Geneve: Generic Network
Virtualization Encapsulation", <draft-ietf-nvo3-geneve- Virtualization Encapsulation", <draft-ietf-nvo3-geneve-
01>, work in progress, January 2016. 01>, work in progress, January 2016.
[GUE] [GUE] Herbert, T. et al., "Generic UDP Encapsulation", <draft-
Herbert, T. et al., "Generic UDP Encapsulation", <draft-
ietf-nvo3-gue-02>, work in progress, December 2015. ietf-nvo3-gue-02>, work in progress, December 2015.
[ISIS-Multicast] [ISIS-Multicast] Yong, L. et al., "ISIS Protocol Extension for
Yong, L. et al., "ISIS Protocol Extension for Building Building Distribution Trees", <draft-yong-isis-ext-4-
Distribution Trees", <draft-yong-isis-ext-4-distribution- distribution-tree-03>, work in progress, October 2014.
tree-03>, work in progress, October 2014.
[LANE] "LAN emulation over ATM," The ATM Forum, af-lane-0021.000, [LANE] "LAN emulation over ATM," The ATM Forum, af-lane-0021.000,
January 1995. January 1995.
[LISP-Signal-Free] [LISP-Signal-Free] Moreno, V. and Farinacci, D., "Signal-Free LISP
Moreno, V. and Farinacci, D., "Signal-Free LISP
Multicast", <draft-ietf-lisp-signal-free-multicast-01>, Multicast", <draft-ietf-lisp-signal-free-multicast-01>,
work in progress, April 2016. work in progress, April 2016.
[VXLAN-GPE] [VXLAN-GPE] Kreeger, L. and Elzur, U. (Eds.), "Generic Protocol
Kreeger, L. and Elzur, U. (Eds.), "Generic Protocol
Extension for VXLAN", <draft-ietf-nvo3-vxlan-gpe-02>, work Extension for VXLAN", <draft-ietf-nvo3-vxlan-gpe-02>, work
in progress, April 2016. in progress, April 2016.
10. Acknowledgments 10. 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. This document was prepared using 2-Word-v2.0.template.dot.
 End of changes. 32 change blocks. 
45 lines changed or deleted 46 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/