Re: [MBONED] [nvo3] NVO3 Multicast Framework

Linda Dunbar <linda.dunbar@huawei.com> Mon, 30 January 2017 22:18 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF726129C06; Mon, 30 Jan 2017 14:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.408
X-Spam-Level:
X-Spam-Status: No, score=-7.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWjpv064yhRL; Mon, 30 Jan 2017 14:18:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F31B4129C05; Mon, 30 Jan 2017 14:18:06 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZS98318; Mon, 30 Jan 2017 22:18:03 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 30 Jan 2017 22:18:02 +0000
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Mon, 30 Jan 2017 14:17:55 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Joe Touch <touch@isi.edu>, Olufemi Komolafe <okomolaf@Brocade.com>, Anoop Ghanwani <anoop@alumni.duke.edu>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
Thread-Topic: [nvo3] [MBONED] NVO3 Multicast Framework
Thread-Index: AQHRteC+NFF/VS0VHUej3IfjF8qBRp/IC/wAgAA0MwCAABTVAIAAAd+AgAAOzICAAACPgIAAMnkAgAAC9ACAAAM4gIAAAn+AgA7d2YCAAGWkAIAIlWCggW4HyHCAAJDhAIADpxxggACiroD//3w4cIAAh3wA//9+xECAAIpUgIAAAeoA//+F32AAEhA1gAANjOdA
Date: Mon, 30 Jan 2017 22:17:55 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6592395EB@SJCEML702-CHM.china.huawei.com>
References: <20160512144607.T22764@sapphire.juniper.net> <CAOZewqawSpSyR_HeqafmEZbWYgwX4zV38C4f_-6BcducLiR=Fg@mail.gmail.com> <4AB9E624-D344-420F-A474-10C0BD59F512@gmail.com> <D37706A7.9C91F%matthew.bocci@nokia.com> <CA+-tSzxQVXLa6_+sDzJqN+7Axsbx-fAuG70dv+CDpkT8z4VNYw@mail.gmail.com> <4481e65fecfc4962839023e162521980@EMEAWP-EXMB11.corp.brocade.com> <4A95BA014132FF49AE685FAB4B9F17F6592388CE@SJCEML702-CHM.china.huawei.com> <de48f270-e8b3-41a9-f9cf-9fd4e7c4735d@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F659238E63@SJCEML702-CHM.china.huawei.com> <6211c9af-38fb-d8d5-7c85-ad5712be26e6@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F6592392FB@SJCEML702-CHM.china.huawei.com> <cbfacff3-dce1-b19c-8017-ecd901466d31@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F659239350@SJCEML702-CHM.china.huawei.com> <004bdb88-ce49-8c8d-3eac-1865c77b00a9@isi.edu> <ea1c9344-aac1-05ce-2fda-c0a6db02a691@isi.edu> <4A95BA014132FF49AE685FAB4B9F17F659239409@SJCEML702-CHM.china.huawei.com> <51d4494d-ddf9-2667-9caa-6b35c34e7ff1@isi.edu>
In-Reply-To: <51d4494d-ddf9-2667-9caa-6b35c34e7ff1@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.184]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6592395EBSJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.588FBB9C.0113, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4d5c63c4616e6c56f5b40a9904310b66
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/YLr231I_-AB6RCzZrZsilZCpQfM>
Cc: MBONED WG <mboned@ietf.org>, Truman Boyes <truman@versionsix.org>, "<nvo3@ietf.org>" <nvo3@ietf.org>
Subject: Re: [MBONED] [nvo3] NVO3 Multicast Framework
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 22:18:13 -0000

Joe,

Thanks for your suggestion.

I added the following sentence in the Section 3 (Multicast Mechanisms in networks that use NVO3):

What makes NVO3 different from any other network is that some NVEs, especially the NVE implemented on server, might not support PIM or other multicast mechanisms. They might just encapsulate the data packets from VMs with an outer header. Therefore, it is important for networks using NVO3 to have mechanisms for NVEs, especially the ones that do not support multicast, to map multicast traffic from VMs (users/applications) to proper Outer Header, e.g. figuring out the outer destination address if NVE does not support multicast (e.g. PIM).


If it is Okay with you, I will upload the draft.

Thanks, Linda

From: Joe Touch [mailto:touch@isi.edu]
Sent: 2017年1月30日 14:02
To: Linda Dunbar <linda.dunbar@huawei.com>; Olufemi Komolafe <okomolaf@Brocade.com>; Anoop Ghanwani <anoop@alumni.duke.edu>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>
Cc: MBONED WG <mboned@ietf.org>; Truman Boyes <truman@versionsix.org>; <nvo3@ietf.org> <nvo3@ietf.org>; Williamson, Beau <Beau.Williamson@t-mobile.com>; Dino Farinacci <farinacci@gmail.com>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework




On 1/30/2017 11:38 AM, Linda Dunbar wrote:
Joe,

You asked:
What makes NVO3 different from any other network?

Answer:  Some NVEs, especially the NVE implemented on server, don’t support PIM or other multicast mechanism. They just encapsulate the data packets from VMs with an outer header.
Then the requirement would be:
    NVO3 does not require native multicast, but does require supported multicast capability.


 The “UNIQUE needs of NVO3” is to have the  mechanism for NVEs (especially the ones that don’t support multicast) to map multicast traffic from VMs (users/applications)  to proper Outer Header. E.g. if NVE doesn’t support multicast (PIM), what outer destination address should be.

That needs to be explained in detail, especially for ways to support multicast without PIM.


 All we need is to differentiate multicast messages originated from users/applications from the infrastructure multicast at the introduction section. Not intended to describe in detail of the Infrastructure multicast.

I don’t understand how  RFC3819 (Advice for Internet Subnetwork Designs) can be used. RFC 3819 talks about MTU, TCP/link retransmission, etc.

See sections 5 and 6.

Joe




Linda Dunbar


From: Joe Touch [mailto:touch@isi.edu]
Sent: 2017年1月30日 12:42
To: Linda Dunbar <linda.dunbar@huawei.com><mailto:linda.dunbar@huawei.com>; Olufemi Komolafe <okomolaf@Brocade.com><mailto:okomolaf@Brocade.com>; Anoop Ghanwani <anoop@alumni.duke.edu><mailto:anoop@alumni.duke.edu>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com><mailto:matthew.bocci@nokia.com>
Cc: MBONED WG <mboned@ietf.org><mailto:mboned@ietf.org>; Truman Boyes <truman@versionsix.org><mailto:truman@versionsix.org>; <nvo3@ietf.org><mailto:nvo3@ietf.org> <nvo3@ietf.org><mailto:nvo3@ietf.org>; Williamson, Beau <Beau.Williamson@t-mobile.com><mailto:Beau.Williamson@t-mobile.com>; Dino Farinacci <farinacci@gmail.com><mailto:farinacci@gmail.com>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework


Note: most of what you want to say about multicast has already been observed in RFC 3819.

The discussion in section 1.1 should refer to LANE (RFC1577) as an example.

However, before we get down into this in detail, I have to ask: what makes NVO3 different from any other network?

This WG doesn't need one doc for everything an NVO3 network needs that a network already needs. The docs should focus on the UNIQUE needs of NVO3 or ways in which NVO3 provides multicast that are not available in generic networks.

The rest of the discussion of the need for multicast, etc., ought to cite existing RFCs.
Joe
On 1/30/2017 10:35 AM, Joe Touch wrote:

Hi, Linda,

This isn't correct grammar.

Do you want to say:

Infrastructure multicast is a capability needed by networking services, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..
Joe
On 1/30/2017 10:21 AM, Linda Dunbar wrote:
Joe,

Are you ok with the following?

Infrastructure multicast are for networking services, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..

Linda

From: Joe Touch [mailto:touch@isi.edu]
Sent: 2017年1月30日 12:03
To: Linda Dunbar <linda.dunbar@huawei.com><mailto:linda.dunbar@huawei.com>; Olufemi Komolafe <okomolaf@Brocade.com><mailto:okomolaf@Brocade.com>; Anoop Ghanwani <anoop@alumni.duke.edu><mailto:anoop@alumni.duke.edu>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com><mailto:matthew.bocci@nokia.com>
Cc: MBONED WG <mboned@ietf.org><mailto:mboned@ietf.org>; Truman Boyes <truman@versionsix.org><mailto:truman@versionsix.org>; <nvo3@ietf.org><mailto:nvo3@ietf.org> <nvo3@ietf.org><mailto:nvo3@ietf.org>; Williamson, Beau <Beau.Williamson@t-mobile.com><mailto:Beau.Williamson@t-mobile.com>; Dino Farinacci <farinacci@gmail.com><mailto:farinacci@gmail.com>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework


I'd suggest "networking services", only to avoid the implication that these are all L3.

Joe

On 1/30/2017 9:58 AM, Linda Dunbar wrote:
Joe,

Do you mean the following?

Infrastructure multicast are originated by network services for the purpose of establishing network topology and reachability, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..

Linda

From: Joe Touch [mailto:touch@isi.edu]
Sent: 2017年1月30日 11:49
To: Linda Dunbar <linda.dunbar@huawei.com><mailto:linda.dunbar@huawei.com>; Olufemi Komolafe <okomolaf@Brocade.com><mailto:okomolaf@Brocade.com>; Anoop Ghanwani <anoop@alumni.duke.edu><mailto:anoop@alumni.duke.edu>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com><mailto:matthew.bocci@nokia.com>
Cc: MBONED WG <mboned@ietf.org><mailto:mboned@ietf.org>; Truman Boyes <truman@versionsix.org><mailto:truman@versionsix.org>; <nvo3@ietf.org><mailto:nvo3@ietf.org> <nvo3@ietf.org><mailto:nvo3@ietf.org>; Williamson, Beau <Beau.Williamson@t-mobile.com><mailto:Beau.Williamson@t-mobile.com>; Dino Farinacci <farinacci@gmail.com><mailto:farinacci@gmail.com>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework


Hi, Linda,

These are not all "network protocols", as I noted already.

It might be useful to describe them all as "services", though.

I.e., to replate "network protocols" with "services" (or maybe even "networking services" - to distinguish them from OS services, but not give the impression they belong at the "network" layer).

Joe

On 1/30/2017 8:17 AM, Linda Dunbar wrote:
Joe,

Thank you very much for articulating a more precise definition.

How about this:
Infrastructure multicast are originated by network protocols for the purpose of establishing network topology and reachability, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..

Application-specific multicast traffic are originated and consumed by user applications.
Linda

From: Joe Touch [mailto:touch@isi.edu]
Sent: 2017年1月27日 18:20
To: Linda Dunbar <linda.dunbar@huawei.com><mailto:linda.dunbar@huawei.com>; Olufemi Komolafe <okomolaf@Brocade.com><mailto:okomolaf@Brocade.com>; Anoop Ghanwani <anoop@alumni.duke.edu><mailto:anoop@alumni.duke.edu>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com><mailto:matthew.bocci@nokia.com>
Cc: MBONED WG <mboned@ietf.org><mailto:mboned@ietf.org>; Truman Boyes <truman@versionsix.org><mailto:truman@versionsix.org>; <nvo3@ietf.org><mailto:nvo3@ietf.org> <nvo3@ietf.org><mailto:nvo3@ietf.org>; Williamson, Beau <Beau.Williamson@t-mobile.com><mailto:Beau.Williamson@t-mobile.com>; Dino Farinacci <farinacci@gmail.com><mailto:farinacci@gmail.com>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework




On 1/27/2017 4:03 PM, Linda Dunbar wrote:
[Linda] Infrastructure multicast are originated by network nodes for the purpose of establishing network topology and reachability, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND), Dynamic Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..
+ Also, how would you classify protocols like OSPF, PIM, VRRP etc that are dependent on multicast?  Even if you do not consider them relevant for this framework, perhaps you should briefly mention them?
[Linda] I don’t think we can enumerate all network protocols (many of them use multicast). The purpose is to differentiate multicast originated by network nodes and the multicast originated by applications.
DHCP and mDNS are applications ("L7").

Network nodes don't originate anything; their protocol layers do (link, network, transport, application).

It might be useful to focus on the difference being "network infrastructure" vs "user applications" as the better way to describe the difference. I don't think "network nodes vs. applications" is clear or meaningful.

Joe