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 <[email protected]> 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 <[email protected]> > 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 <[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] <[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
