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

[Dino Farinacci <[e-mail]>]

> 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
>