Re: draft-marques-l3vpn-mcast-edge-00

[Petr Lapukhov <[e-mail]>]

Hi Pedro,

Thanks for an interesting read! However, I have some concerns regarding the problem statement in the document:

>For Clos topologies with multiple stages native multicast support
>within the switching infrastructure is both unnecessary and
>undesirable.  By definition the Clos network has enough bandwidth to
>deliver a packet from any input port to any output port.  Native
>multicast support would however make it such that the network would
>no longer be non-blocking.  Bringing with it the need to devise
>congestion management procedures.

Here they are:

1) Multicast routing over Clos topology could be non-blocking provided that some criteria on Clos topology dimensions are met and multicast distribution tree fan-outs are properly balanced at ingress and middle stages of the Clos fabric. 
2) Congestion management in Clos networks would be necessary in any case, due to statistical multiplexing and possibility of (N -> 1) port traffic flow.
3) The "ingress unicast replication" in VPN forwarder creates the following issues:

3.1) If done at software hypervisor level, it will most likely overload physical uplink(s) on the server: N replicas sent as opposed to 1 in case of native multicast
3.2) If done at hardware switch level (edge of physical Clos topology), it cannot leverage hardware capabilities for multicast replication, and thus could be difficult to implement and will stress the switch internal fabric.

4) If L3 VPN spans WAN for Inter-DC communications, unicast replication makes any WAN multicast optimization impossible, unless there is a "translating" WAN gateway that will forward packets as native multicast.
5) Optimizing overlay multicast distribution tree could be difficult, since underlying network metrics may be hidden from VPN gateways.

I'm reviewing the rest of the document, and hopefully can come up with more comments later.

Best regards,

Petr Lapukhov
Microsoft