Thanks Matt. We will post an update in the next few days.
Anoop On Fri, Jun 3, 2016 at 2:10 AM, Bocci, Matthew (Nokia - GB) < [email protected]> wrote: > 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnvo3-2Dmcast-2Dframework_&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=IiLKJoOYjbD7xFL_yekuC8ZJl0lRw188OqJDBHmhP3g&e= > >> >> >>> > >> >> >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=Q-tQfNBIRBN8E8O9QqzY819WguDm9Jti7NJh1LM6RRA&e= > >> >> >> > >> >> >> <PastedGraphic-2.png> > >> >> > > >> >> > _______________________________________________ > >> >> > MBONED mailing list > >> >> > [email protected] > >> >> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=Q-tQfNBIRBN8E8O9QqzY819WguDm9Jti7NJh1LM6RRA&e= > >> >> > >> >> _______________________________________________ > >> >> nvo3 mailing list > >> >> [email protected] > >> >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=cmcllRtVM8-EUssGIZ3xAsUmY6I-KNHn4MKwt8Hh0BM&e= > >> >> > >> > > >> > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_nvo3&d=CwIFAw&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=wm2yR6LugG6b19ZxThhblIEqcvNlUdKcBSE6w1drd_U&m=ZOJcI-fLm8AgdwkfqNLzC7LvTNfzXAGI_xnjAnpIriI&s=cmcllRtVM8-EUssGIZ3xAsUmY6I-KNHn4MKwt8Hh0BM&e= > > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
