Hi Saumya,
On Fri, Feb 12, 2016 at 5:44 PM, Saumya Dikshit (sadikshi) < [email protected]> wrote: > > > *>>>[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 ? > [ag] Yes, in this case, L2 broadcast is not possible as well. Thanks again for your thorough review. Anoop > > From: Anoop Ghanwani <[email protected]> > Date: Saturday, February 13, 2016 at 2:23 AM > To: sadikshi <[email protected]> > Cc: "[email protected]" <[email protected]> > 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? > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
