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

Greg Mirsky <gregimirsky@gmail.com> Mon, 04 November 2019 02:50 UTC

Return-Path: <gregimirsky@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 CC1411208B7; Sun, 3 Nov 2019 18:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8pD-_E9sgkdA; Sun, 3 Nov 2019 18:50:27 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 337CB1208E7; Sun, 3 Nov 2019 18:50:27 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id j5so11027917lfh.10; Sun, 03 Nov 2019 18:50:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=biyyDYCCRFNPfOlj02aoCHy3Pgq7W62SAjpx8Rfu8u0=; b=TlcxcppnLVbdj3kbE6idrCpRIwiv0EngDGXYlNiRqLH36Pdkqg+rAUVf44NmMkxyox +DTAbWbG+zXLwPC0Boj98K4KQhNuTpAsr8oZiS3V1iuq4dx7x71vU6bgcWOYTk3tzxYv 2DwfuP9/z7Kes/JYMxlX5dft3DnIAKrXEoPEbvaQ6Cpua+gbtlKBc70UALuWYWiubpue mH4++3ktqEdWpCBUEk7wic+Mzo37+CNWMHRS4BEzpJn+ff+dK4Yc3XchUejZjmAUAc7a 7qfspVDDfqn+Ra31Z7Gt7odbWbozR5qNEuXRyDGHGbjtVgklL/DM+dlIElDgyKXfAfQ3 dMaA==
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=biyyDYCCRFNPfOlj02aoCHy3Pgq7W62SAjpx8Rfu8u0=; b=GfE8sMbDkt6POqA5zQjzwJizM1S6h2eO0ZmNZERVLZyCHiYW3eSzFoZdLpEQtNV5g0 k5xQtO0YPJXzxLrCDr99PVAXVNES5aDOBNlsoRKRy7hHwGw7sz4tkqAvndUvoL9VQK/3 EP9Ro8m7pVa/RBcIB85iQGJwT19IXi77YdIGWr6Vb26E3m2pUjGKZI9Pao/HGCmkMotH duvNwXFupnZVwlpfYX/rziv9YTfjd5xRqjVM6hVkIkvNe0CcOe1IIEHdR6TYf099Khii Tfosho84quvIWzDD+H/ESJN9WUTCdoXTYPzQ09UJQmy5zTf4YS0MSHsOt7TXIXBUKFjO eQ7A==
X-Gm-Message-State: APjAAAWSrIn2ea41WOyYvgNlrENIoRYkvfHx/312/Cje1WZX8cNxZMcf PZah4GZbO/bpjuNDt98DfJGkaB/7Dy/bkD+Plh0=
X-Google-Smtp-Source: APXvYqyiFtZujGXwSKSuJDLwPlRTmHkjbE8MiH3d4fEAW5lU4XgL80wd/LAAymXYwp4JXMo2lycXkQrjWH/qNwYhSWg=
X-Received: by 2002:ac2:5c05:: with SMTP id r5mr13824045lfp.72.1572835825280; Sun, 03 Nov 2019 18:50:25 -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>
In-Reply-To: <CA+-tSzxvknwYwvh-s-UK_C7YoF04eiFhyBvVxoNmT=52=EUnWw@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 03 Nov 2019 18:50:13 -0800
Message-ID: <CA+RyBmU0FViBV8TrwpLN7hUVMkbp9h4E-N048T4BM7a=7F6MdA@mail.gmail.com>
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-08.txt
To: Anoop Ghanwani <anoop@alumni.duke.edu>
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="000000000000a7ea8905967c6054"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/m-stuHp7Ol4oU79cRFn92g3ZTVI>
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 02:50:39 -0000

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