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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 06 May 2020 01:11 UTC

Return-Path: <cpignata@cisco.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 14E913A0CA7; Tue, 5 May 2020 18:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jQVBo4cz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Vy6zzwBj
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 R8B0J9hfFGbW; Tue, 5 May 2020 18:11:30 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663DC3A0CA4; Tue, 5 May 2020 18:11:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47585; q=dns/txt; s=iport; t=1588727490; x=1589937090; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xh+bc1k7QRmvTYq2197+YDHFY1EKCak4mw6nUawwJuE=; b=jQVBo4czhaY0WhAt9/YfEqw6+7Ob0DIvmxvUTi3YqIQrxTT13eBSac2P hYS+rGdUXieMixH7dhHRES1Gy74MMzHovn+9YPt0syRnHz6BDrknqy9bJ RLkAD60X3gPDS8oGOflJZf8tfly4k9Dt+Bm//OiSueyf2oE2MalVR0vNZ o=;
IronPort-PHdr: =?us-ascii?q?9a23=3AmocmNRcwI3nKXxbrReCuN/2xlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAABCDrJe/4kNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBgXYCAQEBAQsBgVMkBSgFblgvKgqEGYNGA41?= =?us-ascii?q?FgQGIeI48gUKBEANUCwEBAQwBASMKAgQBAYREAheBZyQ3Bg4CAwEBCwEBBQE?= =?us-ascii?q?BAQIBBQRthVYMhXEBAQEBAxIRHQEBNQIBDwIBBgIRAwECIQEGAwICAh8RFAk?= =?us-ascii?q?IAgQOBSKDBAGBfk0DLgEOmCeQZwKBOYhhdoEygwABAQWBNgIOQUKCVg0Lgg4?= =?us-ascii?q?JgTgBgmKJYRqBQT+BESccghg1PoIeSQEBAgEBGIEPEgYBAR8hDQkIglQzgi2?= =?us-ascii?q?OQiKCZYYaJIpIjzxKCoJIiBiFLYMSgnWESh2CW4EMh1WEe4xpkW+HfIJGjT6?= =?us-ascii?q?DRAIEAgQFAg4BAQWBPykjgVZwFRohKgGCPgk1EhgNkEIMF4EDAQiCQ4UUhUE?= =?us-ascii?q?BdAI1AgYBBwEBAwl8jwYBJgeBBgGBDwEB?=
X-IronPort-AV: E=Sophos;i="5.73,357,1583193600"; d="scan'208,217";a="747647215"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2020 01:11:28 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0461BStr001599 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2020 01:11:28 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 20:11:28 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 5 May 2020 20:11:28 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 5 May 2020 21:11:27 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=boPtcw+nT7RI4LSCXJ/i6iB03Uksw9RlmsENOHggU05dMDUeNFfYLIyCO2BtVv3uo70ZWvNIyZw8c7iULSSErRrdNO7hgVHRJi3JLiEHHbiaO+U/eZlmuUhEY7oOGScr54bbXZpvkm7zkLC2iN31kkZyCGFKaG8QLOqh90G9K/q0GWEIrJRGwKy3KMs97f8iZnwSzmjmFbKB4hFVSwspgu0JEeYYjFqVjS5eYW+yxWsJSmQtHk6IbdeD4WWLVFwOkM4c+8NbdP6d00dZpHNlEA49qr2Qk9rQt+r0BFKOhI0dQezcBe85mg7CPPWcU/6vWRvSW64Vlz9NYN+PiH1I+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xh+bc1k7QRmvTYq2197+YDHFY1EKCak4mw6nUawwJuE=; b=KSQEebR3HRmmgSLVVaxyrnHE4FMQB6egTODflFNdTOzdDARcd7JvsS6wH5AheFJKDTdUwaRwI1ixCmK92SbVGFiDzyxVxzf4V+m174tqeKH0TCzugcWiN9i9suwCS1sjFZW45aKuCzD3REIY408I29fuUStAWUbFtAhd1SF1qMJOyjmyvTSMnOukPfRDweAqNGlRfDnE+01azd0K3uXohPxVzPFbVU5O/dngnCrmV4qzBE7okmotYmKQc0xJG0On4/OV6qwe4o9Ca5Oj6+Ef8Q838pHUHTd5uySg2ct9lR+5oo413qO/Rd4O7qqehFmvV1bpszUisHQkbFfDLosQ2w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xh+bc1k7QRmvTYq2197+YDHFY1EKCak4mw6nUawwJuE=; b=Vy6zzwBjQ543F9aUa9P8t23GfxVaMa0ElOzoK0Bh41iq4mJXWXByvLeZgly60FXmzQXpnoW7qElQxtBvMMPWHSpAz0NY1WxFWWMUINEvT42MTvH8Oh98hqhF4LkKAWkQHOe95AK/m3Mh+SzxyLVA8ZIUFThBHW8HTCnHOiCQavg=
Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3553.namprd11.prod.outlook.com (2603:10b6:408:81::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Wed, 6 May 2020 01:11:26 +0000
Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96%7]) with mapi id 15.20.2958.029; Wed, 6 May 2020 01:11:26 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: rtg-bfd WG <rtg-bfd@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Subject: Re: New Version Notification for draft-ietf-bfd-vxlan-11.txt
Thread-Topic: New Version Notification for draft-ietf-bfd-vxlan-11.txt
Thread-Index: AQHWImeYzdFcka0XZUWIye+P4kIMEKiYqU+AgAAXzwCAAApdkYABZVKAgAAQ6oA=
Date: Wed, 6 May 2020 01:11:26 +0000
Message-ID: <C6E7C3DF-0E73-47F6-9FD8-655788F982AE@cisco.com>
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>
In-Reply-To: <CA+RyBmVY10AFjLjzKQPp__JvBsuvdM2yZ+rM2C7m0Sir_DuKVw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [108.203.7.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4b481003-cde4-4ea5-5d48-08d7f15a6650
x-ms-traffictypediagnostic: BN8PR11MB3553:
x-microsoft-antispam-prvs: <BN8PR11MB355378601786E0EED2D349A0C7A40@BN8PR11MB3553.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03950F25EC
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VyCGo8dRQd7rLaUch4B8UrhUsEpnzY5rd52ncl2g4EbGAx04VZcyQs/maXjpXjrzUK14COuVmam4QnN3de6UvpzSJ5GzPcMe911/XCVtLso7XDDJuW9aYX9CZBDY/QVlTGygyMO1iP9jIbWnEtsOXU/sW3+P8Dkq9vuE95gRnrJihrizloZojQ4oOcvixoD+EV9qraHm0lX4OmNlCJ6AAlktaE4Rm3nCgSw9zaL7ob1J9Mf5nurdMOgNUuHmaRB5tsNcCpzkSGDCHwouyqMy+Bn/PpFPwtIJGGcvhv5Wb2q+GrP7X146UAs2u61hWX1o66iBtUxJir05QEW4c1Ttej+PKZONBKM7KeGpcH9wlM6OP3PSum0jLTJSoN+G6QsJ3tgXSoX6hU+jfImvG4o2QD0p/qrXY4i/Krns3g4viaIvwM1Nnrn8Att4/95xy2SryrKWAdv4b3gGg1EA5UNFwYLqha8WjZXe5QWZo5u/MFsYllFy+KVjWYKJrTcScIN6OEJqmWBcsXuUCUYbkvuulNM5eonc9QPQFxhbZ9EMlHzipA630KhdAVtbtx+WJuvHtEVzjNwv6Meg6Z8ogEWa2R1iQDKAMx3szOBHekhg5sU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(366004)(39860400002)(136003)(33430700001)(966005)(186003)(54906003)(6506007)(2906002)(86362001)(36756003)(478600001)(66476007)(5660300002)(6486002)(26005)(8936002)(166002)(53546011)(8676002)(33656002)(15650500001)(66556008)(4326008)(316002)(64756008)(71200400001)(6512007)(2616005)(76116006)(33440700001)(6916009)(66446008)(66574014)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: HSIw7IVmFRf3Lq3DZvXH/Zx/Yjft0JaeRLlY97zGaZEZvKSPhRxTZC0zo5BnPEwUd+7GKznQbG6L2oqIJSVZNAp2OVgGWNAg0pu5MliW4LonJCCDqXlvboacVxXijUqkBa22MCQXepxQ74cuko5vhEoH8cfOlMOwig9E50p5Fo3vuSbNidfSyXBRthTe+zaWHVRdyarOed+k51Gm7WnwWHmunw1hdhKjnQI29dIyQF6dr+41XrlYtN3/fohzb1mGoWWyZzSuIHDO6pcaGw+sCBDNybOeDw0wbkHVbYFVLF/5ReK20ChRw5zGCMIe6vxK54GD7WlVeljtPNut+ZjeCrKbPA8Dzl6Uo9KG4tdAxu7/YKS85Am3v/Wkc6ySgDOEKvynuNFebsuGAB7ezkfog30xXvyy1kSbTU4CHFiPThMF/JF5BYZCuvtqbV+svw+4pg24jojLA4Z0P81kaCkt0JJGpJzuLKgB+vKGUgqs3DVW8avU5EGprwj75HjZF3i4DyXxlBjufZdaT4M0s5FSO8yKLj+pq7V0mgoKWmRzbBZUe4gCY/ZHtK8/Q91UooRXeWXQ7wXGcCSZCDuhLNH+Sb//9Xv5CVjViCFBvDsf4NYb66gobiz3DhfmuutwxHain8uOFNoQLYqKUmNUP0rFPGDVuJvLk8MqE0EG2jaB9LFvo5n+tsrSBaPtGPTvwMG1vg1xO9Te/zXl7XbeLsJykYurhoEWSrkMh7W+IYYgCrf30kACAF0TnMgqMjpREBs5Z6YctPOgVVoIGx1WWCCl4NMTx2hxitxQsAbVa8ZuLOY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_C6E7C3DF0E7347F69FD8655788F982AEciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b481003-cde4-4ea5-5d48-08d7f15a6650
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 01:11:26.1038 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tgK+H+urHy8qfuQjYVBImrBikIoPL6b1AHjT8/s56BxU/IbUlwXeZJM9S09Zu65QkEg14S/6UkRe2RAoeEIEZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3553
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/7JRfbW7BKq4-1se1Oc8rDLD1r6Y>
X-Mailman-Approved-At: Wed, 06 May 2020 06:01:12 -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: Wed, 06 May 2020 01:11:35 -0000

Hi, Greg,

Thanks for the quick reply, please see inline.

—
Carlos Pignataro, carlos@cisco.com<mailto: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<mailto:gregimirsky@gmail.com>>のメール:

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].”


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.



  *   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<mailto: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<mailto:gregimirsky@gmail.com>>のメール:

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:mmudigon@cisco.com>>, Sudarsan Paragiri
<sudarsan.225@gmail.com<mailto:sudarsan.225@gmail.com>>, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>, Santosh
Pallagatti <santosh.pallagatti@gmail.com<mailto:santosh.pallagatti@gmail.com>>, Vengada Prasad Govindan
<venggovi@cisco.com<mailto: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<http://tools.ietf.org/>g/>.

The IETF Secretariat