< draft-ietf-nvo3-mcast-framework-08.txt   draft-ietf-nvo3-mcast-framework-09.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, 2017 M. McBride Expires: November 8, 2017 M. McBride
Huawei Huawei
V. Bannai V. Bannai
Google Google
R. Krishnan R. Krishnan
Dell Dell
May 12, 2017 June 23, 2017
A Framework for Multicast in Network Virtualization Overlays A Framework for Multicast in Network Virtualization Overlays
draft-ietf-nvo3-mcast-framework-08 draft-ietf-nvo3-mcast-framework-09
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 7 skipping to change at page 2, line 7
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 November 8, 2016. This Internet-Draft will expire on November 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 3, line 34 skipping to change at page 3, line 34
in the NVO3 Framework document [RFC7365] and NVO3 Architecture in the NVO3 Framework document [RFC7365] and NVO3 Architecture
document [RFC8014]. document [RFC8014].
1.1. Infrastructure multicast 1.1. Infrastructure multicast
Infrastructure multicast is a capability needed by networking Infrastructure multicast is a capability needed by networking
services, such as Address Resolution Protocol (ARP), Neighbor services, such as Address Resolution Protocol (ARP), Neighbor
Discovery (ND), Dynamic Host Configuration Protocol (DHCP), Discovery (ND), Dynamic Host Configuration Protocol (DHCP),
multicast Domain Name Server (mDNS), etc.. RFC3819 Section 5 and 6 multicast Domain Name Server (mDNS), etc.. RFC3819 Section 5 and 6
have detailed description for some of the infrastructure multicast have detailed description for some of the infrastructure multicast
[RFC 3819]. It is possible to provide solutions for these that do [RFC3819]. It is possible to provide solutions for these that do
not involve multicast in the underlay network. In the case of not involve multicast in the underlay network. In the case of
ARP/ND, a network virtualization authority (NVA) can be used for ARP/ND, a network virtualization authority (NVA) can be used for
distributing the mappings of IP address to MAC address to all distributing the mappings of IP address to MAC address to all
network virtualization edges (NVEs). The NVEs can then trap ARP network virtualization edges (NVEs). The NVEs can then trap ARP
Request/ND Neighbor Solicitation messages from the TSs that are Request/ND Neighbor Solicitation messages from the TSs that are
attached to it and respond to them, thereby eliminating the need to attached to it and respond to them, thereby eliminating the need to
for broadcast/multicast of such messages. In the case of DHCP, the for broadcast/multicast of such messages. In the case of DHCP, the
NVE can be configured to forward these messages using a helper NVE can be configured to forward these messages using a helper
function. function.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 are originated and consumed Application-specific multicast traffic are originated and consumed
by user applications. The Application-specific multicast, which can by user applications. The Application-specific multicast, which can
be either Source-Specific Multicast (SSM) or Any-Source Multicast be either Source-Specific Multicast (SSM) or Any-Source Multicast
(ASM)[RFC 3569], has the following characteristics: (ASM)[RFC3569], 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.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
the attributes of the following four methods: the attributes of the following four methods:
1. No multicast support. 1. No multicast support.
2. Replication at the source NVE. 2. Replication at the source NVE.
3. Replication at a multicast service node. 3. Replication at a multicast service node.
4. IP multicast in the underlay. 4. IP multicast in the underlay.
These methods are briefly mentioned in the NVO3 Framework [FW] and These methods are briefly mentioned in the NVO3 Framework [RFC7365]
NVO3 architecture [RFC8014] document. This document provides more and NVO3 architecture [RFC8014] document. This document provides
details about the basic mechanisms underlying each of these methods more details about the basic mechanisms underlying each of these
and discusses the issues and tradeoffs of each. methods and discusses the issues and tradeoffs 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.
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:
 End of changes. 6 change blocks. 
9 lines changed or deleted 9 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/