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) <
sadikshi@cisco.com> 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 <anoop@alumni.duke.edu>
> Date: Thursday, February 11, 2016 at 1:02 PM
> To: "nvo3@ietf.org" <nvo3@ietf.org>
> 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, <internet-drafts@ietf.org> 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
>> nvo3@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>
>