> 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 <[email protected]> wrote: > > On May 24, 2016, at 3:37 PM, Anoop Ghanwani <[email protected]> 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 <[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]> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
