Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

From: Linda Dunbar <[email-masked]>
Date: Sat, 28 Jan 2017 00:03:38 +0000

Olufemi,

Sorry for taking so long to address your comments.

Replies to your comments are inserted below:

From: nvo3 [mailto:[email-masked]] On Behalf Of Olufemi Komolafe
Sent: 2016年6月8日 20:22
To: Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>; <[email-masked]> <[email-masked]>; Williamson, Beau <[email-masked]>; Dino Farinacci <[email-masked]>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

I thought the draft was very well-written, being succinct and well-structured.  I found it very interesting.  Some suggestions:

Section 1.1 & 1.2
+ I did not find the distinction between "Infrastructure multicast" and "Application-specific multicast" intuitive.  Are there better terminology that could be used?  Or even a brief sentence in the  preceding Section 1 giving a brief definition of these terms?

[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.

Section 3.3
+ The MSN seems similar to the RP in PIM SM  which is probably worth mentioning (with the difference that the MSN sends unicast  packets towards the endpoints)

[Linda] The MSN is similar to the RP in PIM SM, but different in that the user data traffic are carried by the NVO3 tunnels.

+ What query messages could the MSN use to extract group membership information from the TS?  Please what did you have in mind as possibilities here?

[Linda] any of  the following steps can do the job:

-        The MSN can obtain this information by snooping the IGMP/MLD messages from the TSs by sending query messages to the TSs.

-        The MSN can obtain this information by snooping the IGMP/MLD messages from the TSs by sending query messages to the TSs.  In order for MSN to snoop the IGMP/MLD messages from TSs, the IGMP/MLD queries from MSN must have the MSN address in the Source Address field, and the IGMP/MLD queries have to be encapsulated with outer addresses destined towards the NVEs that TSs are attached. By doing so, the NVEs can establish the mapping between MSN address and the IGMP/MLD reports from the TSs, so that the IGMP/MLD reports from TSs can be encapsulated with the outer address destined towards the multicast server node.

-        The MSN can obtain the membership information from the NVEs that snoop the IGMP/MLD messages. This can be done by having the MSN communicate with the NVEs (p.s. the communication must be specific to the multicast addresses), or by having the NVA obtain the information from the NVEs, and in turn have MSN communicate with the NVA. This approach requires additional protocol between MSN and NVEs.

-

+ "there is no performance impact at the ingress NVE": perhaps this sentence should be toned down a bit as the ingress NVE has to additionally encapsulate the multicast packets in the unicast tunnel?
[Linda] This is referring to comparing with method described in 3.2.

I think it may be possible to summarise many of the points in your draft succinctly in a table which perhaps may be good as a quick reference in a framework document?
For example,
The column headings headings will be something like
1. Multicast mechanism
2. Ingress NVE to replication point transport
3. Replication point
4. Replication point to egress NVE transport
[you could also add a "Key Requirements", "Advantages", "Disadvantages" columns etc.]

[Linda] Yes, the current structure is based on what kind of mechanisms being supported. Not every NVE support head end replication.

And the rows would summarise the 3 different multicast mechanisms.

So for example, for the source replication row, you could have:
1. Replication at source NVE
2. NA
3. Source NVE
4. Unicast tunnels
etc

[Linda] the current structure already described all items above.

For the replication at MSN row, you could have
1. Replication at multicast service node
2. Unicast tunnel
3. Multicast service node
4. Unicast tunnel
etc

For the multicast in the underlay row, you could have
1. IP multicast in the underlay
2. Multicast packets
3. Any node in underlay network
4. Multicast packets
etc

Regards,
Femi

Thank you very much.

Linda

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Friday, June 03, 2016 5:14 PM
To: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: MBONED WG <[email-masked]<mailto:[email-masked]>>; Truman Boyes <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; Williamson, Beau <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

Thanks Matt.

We will post an update in the next few days.

Anoop

On Fri, Jun 3, 2016 at 2:10 AM, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>> wrote:
This email closes the extended review of draft-ietf-nvo3-mcast-framework.

Thanks for the review and comments on this draft. I saw one suggestion for
specific modification to the draft.

Please can the authors make these updates and I¹mm continue with the
document shepherd process.

Regards

Matthew

On 25/05/2016, 00:08, "Dino Farinacci" <[email-masked]<mailto:[email-masked]>> wrote:

>
>> Switch table sizes should always be considered. Current (S,G) scaling
>>on today's powerful routers are still an issue when rebuilding trees.
>>The Bidir approach or overlay approach with MC underlay support are good
>>target architectures to address tree creation/convergence.
>
>Again, the same ole tradeoff, if you want the best (S,G) scaling and no
>convergence problems in the underlay, then you do head-end-replication at
>the expense of extra bandwidth from the head-end.
>
>However, with LISP signal-free multicast you can use a core based RTR so
>there is one copy sent from head-end and the RTR(s) replicate in the core
>where there is more bandwidth attached on the RTR then there was on the
>head-end. And you still require no state in the core routers other than
>the RTR.
>
>The same ole tradeoff, state versus bandwidth.
>
>Dino
>
>>
>> //Truman
>>
>>
>> On Tue, May 24, 2016 at 6:48 PM Dino Farinacci <[email-masked]<mailto:[email-masked]>>
>>wrote:
>> > On May 24, 2016, at 3:37 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
>>wrote:
>> >
>> > Hi Dino,
>> >
>> > If switch table sizes for IP multicast forwarding are a
>>consideration, would SSM still be the preferred method?
>>
>> It depends on the number of sources. But an (S,G) and a (*,G), each
>>represent one entry. If you use Bidir, then only (*,G) entries are
>>supported at the expense of longer paths from any source.
>>
>> The same ole tradeoff.
>>
>> But for multicast overlays, where the underlay supports multicast, that
>>state in the core can be reduced to the number ITRs (source-VTEP)
>>sending to the ETR (destination-VTEP) group. So, for example,
>> 1000 sources behind ITRa, that sends to many different groups where the
>>same set of ETRb and ETRc have receivers, then only a single (ITRa,G)
>>entry is necessary in the multicast underlay.
>>
>> Dino
>>
>> >
>> > Thanks,
>> > Anoop
>> >
>> > On Tue, May 24, 2016 at 12:37 PM, Dino Farinacci
>><[email-masked]<mailto:[email-masked]>> wrote:
>> > Both RFC6831 and draft-ietf-lisp-signal-free describe why SSM is a
>>preferred solution.
>> >
>> > Dino
>> >
>> > On May 24, 2016, at 12:35 PM, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
>>wrote:
>> >
>> >> Thanks Beau & Dino.
>> >>
>> >> We'll add a reference to RFC 6831 and a brief discussion of SSM.
>> >>
>> >> Anoop
>> >>
>> >> On Tue, May 24, 2016 at 11:42 AM, Dino Farinacci
>><[email-masked]<mailto:[email-masked]>> wrote:
>> >> If a reference to RFC6831 is provided, then there are many details
>>on how an underlay can support ASM, Bidir, and SSM.
>> >>
>> >> Dino
>> >>
>> >> > On May 24, 2016, at 11:35 AM, Williamson, Beau
>><[email-masked]<mailto:[email-masked]>> wrote:
>> >> >
>> >> > I'd like to see Section 3.4, "IP multicast in the underlay"
>>expanded a bit.
>> >> >
>> >> > The section mentions the use of BIDIR for a scalable underlay.
>>The sad fact is that many vendors still do not fully support BIDIR in
>>their devices (after how many years?) or have limitations on its use
>>that preclude it as a viable option.  I'm no expert in these Underlay
>>sort of DC to DC networks but it seems that SSM would not have that
>>issue since it is basically a subset (and much simpler to implement and
>>configure) of the PIM protocol and would therefore be available in
>>pretty much all vendor devices that support multicast.  The problem is
>>one of Source Discovery of the VTEPs (or, in the case of this draft I
>>think the term is NVE) which would be the sources of the multicast
>>traffic in each TS.
>> >> >
>> >> > At the very least, I'd like to see a paragraph discussing the
>>possible use of SSM as an alternative to BIDIR if the VTEP/NVE devices
>>had a way to learn of each other's IP address so that they could join
>>all SSM SPT's to create/maintain an underlay SSM IP Multicast tunnel
>>solution.  This would greatly simplify the configuration and management
>>of the underlay IP Multicast environment.
>> >> >
>> >> > I realize that the VTEP/NVE Source Discovery problem is beyond the
>>scope of this Framework document but I'd like to see the above mentioned
>>to possibly encourage more work in this area if it is not already
>>underway.
>> >> >
>> >> >
>> >> > Beau Williamson
>> >> > CCIE #1346 R/S Emeritus
>> >> > Principal Member of Technical Staff
>> >> > Corporate Engineering
>> >> > metroPCS/T-Mobile
>> >> > Internal: 314982
>> >> > Office:   469.330.4982<tel:469.330.4982>
>> >> > Mobile:   972.679.4334<tel:972.679.4334>
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: MBONED [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Dino
>>Farinacci
>> >> > Sent: Tuesday, May 24, 2016 12:21 PM
>> >> > To: Bocci, Matthew (Nokia - GB)
>> >> > Cc: MBONED WG; <[email-masked]<mailto:[email-masked]>>
>> >> > Subject: Re: [MBONED] NVO3 Multicast Framework
>> >> >
>> >> > Sorry, I thought I had. NVo3, see my comments below.
>> >> >
>> >> > Dino
>> >> >
>> >> >> On May 24, 2016, at 6:14 AM, Bocci, Matthew (Nokia - GB)
>><[email-masked]<mailto:[email-masked]>> wrote:
>> >> >>
>> >> >> Hi Dino
>> >> >>
>> >> >> Could you copy NVO3 on your comments, please?
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Matthew
>> >> >>
>> >> >> From: EXT Dino Farinacci <[email-masked]<mailto:[email-masked]>>
>> >> >> Date: Monday, 16 May 2016 at 23:31
>> >> >> To: Leonard Giuliano <[email-masked]<mailto:[email-masked]>>
>> >> >> Cc: MBONED WG <[email-masked]<mailto:[email-masked]>>, Matthew Bocci
>><[email-masked]<mailto:[email-masked]>>, Benson Schliesser
>><[email-masked]<mailto:[email-masked]>>
>> >> >> Subject: Re: [MBONED] NVO3 Multicast Framework
>> >> >>
>> >> >> I just have one minor comment. Regarding the second paragraph:
>> >> >>
>> >> >>
>> >> >> Using LISP-signal-free does not mean the head-end must do
>>replication. The draft indicates that a mapping system is used to decide
>>where packets go. If the mapping database indicates that packets are
>>encapsulated to multicast RLOCs, or unicast RLOCs, or both in one set,
>>so be it.
>> >> >>
>> >> >> And note if there is a single multicast RLOC, then there is no
>>replication happening at the head-end, just one packet encapsulting
>>multicast in multicast.
>> >> >>
>> >> >> So what is written above is true, but it may be associated with
>>an incorrect section title.
>> >> >>
>> >> >> Dino
>> >> >>
>> >> >>> On May 12, 2016, at 2:52 PM, Leonard Giuliano
>><[email-masked]<mailto:[email-masked]>> wrote:
>> >> >>>
>> >> >>> MBONED,
>> >> >>>
>> >> >>> The following draft recently went through WG last call in the
>>NVO3 working group:
>> >> >>>
>> >> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnvo3-2Dmcast-2Dframework_&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=IiLKJoOYjbD7xFL_yekuC8ZJl0lRw188OqJDBHmhP3g&e=
>> >> >>>
>> >> >>> This doc covers multicast in data center overlay networks.  As
>>you know, it is part of our charter in MBONED to provide feedback to
>>other relevant working groups.  Please review and send any comments to
>>the NVO3 WG mailing list ([email-masked]<mailto:[email-masked]>)- all comments will be greatly
>>appreciated by NVO3.
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> MBONED mailing list
>> >> >>> [email-masked]<mailto:[email-masked]>
>> >> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=Q-tQfNBIRBN8E8O9QqzY819WguDm9Jti7NJh1LM6RRA&e=
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > MBONED mailing list
>> >> > [email-masked]<mailto:[email-masked]>
>> >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=Q-tQfNBIRBN8E8O9QqzY819WguDm9Jti7NJh1LM6RRA&e=
>> >>
>> >> _______________________________________________
>> >> nvo3 mailing list
>> >> [email-masked]<mailto:[email-masked]>
>> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=cmcllRtVM8-EUssGIZ3xAsUmY6I-KNHn4MKwt8Hh0BM&e=
>> >>
>> >
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=cmcllRtVM8-EUssGIZ3xAsUmY6I-KNHn4MKwt8Hh0BM&e=
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Jan 2017 16:20:06 -0800

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

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 16:17:27 +0000

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:[email-masked]]
Sent: 2017年1月27日 18:20
To: Linda Dunbar <[email-masked]>; Olufemi Komolafe <[email-masked]>; Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>; <[email-masked]> <[email-masked]>; Williamson, Beau <[email-masked]>; Dino Farinacci <[email-masked]>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2017 09:49:15 -0800

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:
> /Infrastructure multicast are originated by network //protocols //for
> /Application-specific multicast traffic are originated and consumed by
> user applications./
>
> Linda
>
>  
>
> *From:*Joe Touch [mailto:[email-masked]]
> *Sent:* 2017年1月27日18:20
> *To:* Linda Dunbar <[email-masked]>; Olufemi Komolafe
> <[email-masked]>; Anoop Ghanwani <[email-masked]>; Bocci,
> Matthew (Nokia - GB) <[email-masked]>
> *Cc:* MBONED WG <[email-masked]>; Truman Boyes
> <[email-masked]>; <[email-masked]> <[email-masked]>; Williamson,
> Beau <[email-masked]>; Dino Farinacci <[email-masked]>
> *Subject:* Re: [nvo3] [MBONED] NVO3 Multicast Framework
>
>  
>
>  
>
>  
>
>     /[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. /
>
> 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
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 17:58:42 +0000

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

Sent: 2017年1月30日 11:49

Hi, Linda,

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

How about this:

From: Joe Touch [mailto:[email-masked]]
Sent: 2017年1月27日 18:20
To: Linda Dunbar <[email-masked]><mailto:[email-masked]>; Olufemi Komolafe <[email-masked]><mailto:[email-masked]>; Anoop Ghanwani <[email-masked]><mailto:[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]><mailto:[email-masked]>
Cc: MBONED WG <[email-masked]><mailto:[email-masked]>; Truman Boyes <[email-masked]><mailto:[email-masked]>; <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>; Williamson, Beau <[email-masked]><mailto:[email-masked]>; Dino Farinacci <[email-masked]><mailto:[email-masked]>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2017 10:02:30 -0800

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:
> /Infrastructure multicast are originated by network //services //for
> *Sent:* 2017年1月30日11:49
>     /Infrastructure multicast are originated by network //protocols
>     //for the purpose of establishing network topology and
>     /Application-specific multicast traffic are originated and
>     consumed by user applications./
>
>     Linda
>
>      
>
>     *To:* Linda Dunbar <[email-masked]>
>     <mailto:[email-masked]>; Olufemi Komolafe
>     <[email-masked]> <mailto:[email-masked]>; Anoop
>     Ghanwani <[email-masked]> <mailto:[email-masked]>;
>     Bocci, Matthew (Nokia - GB) <[email-masked]>
>     <mailto:[email-masked]>
>     *Cc:* MBONED WG <[email-masked]> <mailto:[email-masked]>; Truman
>     Boyes <[email-masked]> <mailto:[email-masked]>;
>     <[email-masked]> <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>; Williamson, Beau
>     <[email-masked]>
>     <mailto:[email-masked]>; Dino Farinacci
>     <[email-masked]> <mailto:[email-masked]>
>         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?
>
>         multicast originated by network nodes and the multicast
>         originated by applications. /
>
>     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
>
>  
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 18:21:21 +0000

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

Sent: 2017年1月30日 12:03

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

Joe

Linda

Hi, Linda,

Joe

How about this:

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2017 10:35:03 -0800

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:
> /Infrastructure multicast are //for networking services//, such as
> *Sent:* 2017年1月30日12:03
>     /Infrastructure multicast are originated by network //services
>     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
>
>      
>
>         /Infrastructure multicast are originated by network
>         //protocols //for the purpose of establishing network topology
>         and reachability, such as Address Resolution Protocol (ARP),
>         Ghanwani <[email-masked]>
>         <mailto:[email-masked]>; Bocci, Matthew (Nokia - GB)
>         <[email-masked]> <mailto:[email-masked]>
>         *Cc:* MBONED WG <[email-masked]> <mailto:[email-masked]>;
>         Truman Boyes <[email-masked]>
>         <mailto:[email-masked]>; <[email-masked]>
>         <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>;
>         Williamson, Beau <[email-masked]>
>             /[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. /
>
>         Network nodes don't originate anything; their protocol layers
>         do (link, network, transport, application).
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2017 10:41:54 -0800

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:
>> <[email-masked]>; Anoop Ghanwani <[email-masked]>;
>>     even "networking services" - to distinguish them from OS
>>     services, but not give the impression they belong at the
>>     "network" layer).
>>
>>     Joe
>>
>>      
>>
>>         //protocols //for the purpose of establishing network
>>         Configuration Protocol (DHCP), multicast Domain Name Server
>>         (mDNS), etc../
>>
>>          
>>
>>         <mailto:[email-masked]> <[email-masked]>
>>             not consider them relevant for this framework, perhaps
>>             you should briefly mention them?
>>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 19:38:04 +0000

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.

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.

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.

Linda Dunbar

Sent: 2017年1月30日 12:42

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

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,

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,

Linda

Joe

Linda

Hi, Linda,

Joe

How about this:

Joe

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 19:41:04 +0000

Joe,

To close the loop and make the document forward, we simply say the following:

Infrastructure multicast is a capability needed by networking services, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND).

Linda

Sent: 2017年1月30日 12:35

Hi, Linda,

Do you want to say:

Linda

Joe

Linda

Hi, Linda,

Joe

How about this:

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jan 2017 12:01:59 -0800

On 1/30/2017 11:38 AM, Linda Dunbar wrote:
> 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

> *Sent:* 2017年1月30日12:42
> 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.
>
>     /Infrastructure multicast /*is a capability needed by */networking
>         /Infrastructure multicast are //for networking services//,
>         such as Address Resolution Protocol (ARP), Neighbor Discovery
>         (ND), Dynamic Host Configuration Protocol (DHCP), multicast
>             //services //for the purpose of establishing network
>             <[email-masked]> <mailto:[email-masked]>;
>             Anoop Ghanwani <[email-masked]>
>             <mailto:[email-masked]>; Bocci, Matthew (Nokia -
>             GB) <[email-masked]> <mailto:[email-masked]>
>             *Cc:* MBONED WG <[email-masked]>
>             <mailto:[email-masked]>; Truman Boyes
>             <[email-masked]> <mailto:[email-masked]>;
>             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
>
>              
>
>                 /Application-specific multicast traffic are originated
>                 and consumed by user applications./
>
>                 Linda
>
>                  
>
>                 <[email-masked]> <mailto:[email-masked]>;
>                 Anoop Ghanwani <[email-masked]>
>                 <mailto:[email-masked]>; Bocci, Matthew (Nokia
>                 - GB) <[email-masked]>
>                 *Cc:* MBONED WG <[email-masked]>
>                 <mailto:[email-masked]>; Truman Boyes
>                 <[email-masked]>
>                     /[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),
>                     + Also, how would you classify protocols like
>                     OSPF, PIM, VRRP etc that are dependent on
>                     multicast?  Even if you do not consider 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
>                 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
>
>              
>
>          
>
>      
>
>  
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 22:17:55 +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

Sent: 2017年1月30日 14:02

You asked:

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.

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

See sections 5 and 6.

Joe

Linda Dunbar

Hi, Linda,

Do you want to say:

Linda

Joe

Linda

Hi, Linda,

Joe

How about this:

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Jan 2017 16:25:11 -0600

On Mon, Jan 30, 2017 at 4:17 PM, Linda Dunbar <[email-masked]> wrote:
> 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

> To: Linda Dunbar <[email-masked]>; Olufemi Komolafe
> Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>;
> <[email-masked]> <[email-masked]>; Williamson, Beau
> <[email-masked]>; Dino Farinacci <[email-masked]>
> 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.
>
>  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.
>
>
> 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
>
>
>
>
>
> To: Linda Dunbar <[email-masked]>; Olufemi Komolafe
> Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>;
> <[email-masked]> <[email-masked]>; Williamson, Beau
> <[email-masked]>; Dino Farinacci <[email-masked]>
> 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.
>
> 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
>
> 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
>
>
>
> To: Linda Dunbar <[email-masked]>; Olufemi Komolafe
> Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>;
> <[email-masked]> <[email-masked]>; Williamson, Beau
> <[email-masked]>; Dino Farinacci <[email-masked]>
> 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
>
>
>
> To: Linda Dunbar <[email-masked]>; Olufemi Komolafe
> Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>;
> <[email-masked]> <[email-masked]>; Williamson, Beau
> <[email-masked]>; Dino Farinacci <[email-masked]>
> "networking services" - to distinguish them from OS services, but not give
> the impression they belong at the "network" layer).
>
> Joe
>
>
>
> 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..
>
>
>
> To: Linda Dunbar <[email-masked]>; Olufemi Komolafe
> Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>;
> <[email-masked]> <[email-masked]>; Williamson, Beau
> <[email-masked]>; Dino Farinacci <[email-masked]>
> [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.
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 22:40:54 +0000

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:[email-masked]] 
Sent: 2017年1月30日 16:25
To: Linda Dunbar <[email-masked]>
Cc: Joe Touch <[email-masked]>; Olufemi Komolafe <[email-masked]>; Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>; MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>; <[email-masked]> <[email-masked]>; Williamson, Beau <[email-masked]>; Dino Farinacci <[email-masked]>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

On Mon, Jan 30, 2017 at 4:17 PM, Linda Dunbar <[email-masked]> wrote:
> 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.

Regards,

Behcet

> traffic from VMs
> (users/applications)  to proper Outer Header. E.g. if NVE doesn’t 
> support multicast (PIM), what outer destination address should be.
>
>
> introduction section. Not intended to describe in detail of the Infrastructure multicast.
>
>
>
> Designs) can be used. RFC 3819 talks about MTU, TCP/link retransmission, etc.
>
>
> See sections 5 and 6.
>
> Joe
>
>
>
>
>
>
> Linda Dunbar
>
>
>
>
>
> 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
>
> Infrastructure multicast are originated by network services for the 
> purpose of establishing network topology and reachability, such as 
> Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..
>
>
>
> Linda
>
>
>
> Infrastructure multicast are originated by network protocols for the 
> purpose of establishing network topology and reachability, such as 
> Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..
>
>
>
> [Linda] Infrastructure multicast are originated by network nodes for 
> Host Configuration Protocol (DHCP), multicast Domain Name Server (mDNS), etc..
>
> + 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 
> originated by network nodes and the multicast originated by applications.
>
> vs "user applications" as the better way to describe the difference. I 
> don't think "network nodes vs. applications" is clear or meaningful.
>
> Joe
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 30 Jan 2017 22:51:50 +0000

Joe,

I will also add the reference to RFC 3819 as it has good description of the “infrastructure multicast”.

Infrastructure multicast is a capability needed by networking services, such as Address Resolution Protocol (ARP), Neighbor Discovery (ND). RFC3819 Section 5 & 6 have detailed description for some of the infrastructure multicast [RFC 3819].

Please let me know if it is good enough.

Linda

From: Linda Dunbar
Sent: 2017年1月30日 13:41
To: 'Joe Touch' <[email-masked]>; Olufemi Komolafe <[email-masked]>; Anoop Ghanwani <[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]>
Cc: MBONED WG <[email-masked]>; Truman Boyes <[email-masked]>; <[email-masked]> <[email-masked]>; Williamson, Beau <[email-masked]>; Dino Farinacci <[email-masked]>
Subject: RE: [nvo3] [MBONED] NVO3 Multicast Framework

Joe,

Linda

From: Joe Touch [mailto:[email-masked]]
Sent: 2017年1月30日 12:35
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; Olufemi Komolafe <[email-masked]<mailto:[email-masked]>>; Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Cc: MBONED WG <[email-masked]<mailto:[email-masked]>>; Truman Boyes <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; Williamson, Beau <[email-masked]<mailto:[email-masked]>>; Dino Farinacci <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] [MBONED] NVO3 Multicast Framework

Hi, Linda,

Do you want to say:

Linda

Joe

Linda

Hi, Linda,

Joe

How about this:

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Jan 2017 07:55:06 -0800

That looks good.

Joe

On 1/30/2017 2:51 PM, Linda Dunbar wrote:
> Discovery (ND). RFC3819 Section 5 & 6 have detailed description for
> some of the infrastructure multicast [RFC 3819]. /
>
>  
>
> *From:*Linda Dunbar
> *Sent:* 2017年1月30日13:41
> *To:* 'Joe Touch' <[email-masked]>; Olufemi Komolafe
> *Subject:* RE: [nvo3] [MBONED] NVO3 Multicast Framework
>
>  
>
> Joe,
>
>  
>
> Discovery (ND). /
> / /
> *Sent:* 2017年1月30日12:35
> *To:* Linda Dunbar <[email-masked]
> <mailto:[email-masked]>>; Olufemi Komolafe
> <[email-masked] <mailto:[email-masked]>>; Anoop Ghanwani
> <[email-masked] <mailto:[email-masked]>>; Bocci, Matthew
> (Nokia - GB) <[email-masked] <mailto:[email-masked]>>
> *Cc:* MBONED WG <[email-masked] <mailto:[email-masked]>>; Truman
> Boyes <[email-masked] <mailto:[email-masked]>>;
> <[email-masked] <mailto:[email-masked]>> <[email-masked]
> <mailto:[email-masked]>>; Williamson, Beau
> <[email-masked] <mailto:[email-masked]>>;
> Dino Farinacci <[email-masked] <mailto:[email-masked]>>
>     Address Resolution Protocol (ARP), Neighbor Discovery (ND),
>     Dynamic Host Configuration Protocol (DHCP), multicast Domain Name
>     Server (mDNS), etc../
>
>      
>
>     Linda
>
>      
>
>                 + 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
>                 protocols (many of them use multicast). The purpose is
>                 to differentiate multicast originated by network nodes
>                 and the multicast originated by applications. /
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Jan 2017 07:58:16 -0800

On 1/30/2017 2:17 PM, Linda Dunbar wrote:
> /What makes NVO3 different from any other network is that some NVEs,
> especially the NVE implemented on server, might not support PIM or other /
>
native...

> /multicast mechanisms. They might just encapsulate the data packets
> from VMs with an outer /
>
/unicast/
>
> /header. Therefore, it is important for networks using NVO3 to have
> mechanisms /
>
/to support multicast as a network capability/
> /for NVEs, /
/(omit the following):/
>
> /especially the ones that do not support multicast, /
>
/(end omit)/
> /to map /
/network/
>
> /multicast traffic from VMs (users/applications) to /
>
/an equivalent multicast capability inside the NVE,

(then omit the following:)
/
> /proper Outer Header, /
/(end omit)/
>
> /e.g. figuring out the outer destination address if NVE does not support/
>
/native/
> /multicast (e.g. PIM)./
or IGMP.

> //
> *Sent:* 2017年1月30日14:02
>     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.
>
>     (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.
>
>
>      All we need is to differentiate multicast messages originated
>     from users/applications from the infrastructure multicast at the
>     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.
>
>         /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
>
>             such as Address Resolution Protocol (ARP), Neighbor
>             Discovery (ND), Dynamic Host Configuration Protocol
>                 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
>
>                  
>
>                     /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
>
>                      
>
>                     <[email-masked]>
>                     <mailto:[email-masked]>; Anoop Ghanwani
>                     <[email-masked]>
>                     <mailto:[email-masked]>; Bocci, Matthew
>                     (Nokia - GB) <[email-masked]>
>                     <mailto:[email-masked]>; Dino
>                     Farinacci <[email-masked]>
>                     <mailto:[email-masked]>
>                         /[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),
>                         network protocols (many of them use
>                         multicast). The purpose is to differentiate
>                         multicast originated by network nodes and the
>                         multicast originated by applications. /
>
>                     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.