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

From: [email-masked]
Date: Wed, 10 Feb 2016 23:29:08 -0800

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/

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 10 Feb 2016 23:32:45 -0800

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-masked]> wrote:

> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: "Saumya Dikshit (sadikshi)" <[email-masked]>
Date: Fri, 12 Feb 2016 07:42:25 +0000

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).
  *   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
  *   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.

>>>> 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.

>>>>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"

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 11, 2016 at 1:02 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt

Thanks,
Anoop

On Wed, Feb 10, 2016 at 11:29 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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>.

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 12 Feb 2016 00:17:54 -0800

Hi Saumya,

Thanks for the review.  Please see in line.

Anoop

On Thu, Feb 11, 2016 at 11:42 PM, Saumya Dikshit (sadikshi) <
[email-masked]> 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,
>    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
>
>         protocols.”
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"
>
> 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-masked]>
> To: "[email-masked]" <[email-masked]>

---

From: "Saumya Dikshit (sadikshi)" <[email-masked]>
Date: Fri, 12 Feb 2016 11:48:29 +0000

Hi Anoop

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

Regards,
Saumya.

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 12, 2016 at 1:47 PM
To: sadikshi <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt

Hi Saumya,

Anoop

On Thu, Feb 11, 2016 at 11:42 PM, Saumya Dikshit (sadikshi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Anoop

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

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

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"

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.

Thanks,
Anoop

Abstract:

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 12 Feb 2016 12:53:40 -0800

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

<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?

---

From: "Saumya Dikshit (sadikshi)" <[email-masked]>
Date: Sat, 13 Feb 2016 01:44:49 +0000

Hi Anoop

>>>[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 ?

>>>><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.
This as I mentioned will matter only if underlay is capable of carrying the l2 multicast/broadcast.

Thanks
Saumya.

Date: Saturday, February 13, 2016 at 2:23 AM

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

<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?

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 12 Feb 2016 18:06:38 -0800

Hi Saumya,

On Fri, Feb 12, 2016 at 5:44 PM, Saumya Dikshit (sadikshi) <
[email-masked]> 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

> To: sadikshi <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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
> 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.
>