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

Greg Mirsky <gregimirsky@gmail.com> Thu, 07 May 2020 20:20 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 750493A0D48; Thu, 7 May 2020 13:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.696
X-Spam-Level:
X-Spam-Status: No, score=-0.696 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, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 KGmme2Z3Sy8J; Thu, 7 May 2020 13:20:16 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 9C96E3A0D4D; Thu, 7 May 2020 13:20:15 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id d25so919138lfi.11; Thu, 07 May 2020 13:20:15 -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; bh=8Qt5zV52aFyF134D/sbyvGjv8MI4i0cuuPEytliK2II=; b=Kr0v0Mhkm1ObTnsqR2TTfc0RJ3DUyEDtJzNu2MmaGvaPP8/4sd80GSMRApT4gdvUBz /V8syM2w7s8PX8OadAk3ZZxIv4x2CkKMUbSxqpOu3idXrqBvtnDIz1F2rvtf2+60K2XV ArhVB+rIz3VwwT8eatqo0MduB+6Tu6mNlawO9slL1B3HI2N/nYgrjlqpmJ3QajCdIGK6 EXrdVWZHFVu5dAmBqtPKHthEghVj+C0Gi0u7Ih+XlqkKP8jdY8b2PfkC+IzmqKspaEOl oNO6B/ImMBfZiHTnpx18wsUb+gtSSeeRolaZnyBWqFjOknmDVO91BblQA9T7Gz30EW7m nkxQ==
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=8Qt5zV52aFyF134D/sbyvGjv8MI4i0cuuPEytliK2II=; b=VqTi88sBskjes28WHolBhgimX3tvg011I5I//X59TSmpml2wKTLn0MfUS/AmbL9oOe 1qtQAC8kZKkBy7xjjkwP++sgmc/VHSC77j1ZviTuxNAP9na4KSVCS0yqI3TR3/6YgNld Swk9OmzlVDY3C/tA6KmADN7fYEagdwNgekjMxfBh0XcE6KBhbQMeJ2zLMQ/V5AeLklO6 q9EoEJMMlnya3j6exx+gMdP9o6LaSDelJLwgkKtWckQyU/3HUYYuXUzwitXeEaeOSAMj UlMPf6H8QmdnEcpCoOMh/eoKZ2ZwfQRzeMxRFXYXnyrdRQ38AOw46sjdOjv/EPh2UtG8 OweQ==
X-Gm-Message-State: AGi0PuYRU83l9fWZITslMSvU+mEMpdcPfHsDNtEVJQFAAXE1KFTpo9mF +XJDlnNS5wo+kliRG+j0yFbe2JKgpFMjlrWkNEg=
X-Google-Smtp-Source: APiQypKTOy9fe9CsRH93aiecBRq+iof7Zd0tGVETYsOvT5wsF613/sMq0evQd36KePGXs9qxiVz+uHvJ95a/reL38H4=
X-Received: by 2002:a05:6512:695:: with SMTP id t21mr10060918lfe.158.1588882813581; Thu, 07 May 2020 13:20:13 -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> <CA+RyBmXcRE1JmOSPcSq6ZFvpuaifssZOSqOPOvEppP7eW6QwXw@mail.gmail.com> <2BB0F1AC-3F6F-45CA-BF7E-93335D7C5106@cisco.com> <CA+RyBmVY10AFjLjzKQPp__JvBsuvdM2yZ+rM2C7m0Sir_DuKVw@mail.gmail.com> <C6E7C3DF-0E73-47F6-9FD8-655788F982AE@cisco.com>
In-Reply-To: <C6E7C3DF-0E73-47F6-9FD8-655788F982AE@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 7 May 2020 13:20:02 -0700
Message-ID: <CA+RyBmWeXgrCo+CibVkWdKf1_r6f2JfKR=8cUAtmgHM-YUYQ8A@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: multipart/mixed; boundary="000000000000b1a03405a5149b48"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/IlznQYhbzpS5_EILdxpKi5lQd6g>
X-Mailman-Approved-At: Thu, 07 May 2020 13:56:56 -0700
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: Thu, 07 May 2020 20:20:23 -0000

Dear Carlos,
thank you for the suggestions. Attached are the working version and the
diff. My notes in-line below under GIM>> tag.

Regards,
Greg

On Tue, May 5, 2020 at 6:11 PM Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Hi, Greg,
>
> Thanks for the quick reply, please see inline.
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
> 2020/05/05 午後8:10、Greg Mirsky <gregimirsky@gmail.com>のメールt;のメール:
>
> Dear Carlos,
> I'll do top-posting to highlight the remaining points of discussion.
> Please correct me if my understanding is not correct:
>
>    - the reference to Section 5 RFC 5881 in the following sentence:
>
>    Validation of TTL or Hop Limit of the inner IP packet is performed as
> described in Section 5 [RFC5881].
>
>
>
> “Validation of TTL / Hop Limit of the inner IP packet, as long as the
> related considerations for BFD control packet demultiplexing and
> authentication, is performed as described in Section 5 [RFC5881].”
>
GIM>> Thank you, accepted.

>
>
> I expect that a reader of BFD over VXLAN document is able to find the
> relevant information in Section 5 of RFC 5881. Do you think that the
> reference to Section 5 RFC 5881 might be confusing to the reader? Would you
> suggest to use another reference without replicating the text from RFC 5881
> in this document?
>
>
>    - Security Considerations section
>
> You've suggested:
> Currently the security considerations does not say “security
> considerations of 5881 apply here”, nor does it say “the ttl/hl protection
> isn’t useful in foobar “
>
> I think it should say both.
>
> This draft discusses the use of BFD over VXLAN. Do you mean that 'foobar'
> is BFD over VXLAN? Since security considerations in RFC 7348 are applicable
> in this draft, I don't think that GTSM is not useful in the case of BFD
> over VXLAN. Or I misinterpreted 'foobar'? Could you please clarify it?
>
>  Would the following update is acceptable:
> OLD TEXT:
>    Other than requiring control of the number of BFD sessions between
>    the same pair of VTEPs, this specification does not raise any
>    additional security issues beyond those discussed in [RFC5880],
>    [RFC5881], and [RFC7348].
> NEW TEXT:
>    Other than requiring control of the number of BFD sessions between
>    the same pair of VTEPs, this specification does not raise any
>    additional security issues beyond those discussed in [RFC5880],
>    [RFC5881], and [RFC7348] that apply to this document.
>
>
> I am sorry, as I read this I do not fully understand the first part. What
> is to “require _control_ of the number of sessions”?
>
> I would split that long sentence into two.
>
GIM>> I agree, the sentence is too convoluted. Would removing it altogether
and adding the following at the top of the section make it clearer:
   Security issues discussed in [RFC5880], [RFC5881], and [RFC7348]
   apply to this document.

>
>
>
>    - Acknowledgments
>
> Thank you. I'll thoroughly look through all the relevant discussion
> threads in the mail archive.
>
>
> Sounds good.
>
> Thanks,
>
> Carlos.
>
>
>
> Regards,
> Greg
>
>
> On Mon, May 4, 2020 at 7:52 PM Carlos Pignataro (cpignata) <
> cpignata@cisco.com> wrote:
>
>> Dear Greg,
>>
>> As I said, I did *not* review the updated version (or the changes)
>> thoroughly (or superficially for that matter)
>>
>> Please do not count this as a review of the new revision, and instead
>> consider the context that I laid for my reply.
>>
>> I only checked the changes for one comment I had made.
>>
>> Please see inline.
>>
>> Thumb typed by Carlos Pignataro.
>> Excuze typofraphicak errows
>>
>> 2020/05/04 午後10:15、Greg Mirsky <gregimirsky@gmail.com>のメールt;のメール:
>>
>> Dear Carlos,
>> thank you for your thorough review of the updated version,
>>
>>
>> I didn’t. This is what I had said:
>>
>> I have not checked the diff and the new text regarding the Eth MAC and
>> mgmt VNI.
>>
>> Assuming that was clear...
>>
>> helpful and
>> constructive suggestions.
>>
>>
>> Thanks. That was the intent, but only for the TTL/HL change.
>>
>> 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
>>
>>
>> Thanks.
>>
>>
>>   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.
>>
>>
>> Yes, I agree with this. I did not say “change this reference to 5082” —
>> that was the previous comment on a different passage.
>>
>> 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?
>>
>>
>> Yes, but that’s orthogonal to my comment.
>>
>> My point is that the relevant text from section 5 does more than simply “
>> Validation of TTL or Hop Limit ”
>>
>>
>> 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?
>>
>>
>> Yes, that’s why I made the comment!
>>
>> Currently the security considerations does not say “security
>> considerations of 5881 apply here”, nor does it say “the ttl/hl protection
>> isn’t useful in foobar “
>>
>> I think it should say both.
>>
>> 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.
>>
>>
>> To be clear, I’m not talking about me but about others who invested more
>> time helping with this doc, like Joel and others. It would be useful to go
>> through the list archive (to also ensure all comments are captured, since
>> they were made SO long ago)
>>
>> Best,
>>
>> Carlos.
>>
>>
>> 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>のメールt;のメール:
>>
>>
>> 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>om>, Sudarsan Paragiri
>>
>> <sudarsan.225@gmail.com>om>, Greg Mirsky <gregimirsky@gmail.com>om>, Santosh
>>
>> Pallagatti <santosh.pallagatti@gmail.com>om>, 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
>>
>>
>>
>>
>