This email closes the extended review of draft-ietf-nvo3-mcast-framework. Thanks for the review and comments on this draft. I saw one suggestion for specific modification to the draft.
Please can the authors make these updates and I¹mm continue with the document shepherd process. Regards Matthew On 25/05/2016, 00:08, "Dino Farinacci" <[email protected]> wrote: > >> 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
