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 protected]> 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 protected]> 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:[email protected]] On Behalf Of Dino > Farinacci > > Sent: Tuesday, May 24, 2016 12:21 PM > > To: Bocci, Matthew (Nokia - GB) > > Cc: MBONED WG; <[email protected]> > > 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 protected]> wrote: > >> > >> Hi Dino > >> > >> Could you copy NVO3 on your comments, please? > >> > >> Thanks > >> > >> Matthew > >> > >> From: EXT Dino Farinacci <[email protected]> > >> Date: Monday, 16 May 2016 at 23:31 > >> To: Leonard Giuliano <[email protected]> > >> Cc: MBONED WG <[email protected]>, Matthew Bocci < > [email protected]>, Benson Schliesser < > [email protected]> > >> 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 <[email protected]> > 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 ([email protected])- all comments will be greatly appreciated > by NVO3. > >>> > >>> _______________________________________________ > >>> MBONED mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/mboned > >> > >> <PastedGraphic-2.png> > > > > _______________________________________________ > > MBONED mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/mboned > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
