Re: [nvo3] [MBONED] NVO3 Multicast Framework

[Olufemi Komolafe <[e-mail]>]

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?
+ 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?

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)
+ 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?
+ "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?

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


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

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

From: nvo3 [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
Sent: Friday, June 03, 2016 5:14 PM
To: Bocci, Matthew (Nokia - GB) <[e-mail]>
Cc: MBONED WG <[e-mail]>; Truman Boyes <[e-mail]>; <[e-mail]> <[e-mail]>; Williamson, Beau <[e-mail]>; Dino Farinacci <[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
>>wrote:
>> > On May 24, 2016, at 3:37 PM, Anoop Ghanwani <[e-mail]<mailto:[e-mail]>>
>>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
>><[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
>>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
>><[e-mail]<mailto:[e-mail]>> 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
>><[e-mail]<mailto:[e-mail]>> 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:[phone]>
>> >> > Mobile:   [phone]<tel:[phone]>
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: MBONED [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Dino
>>Farinacci
>> >> > Sent: Tuesday, May 24, 2016 12:21 PM
>> >> > To: Bocci, Matthew (Nokia - GB)
>> >> > Cc: MBONED WG; <[e-mail]<mailto:[e-mail]>>
>> >> > 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)
>><[e-mail]<mailto:[e-mail]>> wrote:
>> >> >>
>> >> >> Hi Dino
>> >> >>
>> >> >> Could you copy NVO3 on your comments, please?
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Matthew
>> >> >>
>> >> >> From: EXT Dino Farinacci <[e-mail]<mailto:[e-mail]>>
>> >> >> Date: Monday, 16 May 2016 at 23:31
>> >> >> To: Leonard Giuliano <[e-mail]<mailto:[e-mail]>>
>> >> >> Cc: MBONED WG <[e-mail]<mailto:[e-mail]>>, Matthew Bocci
>><[e-mail]<mailto:[e-mail]>>, Benson Schliesser
>><[e-mail]<mailto:[e-mail]>>
>> >> >> Subject: Re: [MBONED] NVO3 Multicast Framework
>> >> >>
>> >> >> I just have one minor comment. Regarding the second paragraph:
>> >> >>
>> >> >> <PastedGraphic-2.png>
>> >> >>
>> >> >> 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
>><[e-mail]<mailto:[e-mail]>> 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 ([e-mail]<mailto:[e-mail]>)- all comments will be greatly
>>appreciated by NVO3.
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> MBONED mailing list
>> >> >>> [e-mail]<mailto:[e-mail]>
>> >> >>> 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=
>> >> >>
>> >> >> <PastedGraphic-2.png>
>> >> >
>> >> > _______________________________________________
>> >> > MBONED mailing list
>> >> > [e-mail]<mailto:[e-mail]>
>> >> > 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
>> >> [e-mail]<mailto:[e-mail]>
>> >> 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
>> [e-mail]<mailto:[e-mail]>
>> 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=
>