> We could do an OpenDaylight implementation of Signaling Free Mcast over the > OVS. Set the flow table to catch PIM and IGMP as packetIn from OVS to the ODL > controller. That would easily translate to mapping (NVA) API and wire the OVS > to mcast tree using flows. OVS + ODL will form the NVE.
Sounds good. I have an implementation of lisp-signal-free-multicast if you want to do interoperability testing with. Dino > There may be interest as people look for at least easy tap solution > mapping-flow that can be enhanced to support app-mcast. > > --szb > > On Aug 31, 2014, at 9:49 AM, "Dino Farinacci" <[email protected]> wrote: > >> Dino, >>> >>> At Toronto NV03 session, you suggested that >>> draft-ghanwani-nvo3-app-mcast-framework can use LISP’s signal free >>> multicast scheme. >>> After studying the draft-farinacci-lisp-signal-free-multicast-00, I agree >>> that the proposed scheme can definitely solve the problem of application >>> initiated multicast in environment where underlay network don’t support any >>> IP multicast protocol. >> >> The design allows for either unicast or multicast RLOCs to be registered to >> the mapping system. So LISP signal-free multicast can be used when the >> underlay supports multicast. >> >>> But there are some issues of using the LISP’s signal free multicast >>> mechanism in Data Centers when NVEs, especially the server based hypervisor >>> virtual switches, don’t ( or can’t) support the “General Receiver-site >>> procedure” documented in the >>> “draft-farinacci-list-signal-free-multicast-00”. The general >> >> Whatever the application is going to use to tell the network what multicast >> groups are joined can be used as well. >> >>> receiver-site procedure requires egress edge (i.e. egress NVE) to terminate >>> IGMP or PIM messages. But many NVEs (server based virtual switches) don’t >>> terminate IGMP nor PIM. >> >> Well if the virtual switch supports LISP, then the app directly tells the >> xTR which groups it is joining. >> >> And if the LISP xTR is one-hop northbound from the virtual switch, you can >> bet the virtual switch does IGMP snooping. >> >>> Therefore, NVO3 needs a simpler scheme for “Receiver NVEs”. >>> draft-ghanwani-nvo3-app-mcast-framework-00 suggests all IGMP messages are >>> sent to “multicast server”. >> >> That is not simpler - that adds a new component to the network. >> >> And if you IGMP to a server why is that different than registering to a >> map-server. >> >> But since there is no precise serial spec'ed on how the NVE-to-NVA protocol >> works no one can tell what can be leveraged for multicast. >> >> LISP-signal-free-multicast works because the LISP mapping system protocols >> are well specified, implemented, and deployed. >> >>> Or “Multicast server” can fake “IGMP query” to all the NVEs, which >>> forwarded down to applications. The reply (IGMP report) can be >>> automatically sent back to “multicast server” without NVE doing anything >>> extra. >>> >>> What do you think? >> >> You want multicast routers to attach to the overlay. They don't send IGMP >> packets to each other. >> >> IGMP is a host-to-router protocol and has been abused to be a host-to-switch >> protocol. Let's stop the abuse. :-) >> >> Dino >> >>> >>> >>> Linda >>> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
