Re: [MBONED] [nvo3] NVO3 Multicast Framework

Joe Touch <touch@isi.edu> Mon, 30 January 2017 18:42 UTC

Return-Path: <touch@isi.edu>
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 E374212956E; Mon, 30 Jan 2017 10:42:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.087
X-Spam-Level:
X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, 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 09Mh-DIB-fet; Mon, 30 Jan 2017 10:42:30 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A068C129A92; Mon, 30 Jan 2017 10:42:29 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v0UIfu1Z009443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Jan 2017 10:41:57 -0800 (PST)
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>
References: <20160512144607.T22764@sapphire.juniper.net> <CA+-tSzwqwD4Jb+5bjoKFOmJh-pXODOty_tMHa=DcfBarZmZerg@mail.gmail.com> <1F87ED5D-C2D5-4308-9972-6671063D4F52@gmail.com> <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>
From: Joe Touch <touch@isi.edu>
Message-ID: <ea1c9344-aac1-05ce-2fda-c0a6db02a691@isi.edu>
Date: Mon, 30 Jan 2017 10:41:54 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <004bdb88-ce49-8c8d-3eac-1865c77b00a9@isi.edu>
Content-Type: multipart/alternative; boundary="------------E5108CD8800E279F6259807B"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/u5pggG9d88C4ZgWtKWInhYop_Cc>
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 18:42:32 -0000

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>; 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
>>
>>  
>>
>> 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
>>
>>      
>>
>>  
>>
>