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

From: Linda Dunbar <[email-masked]>
Date: Sun, 31 Aug 2014 13:21:57 +0000

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.

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

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

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?

Linda

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 31 Aug 2014 09:49:37 -0700

> 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

---

From: Sharon Barkai <[email-masked]>
Date: Mon, 1 Sep 2014 01:30:10 +0000

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.

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-masked]<mailto:[email-masked]>> wrote:

Dino,

 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

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.

What do you think?

Dino

Linda

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 31 Aug 2014 18:43:57 -0700

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

Sounds good. I have an implementation of lisp-signal-free-multicast if you want to do interoperability testing with. 

Dino

> On Aug 31, 2014, at 9:49 AM, "Dino Farinacci" <[email-masked]> wrote:
> 
>> Dino,
>>>  
>> [email-masked]