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
