Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt

["Saumya Dikshit (sadikshi)" <[e-mail]>]

Hi Anoop

>>>[ag] Yes, for this case, the NVE would be incapable of performing L2 bridging for multicast traffic.
If above is true then kindly ignore rest of it. Can I assume that L2-broadcast also is not possible, as the L2 treatment meted out to both multicast and broadcast is same ?

>>>><Saum> All remote NVE's receiving this packet can either drop or accept based on their capabilities. The two NVE end-points can potentially belong to two different DC-core domains connected over WAN or DCI-fabric and hence can carry different capabilities for supporting multicast. I think this can be a valid case at least.
This as I mentioned will matter only if underlay is capable of carrying the l2 multicast/broadcast.

Thanks
Saumya.

From: Anoop Ghanwani <[e-mail]<mailto:[e-mail]>>
Date: Saturday, February 13, 2016 at 2:23 AM
To: sadikshi <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt

Hi Saumya,

I'm deleting all the things we agree on and that will be fixed.  Please see inline for the one issue that I see need clarification on.

Anoop

>>>> In sectin "3.1<https://tools.ietf.org/html/draft-ietf-nvo3-mcast-framework-02#section-3.1>. No multicast support" " All of the application traffic in the network is unicast

        traffic and the only multicast/broadcast traffic is from ARP/ND
        protocols."

Does this section implies that bridging/switching is not supported on the NVE devices, which will perform broadcast for all L2 packets (either multicast or broadcast) received from connected TS. If not, then case all link-local multicast packets at least can be bridged/switched by the devices in this case.

I'm not sure I understand the comment.  But what the text is saying is that when a broadcast or link local multicast packet is received at the NVE, the NVE either knows what to do with it (i.e. respond if it's ARP/ND) or it will discard the packet.

<Saum> The intention was to check if in this case, NVE is incapable for performing L2-bridging (flooding the packets destined to broadcast and multicast addresses over the fabric core) for application traffic destined to multicast address.

[ag] Yes, for this case, the NVE would be incapable of performing L2 bridging for multicast traffic.

<Saum> Isn't the outer NVO3 encap header driven by the VNI over which the packet arrives and then flooded in the same bridge domain, that is, on all other TS facing ports (in same bridge-domain) and the fabric (core) facing ports.

[ag] I'm having trouble understanding the use case.  If multicast is desired, then one of the other methods must be used.  This section is specifically calling out the case where the NVA has all of the MAC/IP information for the entire overlay and the NVE knows how to either terminate/handle the multicast locally, forward it on as unicast (e.g. DHCP helper), or will discard it.

<Saum> The NVO3 encap, while sending the packet over the overlay, can potentially carry same destination IP/MAC as carried in inner packet.

[ag] If this is a multicast packet, and the underlay doesn't transport mutlicast, how would this work?

<Saum> All remote NVE's receiving this packet can either drop or accept based on their capabilities. The two NVE end-points can potentially belong to two different DC-core domains connected over WAN or DCI-fabric and hence can carry different capabilities for supporting multicast. I think this can be a valid case at least.

[ag] I'm having trouble understanding this part.  Is it possible to provide more info?