Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt

Hi Anoop

Thanks for clarifying.  Please see inline with tag <Saum>

Regards,
Saumya.

From: Anoop Ghanwani <anoop@alumni.duke.edu<mailto:anoop@alumni.duke.edu>>
Date: Friday, February 12, 2016 at 1:47 PM
To: sadikshi <sadikshi@cisco.com<mailto:sadikshi@cisco.com>>
Cc: "nvo3@ietf.org<mailto:nvo3@ietf.org>" <nvo3@ietf.org<mailto:nvo3@ietf.org>>
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) <sadikshi@cisco.com<mailto: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.
<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 <anoop@alumni.duke.edu<mailto:anoop@alumni.duke.edu>>
Date: Thursday, February 11, 2016 at 1:02 PM
To: "nvo3@ietf.org<mailto:nvo3@ietf.org>" <nvo3@ietf.org<mailto: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<mailto: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<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nvo3 mailing list
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3