Re: [nvo3] [MBONED] NVO3 Multicast Framework

Behcet, 

Many Server based NVEs don't support PIM. 
The draft's Section 3.2 and 3.3 describes the mechanisms when VMs send out multicast data frames

Linda

-----Original Message-----
From: Behcet Sarikaya [mailto:sarikaya2012@gmail.com] 
Sent: 2017年1月30日 16:25
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Joe Touch <touch@isi.edu>; Olufemi Komolafe <okomolaf@brocade.com>; Anoop Ghanwani <anoop@alumni.duke.edu>; Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>; 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 Mon, Jan 30, 2017 at 4:17 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:
> 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).
>

PIM support is needed at the NVE only if any of the VMs is a multicast source which is usually a rare situation.

Otherwise MLD/IGMP Proxy would normally need to be supported at the NVE level.

Regards,

Behcet

>
>
>
>
> 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>; 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
>
>
>
> 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>; 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
>
>
>
> 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>; 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/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
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>