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