Re: [nvo3] [MBONED] NVO3 Multicast Framework

Hi Dino,

If switch table sizes for IP multicast forwarding are a consideration,
would SSM still be the preferred method?

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