Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt

Anoop Ghanwani <anoop@alumni.duke.edu> Mon, 04 November 2019 03:32 UTC

Return-Path: <ghanwani@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001BE120871; Sun, 3 Nov 2019 19:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UodKhLqdn0nz; Sun, 3 Nov 2019 19:32:57 -0800 (PST)
Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33B112008D; Sun, 3 Nov 2019 19:32:56 -0800 (PST)
Received: by mail-ua1-f46.google.com with SMTP id n41so4524028uae.2; Sun, 03 Nov 2019 19:32:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BrJE4MAMptUQj1dWhesyTY/fYfPlc5hN4rjwUqRHVSU=; b=sCFG3jezYqzRsO4/CuaQ8LFdhcXr66YDx4MSXIMUffjG/I21f342nViE3hW7CDOCI0 2bcmRsxfUjUU0VO4Ghu5aZ5+MH9zbQBfSJyg4RaqeGSVN+JaY3JS0Ar3s1aLo5kDgZjC ZRb6YUf4hDPKEF+7O2vG2X/RoyJDj+bpkcGdV5lTIgeSaH4igLAgQOm+EbT85cCj6/zY J6b3x+9tTobFCNFlyAgubAJ0mxHAxobA8kB7SYZVyljCUnq2IPVEORmyCQSo4SkPQNIc kakHIhn1dW/lqVvLIuUWqFLaW+SFv5nJWRufsMrrOImubTtPkm6oytXD4vSRUhM8Hhqu 0oTg==
X-Gm-Message-State: APjAAAXmHG/jTwXWfz9HbszsM2w0ph7D7t8NusD5G1UiPttFnABBQaYR BDEA0j7taf6V7VZ5JqJf9QHcm1xEp/9+6T2ICuw=
X-Google-Smtp-Source: APXvYqxHZxncQKr/WKHy0NoRbe5gxHMTGLEHcAoV9Odpw+lfwci/rCg1W2hqv6wm6TmBZT1J3/j7Gx77HsYjWaPY9xs=
X-Received: by 2002:ab0:4e2d:: with SMTP id g45mr8096415uah.29.1572838375671; Sun, 03 Nov 2019 19:32:55 -0800 (PST)
MIME-Version: 1.0
References: <157263030423.31830.4277364795812171214.idtracker@ietfa.amsl.com> <CA+RyBmUn2zSME51_rDW+y-GdWTmOXQiV7BKkRbNwcy12q8ZjxA@mail.gmail.com> <CA+-tSzxvknwYwvh-s-UK_C7YoF04eiFhyBvVxoNmT=52=EUnWw@mail.gmail.com> <CA+RyBmU0FViBV8TrwpLN7hUVMkbp9h4E-N048T4BM7a=7F6MdA@mail.gmail.com>
In-Reply-To: <CA+RyBmU0FViBV8TrwpLN7hUVMkbp9h4E-N048T4BM7a=7F6MdA@mail.gmail.com>
From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Sun, 3 Nov 2019 19:32:44 -0800
Message-ID: <CA+-tSzxNHF0pRq1-7sPz4eWqCVVpf52jDhhqq0iNFu02Eso1pQ@mail.gmail.com>
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, NVO3 <nvo3@ietf.org>, Dinesh Dutt <didutt@gmail.com>, Joel Halpern <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary="000000000000abcd9f05967cf840"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/VNXIsKznS26TSopk9TA5t_YfwjI>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 03:32:59 -0000

Hi Greg,

In the case of the management VNI, are we trying to say that we would allow
any MAC address other than a tenant MAC address?  I would suggest some more
text be added to clarify what is permitted on the management VLAN.
Assuming that we want to allow any MAC other than a tenant MAC, how does
this get enforced?  In other words, what can be done for the network to
protect itself if a sender violates this?

One possible answer is to restrict the MAC address that may be used to one
that is owned by the VTEP or a "agreed on" multicast MAC address.  That
means the receiver only needs to validate for those, and just treats
everything else as data.

Also, for interoperability purposes, it would be best to specify that a
receiver MUST be able to handle any valid MAC address for the BFD session,
while a sender MAY pick any of them.

Thanks,
Anoop

On Sun, Nov 3, 2019 at 6:50 PM Greg Mirsky <gregimirsky@gmail.com>; wrote:

> Hi Anoop,
> thank you for your comments and questions. Please find my notes in-line
> tagged GIM>>.
>
> Regards,
> Greg
>
> On Fri, Nov 1, 2019 at 4:24 PM Anoop Ghanwani <anoop@alumni.duke.edu>;
> wrote:
>
>> Hi Greg,
>>
>> A few comments.
>>
>> The draft has nits, specifically around the way the IPv6 address is
>> written.
>>
>> In section 4:
>>
>> BFD packet MUST be encapsulated ->
>>
>> BFD packets MUST be encapsulated
>>
>> GIM>> Thanks, will do.
>
>>
>> >>>
>>
>> Destination MAC: This MUST NOT be of one of tenant's MAC
>>          addresses.  The destination MAC address MAY be the address
>>          associated with the destination VTEP.  The MAC address MAY be
>>          configured, or it MAY be learned via a control plane protocol.
>>          The details of how the MAC address is obtained are outside the
>>          scope of this document.
>>
>> >>>
>> It looks like we have removed the option of using a well-known IANA
>> assigned MAC.  If so, why is the above a MAY and not a MUST?  What else can
>> it be?  One interpretation is that it can be anything unicast, or
>> multicast, as long as it's not a tenant MAC.  Is that the intent?  If so,
>> it would be better to state it that way.  Also (and this is purely
>> editorial), I think it would be better if the first sentence above were
>> moved to the end of the paragraph.
>>
> GIM>> Yes, you're right, we've removed that option and have removed the
> request to IANA. I also agree that " MAY be the address associated with the
> destination VTEP" is not the right choice of normative language. On the
> other hand, MUST might be too restrictive if BFD session is using the
> Management VNI. Would the following update address your concern:
> OLD TEXT:
>          Destination MAC: This MUST NOT be of one of tenant's MAC
>          addresses.  The destination MAC address MAY be the address
>          associated with the destination VTEP.  The MAC address MAY be
>          configured, or it MAY be learned via a control plane protocol.
>          The details of how the MAC address is obtained are outside the
>          scope of this document.
> NEW TEXT:
>          Destination MAC: If the BFD session is not using the Management
> VNI,
>          the destination MAC address MUST be the address
>          associated with the destination VTEP.  The Destination MAC
>          MUST NOT be one of the tenant's MAC addresses.
>         The MAC address MAY be configured, or it MAY be learned via
>         a control plane protocol. The details of how the MAC address
>         is obtained are outside the scope of this document.
>
>>
>> "The inner Ethernet frame carrying the BFD
>>    Control packet- has the following format:"
>>
>> Extraneous '-' after packet.
>>
> GIM>> Thanks, will do that too.
>
>>
>> Thanks,
>> Anoop
>>
>> On Fri, Nov 1, 2019 at 10:53 AM Greg Mirsky <gregimirsky@gmail.com>;
>> wrote:
>>
>>> Dear All,
>>> the new version includes updates resulting from the discussions of
>>> Joel's comments in the RtrDir review of BFD over VXLAN draft, comments from
>>> Anoop, and Dinesh. On behalf of editors, thank you for your constructive
>>> comments and for sharing your expertise, all much appreciated.
>>> I hope we've addressed all your comments, and the draft can proceed
>>> further.
>>>
>>> Regards,
>>> Greg
>>>
>>> ---------- Forwarded message ---------
>>> From: <internet-drafts@ietf.org>;
>>> Date: Fri, Nov 1, 2019 at 10:45 AM
>>> Subject: New Version Notification for draft-ietf-bfd-vxlan-08.txt
>>> To: Gregory Mirsky <gregimirsky@gmail.com>;, Mallik Mudigonda <
>>> mmudigon@cisco.com>;, Sudarsan Paragiri <sudarsan.225@gmail.com>;,
>>> Vengada Prasad Govindan <venggovi@cisco.com>;, Santosh Pallagatti <
>>> santosh.pallagatti@gmail.com>;
>>>
>>>
>>>
>>> A new version of I-D, draft-ietf-bfd-vxlan-08.txt
>>> has been successfully submitted by Greg Mirsky and posted to the
>>> IETF repository.
>>>
>>> Name:           draft-ietf-bfd-vxlan
>>> Revision:       08
>>> Title:          BFD for VXLAN
>>> Document date:  2019-11-01
>>> Group:          bfd
>>> Pages:          11
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-08.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
>>> Htmlized:       https://tools.ietf.org/html/draft-ietf-bfd-vxlan-08
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-08
>>>
>>> Abstract:
>>>    This document describes the use of the Bidirectional Forwarding
>>>    Detection (BFD) protocol in point-to-point Virtual eXtensible Local
>>>    Area Network (VXLAN) tunnels forming up an overlay network.
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>> The IETF Secretariat
>>>
>>>