< draft-ietf-nvo3-mcast-framework-01.txt   draft-ietf-nvo3-mcast-framework-02.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: May 9, 2016 M. McBride Expires: August 9, 2016 M. McBride
Huawei Huawei
V. Bannai V. Bannai
Google Google
R. Krishnan R. Krishnan
Dell Dell
November 9, 2015 February 10, 2016
A Framework for Multicast in NVO3 A Framework for Multicast in NVO3
draft-ietf-nvo3-mcast-framework-01 draft-ietf-nvo3-mcast-framework-02
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 1, line 43 skipping to change at page 1, line 43
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 9, 2016. This Internet-Draft will expire on August 9 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 32 skipping to change at page 2, line 32
This document discusses a framework of supporting multicast traffic This document discusses a framework of supporting multicast traffic
in a network that uses Network Virtualization Overlays over Layer 3 in a network that uses Network Virtualization Overlays over Layer 3
(NVO3). Both infrastructure multicast and application-specific (NVO3). Both infrastructure multicast and application-specific
multicast are discussed. It describes the various mechanisms that multicast are discussed. It describes the various mechanisms that
can be used for delivering such traffic as well as the data plane can be used for delivering such traffic as well as the data plane
and control plane considerations for each of the mechanisms. 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.2. Application-specific multicast............................3
1.3. Terminology clarification.................................4
2. Acronyms.......................................................4 2. Acronyms.......................................................4
3. Multicast mechanisms in networks that use NVO3.................4 3. Multicast mechanisms in networks that use NVO3.................5
3.1. No multicast support......................................5 3.1. No multicast support......................................5
3.2. Replication at the source NVE.............................6 3.2. Replication at the source NVE.............................6
3.3. Replication at a multicast service node...................8 3.3. Replication at a multicast service node...................8
3.4. IP multicast in the underlay..............................9 3.4. IP multicast in the underlay..............................9
3.5. Other schemes............................................10 3.5. Other schemes............................................11
4. Simultaneous use of more than one mechanism...................10 4. Simultaneous use of more than one mechanism...................11
5. Other issues..................................................11 5. Other issues..................................................11
5.1. Multicast-agnostic NVEs..................................11 5.1. Multicast-agnostic NVEs..................................11
5.2. Multicast membership management for DC with VMs..........12 5.2. Multicast membership management for DC with VMs..........12
6. Summary.......................................................12 6. Summary.......................................................12
7. Security Considerations.......................................12 7. Security Considerations.......................................13
8. IANA Considerations...........................................12 8. IANA Considerations...........................................13
9. References....................................................12 9. References....................................................13
9.1. Normative References.....................................12 9.1. Normative References.....................................13
9.2. Informative References...................................13 9.2. Informative References...................................13
10. Acknowledgments..............................................14 10. Acknowledgments..............................................14
1. Introduction 1. Introduction
Network virtualization using Overlays over Layer 3 (NVO3) is a Network virtualization using Overlays over Layer 3 (NVO3) is a
technology that is used to address issues that arise in building technology that is used to address issues that arise in building
large, multitenant data centers that make extensive use of server large, multitenant data centers that make extensive use of server
virtualization [RFC7364]. virtualization [RFC7364].
This document provides a framework for supporting multicast traffic, This document provides a framework for supporting multicast traffic,
skipping to change at page 3, line 45 skipping to change at page 3, line 47
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.
1.2. Application-specific multicast 1.2. Application-specific multicast
Application-specific multicast traffic, which may be either Source- Application-specific multicast traffic, which may be either Source-
Specific Multicast (SSM) or Any-Source Multicast (ASM)[RFC 3569], Specific Multicast (SSM) or Any-Source Multicast (ASM)[RFC3569],
has the following characteristics: has the following characteristics:
1. Receiver hosts are expected to subscribe to multicast content 1. Receiver hosts are expected to subscribe to multicast content
using protocols such as IGMP [RFC3376] (IPv4) or MLD (IPv6). using protocols such as IGMP [RFC3376] (IPv4) or MLD (IPv6).
Multicast sources and listeners participant in these protocols Multicast sources and listeners participant in these protocols
using addresses that are in the Tenant System address domain. using addresses that are in the Tenant System address domain.
2. The list of multicast listeners for each multicast group is not 2. The list of multicast listeners for each multicast group is not
known in advance. Therefore, it may not be possible for an NVA known in advance. Therefore, it may not be possible for an NVA
to get the list of participants for each multicast group ahead to get the list of participants for each multicast group ahead
of time. of time.
1.3. Terminology clarification
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.
2. Acronyms 2. Acronyms
ASM: Any-Source Multicast ASM: Any-Source Multicast
LISP: Locator/ID Separation Protocol LISP: Locator/ID Separation Protocol
MSN: Multicast Service Node
NVA: Network Virtualization Authority NVA: Network Virtualization Authority
NVE: Network Virtualization Edge NVE: Network Virtualization Edge
NVGRE: Network Virtualization using GRE NVGRE: Network Virtualization using GRE
SSM: Source-Specific Multicast SSM: Source-Specific Multicast
STT: Stateless Tunnel Transport STT: Stateless Tunnel Transport
TS: Tenant system
VM: Virtual Machine
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 VXLAN [VXLAN], NVGRE [NVGRE], STT [STT], etc. encapsulation such as VXLAN [VXLAN], NVGRE [RFC7637], STT [STT],
etc.
Besides the need to support the Address Resolution Protocol (ARP) Besides the need to support the Address Resolution Protocol (ARP)
and Neighbor Discovery (ND), there are several applications that and Neighbor Discovery (ND), there are several applications that
require the support of multicast and/or broadcast in data centers require the support of multicast and/or broadcast in data centers
[DC-MC]. With NVO3, there are many possible ways that multicast may [DC-MC]. With NVO3, there are many possible ways that multicast may
be handled in such networks. We discuss some of the attributes of be handled in such networks. We discuss some of the attributes of
the following four methods: the following four methods:
1. No multicast support. 1. No multicast support.
skipping to change at page 6, line 26 skipping to change at page 6, line 40
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 Tenant Systems in the virtual IP addresses of all the NVEs that have Tenant Systems in the virtual
network instance (VNI) of the Tenant System that generated the network instance (VNI) of the Tenant System that generated the
request. For the support of application-specific multicast traffic, request. For the support of application-specific multicast traffic,
a method similar to that of receiver-sites registration for a a method similar to that of receiver-sites registration for a
particular multicast group described in [LISP-Signal-Free] can be particular multicast group described in [LISP-Signal-Free] can be
used. The registrations from different receiver-sites can be merged used. The registrations from different receiver-sites can be merged
at the NVA, which can construct a multicast replication-list at the NVA, which can construct a multicast replication-list
inclusive of all NVEs to which receivers for a particular multicast inclusive of all NVEs to which receivers for a particular multicast
group are attached. The replication-list for each specific multicast group are attached. The replication-list for each specific multicast
group is maintained either by the NVA. group is maintained by the NVA.
The receiver-sites registration is achieved by egress NVEs The receiver-sites registration is achieved by egress NVEs
performing the IGMP/MLD snooping to maintain state for which performing the IGMP/MLD snooping to maintain state for which
attached Tenant Systems have subscribed to a given IP multicast attached Tenant Systems have subscribed to a given IP multicast
group. When the members of a multicast group are outside the NVO3 group. When the members of a multicast group are outside the NVO3
domain, it is necessary for NVO3 gateways to keep track of the domain, it is necessary for NVO3 gateways to keep track of the
remote members of each multicast group. The NVEs then communicate remote members of each multicast group. The NVEs and NVO3 gateways
these mappings to the NVA. Even if the membership is not then communicate the multicast groups that are of interest to the
communicated to the NVA, if it is necessary to prevent hosts NVA. If the membership is not communicated to the NVA, and if it is
attached to an NVE that have not subscribed to a multicast group necessary to prevent hosts attached to an NVE that have not
from receiving the multicast traffic, the NVE needs to maintain the subscribed to a multicast group from receiving the multicast
multicast group membership. traffic, the NVE would need to maintain multicast group membership
information.
In multi-homing environments, i.e. more than one NVE can reach a
specific TS, the NVA would be expected to provide all the NVEs that
can reach the given TS. The ingress NVE can choose any one of the
egress NVEs for the data frames destined towards the TS.
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 hosts that are part of the VNI. to all hosts that are part of the VNI.
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. This also creates an issue with the times at the source NVE. This also creates an issue with the
forwarding performance of the NVE. forwarding performance of the NVE.
Note that this method is similar to what was used in VPLS [VPLS] Note that this method is similar to what was used in VPLS [RFC4762]
prior to support of MPLS multicast [MPLS-MC]. While there are some prior to support of MPLS multicast [RFC7117]. While there are some
similarities between MPLS VPN and the NVO3 overlay, there are some similarities between MPLS VPN and the NVO3 overlay, there are some
key differences: key differences:
- The CE-to-PE attachment in VPNs is somewhat static, whereas in a - The CE-to-PE attachment in VPNs is somewhat static, whereas in a
DC that allows VMs to migrate anywhere, the TS attachment to NVE DC that allows VMs to migrate anywhere, the TS attachment to NVE
is much more dynamic. is much more dynamic.
- The number of PEs to which a single VPN customer is attached in - 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 an MPLS VPN environment is normally far less than the number of
NVEs to which a VNI's VMs are attached in a DC. NVEs to which a VNI's VMs are attached in a DC.
skipping to change at page 8, line 8 skipping to change at page 8, line 23
of their attached VMs, resulting in considerable wastage of of their attached VMs, resulting in considerable wastage of
bandwidth. bandwidth.
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.
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 to a multicast service node (MSN). The unicast tunnel encapsulation from the ingress NVE to a multicast
MSN, in turn, would create multiple copies of the packet and would service node (MSN). The MSN, in turn, would create multiple copies
deliver a copy, using a unicast tunnel encapsulation, to each of the of the packet and would deliver a copy, using a unicast tunnel
NVEs that are part of the multicast group for which the packet is encapsulation, to each of the NVEs that are part of the multicast
intended. group for which the packet is intended.
This mechanism is similar to that used by the ATM Forum's LAN This mechanism is similar to that used by the ATM Forum's LAN
Emulation [LANE] specification [LANE]. Emulation [LANE] specification [LANE].
The following are the possible ways for the MSN to get the The following are the possible ways for the MSN to get the
membership information for each multicast group: membership information for each multicast group:
- The MSN can obtain this information by snooping the IGMP/MLD - The MSN can obtain this information by snooping the IGMP/MLD
messages from the Tenant Systems and/or sending query messages to messages from the Tenant Systems and/or sending query messages to
the Tenant Systems. In order for MSN to snoop the IGMP/MLD the Tenant Systems. In order for MSN to snoop the IGMP/MLD
skipping to change at page 9, line 20 skipping to change at page 9, line 39
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 Layer 2 network, there If an NVE connects to its attached TSs via 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:
- 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.
-
- 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-
PIM) would offer better scalability with the number of flows PIM) would offer better scalability with the number of flows
skipping to change at page 10, line 23 skipping to change at page 10, line 44
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
another one does, the former's multicast packets would still be another one does, the former's multicast packets would still be
delivered to that NVE). It also introduces an additional network delivered to that NVE). It also introduces an additional network
management burden to optimize which tenants should be part of the management burden to optimize which tenants should be part of the
same tenant group (based on the NVEs they share), which somewhat same tenant group (based on the NVEs they share), which somewhat
dilutes the value proposition of NVO3 which is to completely dilutes the value proposition of NVO3 which is to completely
decouple the overlay and physical network design allowing complete decouple the overlay and physical network design allowing complete
freedom of placement of VMs anywhere within the data center. freedom of placement of VMs anywhere within the data center.
Multicast schemes such as BIER (Bit Index Explicit Replication) may Multicast schemes such as BIER (Bit Indexed Explicit Replication)
be able to provide optimizations by allowing the underlay network to [BIER-ARCH] may be able to provide optimizations by allowing the
provide optimum multicast delivery without requiring routers in the underlay network to provide optimum multicast delivery without
core of the network to main per-multicast group state. requiring routers in the core of the network to main per-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 (router) versus amount of replication at an intermediate node (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.
skipping to change at page 11, line 22 skipping to change at page 12, line 4
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
MSN get the updated multicast group information, the MSN can also the MSN to get the updated multicast group information, the MSN can
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 the NVEs
to which the TSs in the VN are attached. to which the TSs in the VN are attached.
However, MSN may not always be aware of the client specific However, the MSN may not always be aware of the client specific
multicast addresses. Then MSN has to snoop the IGMP/MLD messages multicast addresses. In order to perform multicast filtering, the
between TSs and their corresponding routers to maintain the MSN has to snoop the IGMP/MLD messages between TSs and their
multicast membership. In order for MSN to snoop the IGMP/MLD corresponding routers to maintain the multicast membership. In order
messages between TSs and their router, NVA needs to configure the for the MSN to snoop the IGMP/MLD messages between TSs and their
NVE to send copies of the IGMP/MLD messages to the MSN in addition router, the NVA needs to configure the NVE to send copies of the
to the default behavior of sending them to the TSs' routers; e.g. IGMP/MLD messages to the MSN in addition to the default behavior of
the NVA has to inform the NVEs to encapsulate data frames with DA sending them to the TSs' routers; e.g. the NVA has to inform the
being 224.0.0.2 (destination address of IGMP report) to TSs' router NVEs to encapsulate data frames with DA being 224.0.0.2 (destination
and MSN. address of IGMP report) to TSs' router and MSN.
This process is similar to "Source Replication" described in Section This process is similar to "Source Replication" described in Section
3.2, except the NVEs only replicate the message to TS's router and 3.2, except the NVEs only replicate the message to TSs' router and
MSN. 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 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
skipping to change at page 13, line 11 skipping to change at page 13, line 30
[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.
[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.
[NVO3-ARCH] Narten, T. et al.," An Architecture for Overlay Networks [NVO3-ARCH] Narten, T. et al.," An Architecture for Overlay Networks
(NVO3)", work in progress, February 2014. (NVO3)", work in progress, February 2014.
[RFC3376] B. Cain, et al, "Internet Group Management Protocol, [RFC3376] Cain B. et al., "Internet Group Management Protocol,
Version 3", October 2002. Version 3", October 2002.
[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.
9.2. Informative References 9.2. Informative References
[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.
[NVGRE] Sridharan, M. et al., "NVGRE: Network virtualization using [RFC7637] Garg P. and Wang, Y. (Eds.), "NVGRE: Network
Generic Routing Encapsulation", work in progress. Virtualization using Generic Routing Encapsulation",
September 2015.
[STT] Davie, B. and Gross J., "A stateless transport tunneling
protocol for network virtualization," work in progress.
[DC-MC] McBride M., and Lui, H., "Multicast in the data center [STT] Davie, B. and Gross, J., "A stateless transport tunneling
overview," work in progress. protocol for network virtualization," work in progress.
[ISIS-Multicast] [DC-MC] McBride M., and Lui, H., "Multicast in the data center
overview," work in progress.
L. Yong, et al, "ISIS Protocol Extension For Building [ISIS-Multicast]
Distribution Trees", work in progress. Oct 2013. L. Yong, et al., "ISIS Protocol Extension for Building
Distribution Trees", work in progress.
[VPLS] Lasserre, M., and Kompella, V. (Eds), "Virtual Private LAN [RFC4762] Lasserre, M., and Kompella, V. (Eds.), "Virtual Private
Service (VPLS) using Label Distribution Protocol (LDP) LAN Service (VPLS) using Label Distribution Protocol (LDP)
signaling," RFC 4762, January 2007. signaling," January 2007.
[MPLS-MC] Aggarwal, R. et al., "Multicast in VPLS," work in [RFC7117] Aggarwal, R. et al., "Multicast in VPLS," February 2014.
progress.
[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.
[EDGE-REP] [EDGE-REP]
Marques P. et al., "Edge multicast replication for BGP IP Marques P. et al., "Edge multicast replication for BGP IP
VPNs," work in progress, June 2012. VPNs," work in progress..
[RFC 3569]
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.
[LISP-Signal-Free] [LISP-Signal-Free]
Moreno, V. and Farinacci, D., "Signal-Free LISP
V. Moreno & D. Farinacci, "Signal-Free LISP Multicast", Multicast", work in progress.
work in progress. Dec 2014.
10. Acknowledgments 10. Acknowledgments
Thanks are due to Dino Farinacci and Erik Nordmark for their Thanks are due to Dino Farinacci, Erik Nordmark, Lucy Yong, and
comments and suggestions. Nicolas Bouliane, for their 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.
Authors' Addresses Authors' Addresses
Anoop Ghanwani Anoop Ghanwani
Dell Dell
Email: anoop@alumni.duke.edu Email: anoop@alumni.duke.edu
Linda Dunbar Linda Dunbar
skipping to change at page 15, line 28 skipping to change at page 15, line 28
Mike McBride Mike McBride
Huawei Technologies Huawei Technologies
mmcbride7@gmail.com mmcbride7@gmail.com
Vinay Bannai Vinay Bannai
Google Google
Email: vbannai@gmail.com Email: vbannai@gmail.com
Ram Krishnan Ram Krishnan
Dell Dell
Email: Ramki_Krishnan@dell.com Email: ramkri123@gmail.com
 End of changes. 42 change blocks. 
81 lines changed or deleted 98 lines changed or added

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