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
