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

[Anoop Ghanwani <[e-mail]>]

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

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

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