Re: [nvo3] [MBONED] NVO3 Multicast Framework

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" <farinacci@gmail.com> 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 <farinacci@gmail.com>
>>wrote:
>> > On May 24, 2016, at 3:37 PM, Anoop Ghanwani <anoop@alumni.duke.edu>
>>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
>><farinacci@gmail.com> 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 <anoop@alumni.duke.edu>
>>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
>><farinacci@gmail.com> 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
>><Beau.Williamson@T-Mobile.com> 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
>> >> > Mobile:   972.679.4334
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: MBONED [mailto:mboned-bounces@ietf.org] On Behalf Of Dino
>>Farinacci
>> >> > Sent: Tuesday, May 24, 2016 12:21 PM
>> >> > To: Bocci, Matthew (Nokia - GB)
>> >> > Cc: MBONED WG; <nvo3@ietf.org>
>> >> > 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)
>><matthew.bocci@nokia.com> wrote:
>> >> >>
>> >> >> Hi Dino
>> >> >>
>> >> >> Could you copy NVO3 on your comments, please?
>> >> >>
>> >> >> Thanks
>> >> >>
>> >> >> Matthew
>> >> >>
>> >> >> From: EXT Dino Farinacci <farinacci@gmail.com>
>> >> >> Date: Monday, 16 May 2016 at 23:31
>> >> >> To: Leonard Giuliano <lenny@juniper.net>
>> >> >> Cc: MBONED WG <mboned@ietf.org>, Matthew Bocci
>><matthew.bocci@alcatel-lucent.com>, Benson Schliesser
>><bensons@queuefull.net>
>> >> >> 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
>><lenny@juniper.net> wrote:
>> >> >>>
>> >> >>> MBONED,
>> >> >>>
>> >> >>> The following draft recently went through WG last call in the
>>NVO3 working group:
>> >> >>>
>> >> >>> https://datatracker.ietf.org/doc/draft-ietf-nvo3-mcast-framework/
>> >> >>>
>> >> >>> 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 (nvo3@ietf.org)- all comments will be greatly
>>appreciated by NVO3.
>> >> >>>
>> >> >>> _______________________________________________
>> >> >>> MBONED mailing list
>> >> >>> MBONED@ietf.org
>> >> >>> https://www.ietf.org/mailman/listinfo/mboned
>> >> >>
>> >> >> <PastedGraphic-2.png>
>> >> >
>> >> > _______________________________________________
>> >> > MBONED mailing list
>> >> > MBONED@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/mboned
>> >>
>> >> _______________________________________________
>> >> nvo3 mailing list
>> >> nvo3@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/nvo3
>> >>
>> >
>> 
>> _______________________________________________
>> nvo3 mailing list
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>