> 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
>  
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to