Re: [nvo3] [MBONED] NVO3 Multicast Framework

[Anoop Ghanwani <[e-mail]>]

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) <
[e-mail]> 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" <[e-mail]> 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 <[e-mail]>
> >>wrote:
> >> > On May 24, 2016, at 3:37 PM, Anoop Ghanwani <[e-mail]>
> >>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
> >><[e-mail]> 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 <[e-mail]>
> >>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
> >><[e-mail]> 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
> >><[e-mail]> 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:   [phone]
> >> >> >
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: MBONED [mailto:[e-mail]] On Behalf Of Dino
> >>Farinacci
> >> >> > Sent: Tuesday, May 24, 2016 12:21 PM
> >> >> > To: Bocci, Matthew (Nokia - GB)
> >> >> > Cc: MBONED WG; <[e-mail]>
> >> >> > 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)
> >><[e-mail]> wrote:
> >> >> >>
> >> >> >> Hi Dino
> >> >> >>
> >> >> >> Could you copy NVO3 on your comments, please?
> >> >> >>
> >> >> >> Thanks
> >> >> >>
> >> >> >> Matthew
> >> >> >>
> >> >> >> From: EXT Dino Farinacci <[e-mail]>
> >> >> >> Date: Monday, 16 May 2016 at 23:31
> >> >> >> To: Leonard Giuliano <[e-mail]>
> >> >> >> Cc: MBONED WG <[e-mail]>, Matthew Bocci
> >><[e-mail]>, Benson Schliesser
> >><[e-mail]>
> >> >> >> 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
> >><[e-mail]> 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 ([e-mail])- all comments will be greatly
> >>appreciated by NVO3.
> >> >> >>>
> >> >> >>> _______________________________________________
> >> >> >>> MBONED mailing list
> >> >> >>> [e-mail]
> >> >> >>>
> 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
> >> >> > [e-mail]
> >> >> >
> 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
> >> >> [e-mail]
> >> >>
> 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
> >> [e-mail]
> >>
> 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=
> >
>
>