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