Hi Anoop Thanks for clarifying. Please see inline with tag <Saum>
Regards, Saumya. From: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Friday, February 12, 2016 at 1:47 PM To: sadikshi <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt Hi Saumya, Thanks for the review. Please see in line. Anoop On Thu, Feb 11, 2016 at 11:42 PM, Saumya Dikshit (sadikshi) <[email protected]<mailto:[email protected]>> wrote: Hi Anoop I have few queries regarding the following texts from the (kindly bear with if these were taken up earlier or should be posted against different literature): >>>>In the case of ARP/ND, an NVA can be used for distributing the mappings of IP address to MAC address to all NVEs, and the NVEs can respond to ARP messages from the TSs that are attached to it in a way that is similar to proxy-ARP. * NVA here can distribute and ALSO withdraw the IP/MAC mappings, OR the deletion of entries can be delegated to NVE implementation OR based on native ARP/ND functionality (of refreshes and timeouts). Since the NVE got the information from the NVA, it will need to hold on to it until it is removed by the NVA, since the NVA would know if any TS moved around, went away, or timed-out. I can add a clarification statement for that. <Saum> Sure. I think, if these are planted via config (by NVA), hence, can be rendered as “static" and need explicit administrative (NVA) intervention for any further updates/deletion * Does the "mapping distribution" generalizes “both local and remote TS credentials” and "remote NVE’s" as well or connected TS credentials are expected to be learnt the native ARP/ND way It would apply to both local and remote TS credentials. * Proxy-ARP is different in a way wherein the Proxying-router can proxy for destination-hosts which are in different subnets as there may be no default gateway connected to sending-host. In this case local and remote Vteps will map same vni to same-subnet routes, to put them under the same bridging-domain. Indeed proxy-ARP is different and that is why the text says "in a way that is similar to proxy-ARP" implying that the NVE would be responding to ARP messages that aren't for an address the NVE owns. If you think this is inaccurate, we could modify the text by saying some thing like: >>> ...and the NVEs can respond to ARP messages from the TSs that are attached to it by trapping the ARP messages from its local TSs. >>> <Saum> Thanks. The mentioned rephrase should be apt. >>>> 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. 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. The NVO3 encap, while sending the packet over the overlay, can potentially carry same destination IP/MAC as carried in inner packet. 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. >>>>In section >>>>“3.2<https://tools.ietf.org/html/draft-ietf-nvo3-mcast-framework-02#section-3.2>. >>>> Replication at the source NVE" In multi-homing environments, i.e. more than one NVE can reach a specific TS, the NVA would be expected to provide all the NVEs that can reach the given TS. I think the above sentence is incomplete and needs to be rephrased, wherein "the credentials of ALL NVEs which are directly connected to TSs should be provided by NVA to other NVEs in it's authoritative domain" Yes, I can see why the text can appear incomplete. I will modify to the following: >>> In multi-homing environments, i.e. a TS is attached to more than one NVE, the NVA would be expected to provide information to all of the NVEs under its control about the NVEs to which such a TS is attached. >>> <Saum> Thanks for acknowledging. From: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Thursday, February 11, 2016 at 1:02 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt This version addresses the comments received during WGLC. Please let us know if there are any additional comments. Thanks, Anoop On Wed, Feb 10, 2016 at 11:29 PM, <[email protected]<mailto:[email protected]>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Virtualization Overlays of the IETF. Title : A Framework for Multicast in NVO3 Authors : Anoop Ghanwani Linda Dunbar Mike McBride Vinay Bannai Ram Krishnan Filename : draft-ietf-nvo3-mcast-framework-02.txt Pages : 15 Date : 2016-02-10 Abstract: This document discusses a framework of supporting multicast traffic in a network that uses Network Virtualization Overlays over Layer 3 (NVO3). Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nvo3-mcast-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-nvo3-mcast-framework-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-mcast-framework-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
