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

[Anoop Ghanwani <[e-mail]>]

Hi Saumya,


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


>
> From: Anoop Ghanwani <[e-mail]>
> Date: Saturday, February 13, 2016 at 2:23 AM
> To: sadikshi <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [nvo3] I-D Action: draft-ietf-nvo3-mcast-framework-02.txt
>
> 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?
>
>
>