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

Greg Mirsky <gregimirsky@gmail.com> Tue, 05 May 2020 02:15 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 77E223A1362; Mon, 4 May 2020 19:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 y85wKdycXGQa; Mon, 4 May 2020 19:15:08 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 50FD13A0AF7; Mon, 4 May 2020 19:15:08 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id y4so62139ljn.7; Mon, 04 May 2020 19:15:08 -0700 (PDT)
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:content-transfer-encoding; bh=r4JUIkuVEwZLWORgA8n3D2KD8p0AtHikYaP+cW9faEM=; b=fizLJ5SttTwGnPeOYOwwtIEa6bwkZc1hj/f8lLXx49ix0b+iZtB/JNY1vYoFlsvXw7 2LUX23Os3ws9Fm8HnAM4OQ45u+svmQFHhklaV8ayB7u4S9n7ITHgp9ZDdzzfc9S5bkMg OgF10lKVLNb5MMnHsi3IF1Ylzig3FXruIUsh3E3mpWi4oV1VzK6Eh9gT4DWf1CbJomh4 ufAWfJL+6ebadf4B7sv9/aZywBcSWazf5MDD7VUqaYUNxEGAARzkY/25qkQyKJpEoJZr bt9TNEPTbt/wiynXPw78wSQdza+CAls2r3yIDkeYoflHaGHgRP9sa5gUiRxi3C7UXath LzPw==
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:content-transfer-encoding; bh=r4JUIkuVEwZLWORgA8n3D2KD8p0AtHikYaP+cW9faEM=; b=Nm3lB8HKy3flGQm1EoE+ooJBk/Upz8Nl5q+brFnXEZGY5jVqz12umlUEA46TiJCBJH NwhV6O3tw1XciEiVHwW7Aix31WGuaZ4MnEDULt6zg0VC4HhwBFHPAVBT7ung3iwhGqoc PdpN8xZyRfRZyPopMptFTg17ug+MgHP7uNHZjVLqs+1kehgEiGn+mXszJT8QxacVxTKU 3dErpK3v93NFnUePpKHfSiUDLXLb3okuGSeXAkNDzydClz9GUt88mL9ek6VFG709mAVc qymK52Vu01cgCID9YkbEzmriHKbMvcN9YvsgiKaWDJLB0RwN8vMhGSF7W+qgM1JQwF0z ZnsQ==
X-Gm-Message-State: AGi0PubhFHcfyRM0SWivrC4EW452ruiL7sRB/BjhRpQfQIpbFKhfluWS PSYX/QhOn7a+gVLbnffV9a3xQ6uPLgqUnGlckfZxZC2t
X-Google-Smtp-Source: APiQypIga/LdOtkeXcU7z5lOX15Z51MORcomQOJMxwH6VU1Kr8b/msfggGFapff1+b73Nzv+CPUvmQYg9NZje6i2uVE=
X-Received: by 2002:a2e:a37b:: with SMTP id i27mr359146ljn.36.1588644906235; Mon, 04 May 2020 19:15:06 -0700 (PDT)
MIME-Version: 1.0
References: <158863263846.21115.1621770081697874195@ietfa.amsl.com> <CA+RyBmWxv7E+LRejhnbW0CjRYb6VGpdEm5Hq92UYrKoz6qGaBA@mail.gmail.com> <039E96B8-40E5-46B4-A519-434C2AEEAE47@cisco.com>
In-Reply-To: <039E96B8-40E5-46B4-A519-434C2AEEAE47@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 04 May 2020 19:14:54 -0700
Message-ID: <CA+RyBmXcRE1JmOSPcSq6ZFvpuaifssZOSqOPOvEppP7eW6QwXw@mail.gmail.com>
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/auSRJdibevTs0fzGroGgvv9dLPs>
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: Tue, 05 May 2020 02:15:10 -0000

Dear Carlos,
thank you for your thorough review of the updated version, helpful and
constructive suggestions. Please find my answers in-line tagged GIM>>.

Regards,
Greg

On Mon, May 4, 2020 at 5:49 PM Carlos Pignataro (cpignata)
<cpignata@cisco.com> wrote:
>
> Dear Greg,
>
> I have not checked the diff and the new text regarding the Eth MAC and mgmt VNI.
>
> However, these diffs also include a change that you did not mention: TTL / Hop Limit handling, which is one of the comments I had made.
>
> In that context, thank you very much! since this update partially (although largely) addresses my comment.
>
> Still missing:
>
>          TTL or Hop Limit: MUST be set to 255 in accordance with the
>          Generalized TTL Security Mechanism [RFC5881].
>
> CMP: this is an incorrect citation. The GTSM is RFC 5082, not RFC 5881. I recommend adding a Reference to RFC 5082 (as I’d suggested before).
GIM>> Agreed, will change the reference to RFC 5082
>
>    Validation of TTL or Hop Limit of the inner IP packet is performed as
>    described in Section 5 [RFC5881].
>
> CMP: This is an oversimplification. S5 of RFC 5881 explains not only how to validate TTL/HL, but also about demultiplexing tulles in presence of auth and various header fields.
GIM>> I've compared Section 3 of RFC 5082 and Section 5 of RFC 5881
and still believe that for this document the reference to Section 5 of
RFC 5881 is more helpful to a reader and an implementor. Section 5
provides an explicit specification on handling TTL/HC != 255 by a
receiving BFD system. I think that it is important to reference
Section 5, as the handling of TTL/HC != 255 is different depending on
whether the BFD session is in unauthenticated or authenticated mode.
Would you agree?
>
> 9.  Security Considerations
>
> CMP: A discussion on the positive impact of using GTSM would help here.
GIM>> The Security Consideration section in RFC 5881 provides the
excellent text on the benefit of using GTSM in both, unauthenticated
and authenticated, modes. the last para in the Security Consideration
section of this document mentioned the discussion in several RFCs,
including in RFC 5881. Do you think that an additional text about the
use of GTSM in single-hop BFD should be added in this document? Could
you suggest some text?
>
> 11.  Acknowledgments
>
> CMP: Both professional courtesy as well as proper record and provenance tracking suggest keeping an updated Acknowledgements section.
GIM>> My apologies, I've updated the working version accordingly.
>
> Best,
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."
>
> 2020/05/04 午後6:58、Greg Mirsky <gregimirsky@gmail.com>のメール:
>
> Dear All,
> my apologies for holding off this upload. The update is to address a
> set of comments related to the use of destination Ethernet MAC in the
> inner Ethernet frame that encapsulates a BFD control message. A new
> section on the use of the Management VNI has been added and the
> document now considers only the case of using the Management VNI to
> transmitted receive BFD control messages.
> Always welcome your questions and comments.
>
> Regards,
> Greg
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, May 4, 2020 at 3:50 PM
> Subject: New Version Notification for draft-ietf-bfd-vxlan-11.txt
> To: Mallik Mudigonda <mmudigon@cisco.com>, Sudarsan Paragiri
> <sudarsan.225@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, Santosh
> Pallagatti <santosh.pallagatti@gmail.com>, Vengada Prasad Govindan
> <venggovi@cisco.com>
>
>
>
> A new version of I-D, draft-ietf-bfd-vxlan-11.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:           draft-ietf-bfd-vxlan
> Revision:       11
> Title:          BFD for VXLAN
> Document date:  2020-05-04
> Group:          bfd
> Pages:          11
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-bfd-vxlan-11.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-bfd-vxlan-11
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-bfd-vxlan
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-vxlan-11
>
> Abstract:
>   This document describes the use of the Bidirectional Forwarding
>   Detection (BFD) protocol in point-to-point Virtual eXtensible Local
>   Area Network (VXLAN) tunnels used to form 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
>
>