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]> 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. > > - 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. >>> > >>>> 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. > > >>>>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. >>> > > > > From: Anoop Ghanwani <[email protected]> > Date: Thursday, February 11, 2016 at 1:02 PM > To: "[email protected]" <[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]> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
