Re: [nvo3] [lisp] Questions on using LISP's signal free multicast for draft-ghanwani-nvo3-app-mcast-framework

> 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" <farinacci@gmail.com> 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
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp