Re: [nvo3] [MBONED] NVO3 Multicast Framework

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
>