From nobody Wed Dec 2 13:31:53 2020 Return-Path: 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 A35D83A1754; Wed, 2 Dec 2020 13:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0pLJAGoBPkHS; Wed, 2 Dec 2020 13:31:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E6D713A1664; Wed, 2 Dec 2020 13:29:25 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1B1831E355; Wed, 2 Dec 2020 16:46:11 -0500 (EST) Date: Wed, 2 Dec 2020 16:46:10 -0500 From: Jeffrey Haas To: "Reshad Rahman (rrahman)" Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-secure-sequence-numbers@ietf.org" , "'reshad@yahoo. com'" Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers Message-ID: <20201202214610.GC29769@pfrc.org> References: <043D4BDD-5024-4F99-83E8-1E3ECD6F4E44@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <043D4BDD-5024-4F99-83E8-1E3ECD6F4E44@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 21:31:52 -0000 It's been some time since I've reviewed the entire document, so this is almost fresh for me as well. :-) My comments largely follow Reshad's: - I don't know what [S] is intended to be. - The chains in the diagrams aren't necessarily clear. I think they're intended to represent that you can work forward and backward through the mechanism, but I don't think they're helping with clarity. My memory of our prior conversations were that we'd discussed a hash that had the properties we wanted here. But that hash isn't in the document. Alan, could you remind us of the example you gave? I think my biggest procedural issue is discovering the initial sequence number. Since the Receiver is always receiving the output of the hash itself, how does it discover the initial sequence number? If this is a hash rather than a symmetric operation, we don't have the property that hash(s,k) = H1; hash (H1,k) = s So, I think we need some clarity for this sentence: Note: The first sequence number can be obtained using the same logic as used in determining Local Discriminator value for the session or by using a random number. -- Jeff On Tue, Nov 24, 2020 at 12:09:53AM +0000, Reshad Rahman (rrahman) wrote: > Hi, > > Authors, thank you for addressing my comments in rev-06. > > I believe there’s some room for clarification in Section 3. > > Comments: > > 1. [0] states monotonically increasing sequence number but the sequence number is actually in [S] > > [A] states Authentication but the authentication format contains the sequence #. So this is supposed to be the hash of the BFD packet as described in 4.4 of RFC5880. > > > > As currently defined in BFD [RFC5880], a BFD packet with > authentication will undergo the following steps, where: > > [O]: original RFC 5880 packet with monotonically increasing sequence > number > > [S]: pseudo random sequence number > > [A]: Authentication > > Sender Receiver > > [O] [S] [A] ------------- [A] [S] [O] > > > 1. The text below states that “mechanism of provisioning such a key is outside the scope of this document”. But further down H1 and H2 are both calculated with key ‘k’. So is the key to calculate the sequence number hash the same as the key to calculate the hash for the packet (as per section 4.4 of RFC5880)? And if they are the same and the attacker has it, can’t the attacker fudge the sequence number hash also? I think I could be missing something here. > > This document proposes that for enhanced security in sequence number > encoding, the sender would identify a hash algorithm (symmetric) that > would create a 32 bit hash. The hashing key is provisioned securely > on the sender and receiver of the BFD session. The mechanism of > provisioning such a key is outside the scope of this document. > Instead of using the sequence number, the sender encodes the sequence > number with the hashing key to produce a hash. > > > 1. When the receiver does the reverse hash operation to extract the sequence number, > previously received ‘s’ is not enough as per previous text which mentions tolerate dropped frames. > > > > k: hashing key > > > > s: sequence number > > > > O: original RFC 5880 packet with monotonically increasing sequence > > number > > > > 1. What is meant by “remainder of packet”? > > > > R: remainder of packet > > > > H1: hash of s > > > > H2: hash of entire packet > > > > A: H2 + insertion in packet > > > > hash(s, k) = H1 > > > > hash((H1 + R), k) = H2 > > > > hash'((Packet - H2), k) == H2 ? Good packet : bad packet > > > > hash'(H1, k) > previously received s ? Good sequence number : bad > > sequence number > > > > Sender Receiver > > > > [O] [H1] [A] -------- [A] [H1] [O] > > > > The above diagram describes how the sender encodes and receiver > > decodes the sequence number. The sender starts by taking the > > monotonically increasing sequence number and hashing it. It replaces > > the sequence number with the hash. It then calculates the hash for > > the entire packet and appends the hash value to the end of the > > packet, before transmitting it. > > > > 1. s/retrieve s/retrieve ‘s’/ and s/monotically/monotonically/ > > > > The receiver hashes the entire packet without H2, and compares the > > hash value with the received hash (H2). If the hash values are > > equal, it is a good packet, else it is a bad packet. It then > > calculates the hash on the received sequence number to retreive s. > > If it is greater than the previously received monotically increasing > > sequence number, then the receiver knows it's a valid sequence > > number. > > Regards, > Reshad. > > From: "Reshad Rahman (rrahman)" > Date: Sunday, June 14, 2020 at 2:50 PM > To: "rtg-bfd@ietf.org" , "draft-ietf-bfd-secure-sequence-numbers@ietf.org" > Subject: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers > > Authors, WG, > > The writeup is available at https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/shepherdwriteup/ > > For convenience I’ve copied the comments on the document below. > > Regards, > Reshad. > > > This document updates RFC5880. This is missing from the title page header. > > > > Abstract > > s/a security enhancements/a security enhancement/ > > Suggestion: “This document describes a security enhancement for the sequence number used in BFD control packets”. > > > > Requirements Language > > Please put this later in the document, e.g. after introduction. Add RFC8174, and add it as normative reference. > > > > Introduction > > Don’t use Authentication TLV, instead use “Authentication Section”. E.g. > > s/in BFD authentication TLVs/in the BFD authentication section/ > > > > > > s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in BFD control packets/ > > I’m not sure I understood the last sentence starting with “Further security may be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the sequence numbers rolls over, it’s reset to a pseudo-random number? > > > > Section 2 > > Rename to “Theory of operation” > > Suggest splitting the 1st sentence, e.g. > > Instead of inserting a monotonically, sometimes occasionally, increasing > > sequence number in BFD control packets, a hash is inserted instead. > > The hash is computed, using a shared key, on the sequence number. That > > computed hash is then inserted into the sequence number field of the > > packet. > > > > In the following sentence, the part “used in computing an authenticated packet” is referring to computing the SHA1/MD5 hash/digest for the packet? That sentence should be clarified then. > > In > > case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication], > > the sequence number used in computing an authenticated packet would > > be this new computed hash. > > > > Also, when referring to the optimization draft, better to use e.g. “optimized BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 BFD authentication. > > > > s/psuedo/pseudo/ > > s/ scope of this draft/ scope of this document/ > > s/seuquence/sequence/ > > > > Not clear to me what the following means. > > Note: The first sequence number can > > be obtained using the same logic as the My Discriminator value. > > > > The diagram reads well for regular authentication. For secure sequence number, I think the diagram would gain clarity from an ordered list of steps on the sender and receiver. The current list before the diagram is useful, I believe the sender steps would start at “H1:” and the receiver steps at hash’. And yes, hash’ needs an explanation. On the receiver side, for validating that ’s’ is a good sequence number, the range has to be checked as mentioned in the previous paragraph. > > > > Section 5 > > s/ stabiluty/ stability/ > > s/admistratively/administratively/ > > s/Sequential nature/The sequential nature/ > > Date: Wed, 05 Aug 2020 16:28:55 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: rtg-bfd@ietf.org > Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-06.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. > > Title : Secure BFD Sequence Numbers > Authors : Mahesh Jethanandani > Sonal Agarwal > Ashesh Mishra > Ankur Saxena > Alan DeKok > Filename : draft-ietf-bfd-secure-sequence-numbers-06.txt > Pages : 6 > Date : 2020-08-05 > > Abstract: > This document describes a security enhancement for the sequence > number used in BFD control packets. This document updates RFC 5880. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-06 > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-06 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > From nobody Tue Dec 8 16:34:48 2020 Return-Path: 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 ED6083A064A; Tue, 8 Dec 2020 16:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_MESSAGE=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 98TpOL5wf5cF; Tue, 8 Dec 2020 16:34:45 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 B72D53A0646; Tue, 8 Dec 2020 16:34:44 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id l11so1064833lfg.0; Tue, 08 Dec 2020 16:34:44 -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=rMWBvaIQPQDWNzXNLpyPDQMaSOLKCSwa3PJWhtKzD9A=; b=G39WN7tr2ZaJ7QiEl1fIGfXN+R6dywa5ro46l0jsIU4FpZ/tpPzAKXtvUgJJByAo4S qgZ0JVGjd9YxwS+ppZuFJz1sLCL6zaBzU9qrCiE3eSoVgJtKMHNlHlHocVogLhVtu6wp BZXBYQHOWQjiSkcIPojyoR+0Z48M4eP4vtycNwpEIieQLyUhaJQdqWG0xhpWrh2F9LZF xKglAkgrqy+WSX0du2BJFPizoNT7gwDF1RdcogIq5E3gXHhd6RzaVNH+KLYyC/HGzRsM zR6xCdSrJhff7VYPAKxBmNv9y8UtIbzu9dHg3CQynb+/AUa+QlLLo8ynbieqWHPTWU/m qrBA== 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=rMWBvaIQPQDWNzXNLpyPDQMaSOLKCSwa3PJWhtKzD9A=; b=AU0pKIdvf7ST/2mC5YKgBIZ839cfhKC+ByHmRcGt9sIvDq7vF7WgVyE8GOWbInklNZ YK6l/iidc0cIHBdsQMt7ftCy9BQQNFuc7bdk1RWxr4WJCe9rSSaHJSQVx6Pmvl1kRCUU H3a4TepO5m9j+QR9UAQK/8PiqhVLjGk6DYaZ4lQzyntitti9SLg/DmBNU/c++2d8V27E FZsTifopDDO9XR5SgerdQgJiX0RXjvQFes4p1Jkopip4sTr/jT6Am1RItwRZGbmWGIOX voKJAge9Bhu0Lr4mj+Kwg7ChAQetubBsfHUp4o6q0vmYP/EUwhKj4T5pAqj+Q0nKwJw1 QZ8w== X-Gm-Message-State: AOAM533sCim4ozZVZq9qqT6y2ZpRaBpf0GP3k7yGUdzYNs/WjjAabhkj rS7Iu2IP5YH6DO2/ExbW6fdn6aKifD/nX9A9/FqR2BWp/zY= X-Google-Smtp-Source: ABdhPJz452dSXnzGXzGduwjUZJLlFBZMlOxfRTHOhhXbwrlAftzzztKC9WiVkuqbIZjapKfSOWzy29NonJ2ybNJ9Vkc= X-Received: by 2002:ac2:5490:: with SMTP id t16mr39266lfk.109.1607474082588; Tue, 08 Dec 2020 16:34:42 -0800 (PST) MIME-Version: 1.0 References: <160747368550.27088.11306069429350103153@ietfa.amsl.com> In-Reply-To: <160747368550.27088.11306069429350103153@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 8 Dec 2020 16:34:31 -0800 Message-ID: Subject: Fwd: New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt To: rtg-bfd WG , bfd-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000adaa1205b5fd39a6" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 00:34:47 -0000 --000000000000adaa1205b5fd39a6 Content-Type: text/plain; charset="UTF-8" Dear All, We welcome a new co-author, Gyan. There are no technical changes but several editorial nits. I recall that following the presentation of this draft a couple of years ago it was suggested that there might be an interest to start 5884bis. Welcome your comments, suggestions on the technical aspects of the draft and possible next steps to progress this work. Regards, Greg ---------- Forwarded message --------- From: Date: Tue, Dec 8, 2020 at 4:28 PM Subject: New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt To: Gyan Mishra , Yanhua Zhao < zhao.yanhua3@zte.com.cn>, Greg Mirsky A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-mpls-bfd-bootstrap-clarify Revision: 01 Title: Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP Document date: 2020-12-08 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/archive/id/draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-bootstrap-clarify/ Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-bfd-bootstrap-clarify Htmlized: https://tools.ietf.org/html/draft-mirsky-mpls-bfd-bootstrap-clarify-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-mpls-bfd-bootstrap-clarify-01 Abstract: This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path. 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 --000000000000adaa1205b5fd39a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear All,
We welcome a new co-author, Gyan.
<= div>There are no technical changes but several editorial nits.
I = recall that following=C2=A0the presentation of this draft a couple of years= ago it was suggested that there might be an interest to start 5884bis.
Welcome your comments, suggestions on the technical aspects of the d= raft and possible next steps to progress this work.

Regards,
Greg

---------- Forwarded message ---------
Fro= m: <inter= net-drafts@ietf.org>
Date: Tue, Dec 8, 2020 at 4:28 PM
= Subject: New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clari= fy-01.txt
To: Gyan Mishra <gyan.s.mishra@verizon.com>, Yanhua Zhao <zhao.yanhua3@zte.com.cn>, Greg Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-01.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-mpls-bfd-bootstr= ap-clarify
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Clarifying Use of LSP Ping to Boot= strap BFD over MPLS LSP
Document date:=C2=A0 2020-12-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-mirsky-mpls-b= fd-bootstrap-clarify-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-bootst= rap-clarify/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-bfd-bo= otstrap-clarify
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mirsky-mpls-bfd-bootstrap-clarify-0= 1
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mp= ls-bfd-bootstrap-clarify-01

Abstract:
=C2=A0 =C2=A0This document, if approved, updates RFC 5884 by clarifying pro= cedures
=C2=A0 =C2=A0for using MPLS LSP ping to bootstrap Bidirectional Forwarding<= br> =C2=A0 =C2=A0Detection (BFD) over MPLS Label Switch Path.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--000000000000adaa1205b5fd39a6-- From nobody Mon Dec 14 07:52:49 2020 Return-Path: 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 916D53A10B0; Mon, 14 Dec 2020 07:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 HU2YbPqGfTS9; Mon, 14 Dec 2020 07:52:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874E23A10A7; Mon, 14 Dec 2020 07:52:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DA138F40705; Mon, 14 Dec 2020 07:52:36 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: =?UTF-8?B?UkZDIDg5NzEgb24gQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBmb3IgVmlydHVhbCBlWHRlbnNpYmxlIExvY2FsIEFyZWEgTmV0d29yayAoVlhMQU4p?= X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, rtg-bfd@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20201214155236.DA138F40705@rfc-editor.org> Date: Mon, 14 Dec 2020 07:52:36 -0800 (PST) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 15:52:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8971 Title: Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) Author: S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda Status: Informational Stream: IETF Date: December 2020 Mailbox: santosh.pallagatti@gmail.com, gregimirsky@gmail.com, sudarsan.225@gmail.com, venggovi@cisco.com, mmudigon@cisco.com Pages: 9 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bfd-vxlan-16.txt URL: https://www.rfc-editor.org/info/rfc8971 DOI: 10.17487/RFC8971 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. This document is a product of the Bidirectional Forwarding Detection Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Dec 16 11:56:40 2020 Return-Path: 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 E08113A0E94 for ; Wed, 16 Dec 2020 11:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 sR1AoWYFHpoK for ; Wed, 16 Dec 2020 11:56:36 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4D29F3A0E93 for ; Wed, 16 Dec 2020 11:56:36 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id A0ED21E356; Wed, 16 Dec 2020 15:13:57 -0500 (EST) Date: Wed, 16 Dec 2020 15:13:57 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [rfc-editor@rfc-editor.org: RFC 8971 on Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN)] Message-ID: <20201216201357.GA24940@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 19:56:39 -0000 Congratulations and thank you for all of your hard work Authors and Working Group on another RFC. -- Jeff and Reshad ----- Forwarded message from rfc-editor@rfc-editor.org ----- Date: Mon, 14 Dec 2020 07:52:36 -0800 (PST) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, rtg-bfd@ietf.org, rfc-editor@rfc-editor.org Subject: RFC 8971 on Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) A new Request for Comments is now available in online RFC libraries. RFC 8971 Title: Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) Author: S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda Status: Informational Stream: IETF Date: December 2020 Mailbox: santosh.pallagatti@gmail.com, gregimirsky@gmail.com, sudarsan.225@gmail.com, venggovi@cisco.com, mmudigon@cisco.com Pages: 9 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bfd-vxlan-16.txt URL: https://www.rfc-editor.org/info/rfc8971 DOI: 10.17487/RFC8971 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. This document is a product of the Bidirectional Forwarding Detection Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ----- End forwarded message ----- From nobody Wed Dec 16 15:30:12 2020 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDE73A12A9; Wed, 16 Dec 2020 15:30:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <160816140645.21399.14012995568337934429@ietfa.amsl.com> Date: Wed, 16 Dec 2020 15:30:06 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 23:30:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : Secure BFD Sequence Numbers Authors : Mahesh Jethanandani Sonal Agarwal Ashesh Mishra Ankur Saxena Alan DeKok Filename : draft-ietf-bfd-secure-sequence-numbers-07.txt Pages : 6 Date : 2020-12-16 Abstract: This document describes a security enhancement for the sequence number used in BFD control packets. This document updates RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-07 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 16 15:37:22 2020 Return-Path: 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 6E4643A12C8; Wed, 16 Dec 2020 15:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 fcXZcDybtpCm; Wed, 16 Dec 2020 15:37:18 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 52E0A3A12C9; Wed, 16 Dec 2020 15:37:18 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id x2so24097039ybt.11; Wed, 16 Dec 2020 15:37:18 -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=Y9wTJfAQWGxX5wdufr8/f3GpMxdC+O2iRnIAM5NnJSQ=; b=nFbtiL59UaldPcSWb7DFaS5rCZdK8FrYgx8t3NiPrruoI+B9Am9FTXcRqT1vgjL6u1 RwsHjQvIqxUMpv5vmLGlmxgLPA9c7q+0pUO73UfKviL+xQCPWjKRWZP7Dh0pzuAFnO0F Vir05FPshI3Co6FSUbMdG41S82ca+QO3iVyNW2msZuZOzsvFabT7b56s6GTc7kW9oGHd l0IdJ5LeEMkxmcjyaBQLYkk4v+9g6OvSPrU8YZLm8oeBG+ZXQgjRWDWwaT4GnhGtl/Il MfV8fsqfX/4eP45DKKNIUlB4Jwi231QDTjjOEXaVYyyLpavewrCoZo+65s6LXDUhw+zG UmhA== 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=Y9wTJfAQWGxX5wdufr8/f3GpMxdC+O2iRnIAM5NnJSQ=; b=IyEYYy0o0RoiTcdc2slHN+ormUjsFYmkv8mXQGbhFhsE+OEZz5QNBE+UtSBgMQspNY lTJH6eXCM5t/6B1wLR7OTP9m6jjhbZR5n+oU/+cNZJh1S7bII0aMkDTAwJNe+LpdQw+j ATMIITsj8PypcAzt7xAC3miqvgkTlEyO2z4mq8uueMb/1YuV4EUUPbv+HOuvsa3HtTQI fwr5+a/LUFFUtfJJFBDUFjJ5wwzMCJCo7tE1ebZ1SGkKhEsk2LRoeA+iISAYfBU21wiN FnEubFQpuRlv6ZAUfsE/jHPnIJd87+jmQklFC9rKcTu1LjcLDQMCPDvDAJ/KOyk2u8Na axmQ== X-Gm-Message-State: AOAM531Ts2+FTpwLdtedZiLFz5LDtuEg4UCa4MqZjGV60oKvpZj+0iiz hXuEGwu8FfhQEMf/RrS2ukE11VnvRxI3tVXZh+4braNv7xM= X-Google-Smtp-Source: ABdhPJyWQOX+bW5obSGN1y2KHrksTXC7Se3/D1UQbbwjk8WP4yVlyg7SwYE/s5JP0/DYnjwicWhiGUkpeew0afi9M3s= X-Received: by 2002:a25:df05:: with SMTP id w5mr58709811ybg.20.1608161837432; Wed, 16 Dec 2020 15:37:17 -0800 (PST) MIME-Version: 1.0 References: <043D4BDD-5024-4F99-83E8-1E3ECD6F4E44@cisco.com> <20201202214610.GC29769@pfrc.org> In-Reply-To: <20201202214610.GC29769@pfrc.org> From: Sonal Agarwal Date: Wed, 16 Dec 2020 15:37:06 -0800 Message-ID: Subject: Re: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" , "reshad@yahoo. com" , "draft-ietf-bfd-secure-sequence-numbers@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000fc4bc05b69d5bc9" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 23:37:22 -0000 --0000000000000fc4bc05b69d5bc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reshad, Jeff, Thanks very much for the review. We have posted a new version of the draft that should address your concerns. URL: https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-07.t= xt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-number= s Htmlized: https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-07 Regards, Sonal. On Wed, Dec 2, 2020 at 1:37 PM Jeffrey Haas wrote: > It's been some time since I've reviewed the entire document, so this is > almost fresh for me as well. :-) > > My comments largely follow Reshad's: > - I don't know what [S] is intended to be. > - The chains in the diagrams aren't necessarily clear. I think they're > intended to represent that you can work forward and backward through th= e > mechanism, but I don't think they're helping with clarity. > > My memory of our prior conversations were that we'd discussed a hash that > had the properties we wanted here. But that hash isn't in the document. > Alan, could you remind us of the example you gave? > > I think my biggest procedural issue is discovering the initial sequence > number. Since the Receiver is always receiving the output of the hash > itself, how does it discover the initial sequence number? If this is a > hash > rather than a symmetric operation, we don't have the property that > hash(s,k) =3D H1; hash (H1,k) =3D s > > So, I think we need some clarity for this sentence: > Note: The first sequence number can > be obtained using the same logic as used in determining Local > Discriminator value for the session or by using a random number. > > -- Jeff > > On Tue, Nov 24, 2020 at 12:09:53AM +0000, Reshad Rahman (rrahman) wrote: > > Hi, > > > > Authors, thank you for addressing my comments in rev-06. > > > > I believe there=E2=80=99s some room for clarification in Section 3. > > > > Comments: > > > > 1. [0] states monotonically increasing sequence number but the > sequence number is actually in [S] > > > > [A] states Authentication but the authentication format contains the > sequence #. So this is supposed to be the hash of the BFD packet as > described in 4.4 of RFC5880. > > > > > > > > As currently defined in BFD [RFC5880], a BFD packet with > > authentication will undergo the following steps, where: > > > > [O]: original RFC 5880 packet with monotonically increasing sequence > > number > > > > [S]: pseudo random sequence number > > > > [A]: Authentication > > > > Sender Receiver > > > > [O] [S] [A] ------------- [A] [S] [O] > > > > > > 1. The text below states that =E2=80=9Cmechanism of provisioning suc= h a key > is outside the scope of this document=E2=80=9D. But further down H1 and = H2 are > both calculated with key =E2=80=98k=E2=80=99. So is the key to calculate = the sequence > number hash the same as the key to calculate the hash for the packet (as > per section 4.4 of RFC5880)? And if they are the same and the attacker ha= s > it, can=E2=80=99t the attacker fudge the sequence number hash also? I thi= nk I could > be missing something here. > > > > This document proposes that for enhanced security in sequence number > > encoding, the sender would identify a hash algorithm (symmetric) tha= t > > would create a 32 bit hash. The hashing key is provisioned securely > > on the sender and receiver of the BFD session. The mechanism of > > provisioning such a key is outside the scope of this document. > > Instead of using the sequence number, the sender encodes the sequenc= e > > number with the hashing key to produce a hash. > > > > > > 1. When the receiver does the reverse hash operation to extract the > sequence number, > previously received =E2=80=98s=E2=80=99 is not enoug= h as per previous > text which mentions tolerate dropped frames. > > > > > > > > k: hashing key > > > > > > > > s: sequence number > > > > > > > > O: original RFC 5880 packet with monotonically increasing sequence > > > > number > > > > > > > > 1. What is meant by =E2=80=9Cremainder of packet=E2=80=9D? > > > > > > > > R: remainder of packet > > > > > > > > H1: hash of s > > > > > > > > H2: hash of entire packet > > > > > > > > A: H2 + insertion in packet > > > > > > > > hash(s, k) =3D H1 > > > > > > > > hash((H1 + R), k) =3D H2 > > > > > > > > hash'((Packet - H2), k) =3D=3D H2 ? Good packet : bad packet > > > > > > > > hash'(H1, k) > previously received s ? Good sequence number : bad > > > > sequence number > > > > > > > > Sender Receiver > > > > > > > > [O] [H1] [A] -------- [A] [H1] [O] > > > > > > > > The above diagram describes how the sender encodes and receiver > > > > decodes the sequence number. The sender starts by taking the > > > > monotonically increasing sequence number and hashing it. It replace= s > > > > the sequence number with the hash. It then calculates the hash for > > > > the entire packet and appends the hash value to the end of the > > > > packet, before transmitting it. > > > > > > > > 1. s/retrieve s/retrieve =E2=80=98s=E2=80=99/ and s/monotically/mono= tonically/ > > > > > > > > The receiver hashes the entire packet without H2, and compares the > > > > hash value with the received hash (H2). If the hash values are > > > > equal, it is a good packet, else it is a bad packet. It then > > > > calculates the hash on the received sequence number to retreive s. > > > > If it is greater than the previously received monotically increasing > > > > sequence number, then the receiver knows it's a valid sequence > > > > number. > > > > Regards, > > Reshad. > > > > From: "Reshad Rahman (rrahman)" > > Date: Sunday, June 14, 2020 at 2:50 PM > > To: "rtg-bfd@ietf.org" , " > draft-ietf-bfd-secure-sequence-numbers@ietf.org" < > draft-ietf-bfd-secure-sequence-numbers@ietf.org> > > Subject: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers > > > > Authors, WG, > > > > The writeup is available at > https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/s= hepherdwriteup/ > > > > For convenience I=E2=80=99ve copied the comments on the document below. > > > > Regards, > > Reshad. > > > > > > This document updates RFC5880. This is missing from the title page > header. > > > > > > > > Abstract > > > > s/a security enhancements/a security enhancement/ > > > > Suggestion: =E2=80=9CThis document describes a security enhancement for= the > sequence number used in BFD control packets=E2=80=9D. > > > > > > > > Requirements Language > > > > Please put this later in the document, e.g. after introduction. Add > RFC8174, and add it as normative reference. > > > > > > > > Introduction > > > > Don=E2=80=99t use Authentication TLV, instead use =E2=80=9CAuthenticati= on Section=E2=80=9D. E.g. > > > > s/in BFD authentication TLVs/in the BFD authentication section/ > > > > > > > > > > > > s/pseudo-random sequence numbers on the frame/pseudo-random sequence > numbers in BFD control packets/ > > > > I=E2=80=99m not sure I understood the last sentence starting with =E2= =80=9CFurther > security may be =E2=80=A6.=E2=80=9D. What is =E2=80=9Cresetting un-encryp= ted sequence=E2=80=9D? Does it > mean that when the sequence numbers rolls over, it=E2=80=99s reset to a > pseudo-random number? > > > > > > > > Section 2 > > > > Rename to =E2=80=9CTheory of operation=E2=80=9D > > > > Suggest splitting the 1st sentence, e.g. > > > > Instead of inserting a monotonically, sometimes occasionally, > increasing > > > > sequence number in BFD control packets, a hash is inserted instead. > > > > The hash is computed, using a shared key, on the sequence number. Th= at > > > > computed hash is then inserted into the sequence number field of the > > > > packet. > > > > > > > > In the following sentence, the part =E2=80=9Cused in computing an authe= nticated > packet=E2=80=9D is referring to computing the SHA1/MD5 hash/digest for th= e packet? > That sentence should be clarified then. > > > > In > > > > case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication], > > > > the sequence number used in computing an authenticated packet would > > > > be this new computed hash. > > > > > > > > Also, when referring to the optimization draft, better to use e.g. > =E2=80=9Coptimized BFD authentication=E2=80=9D than =E2=80=9CBFD authenti= cation=E2=80=9D. The latter > implies per-RFC5880 BFD authentication. > > > > > > > > s/psuedo/pseudo/ > > > > s/ scope of this draft/ scope of this document/ > > > > s/seuquence/sequence/ > > > > > > > > Not clear to me what the following means. > > > > Note: The first sequence number can > > > > be obtained using the same logic as the My Discriminator value. > > > > > > > > The diagram reads well for regular authentication. For secure sequence > number, I think the diagram would gain clarity from an ordered list of > steps on the sender and receiver. The current list before the diagram is > useful, I believe the sender steps would start at =E2=80=9CH1:=E2=80=9D = and the receiver > steps at hash=E2=80=99. And yes, hash=E2=80=99 needs an explanation. On t= he receiver side, > for validating that =E2=80=99s=E2=80=99 is a good sequence number, the ra= nge has to be > checked as mentioned in the previous paragraph. > > > > > > > > Section 5 > > > > s/ stabiluty/ stability/ > > > > s/admistratively/administratively/ > > > > s/Sequential nature/The sequential nature/ > > > > > Date: Wed, 05 Aug 2020 16:28:55 -0700 > > From: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > CC: rtg-bfd@ietf.org > > Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-06.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Bidirectional Forwarding Detection WG > of the IETF. > > > > Title : Secure BFD Sequence Numbers > > Authors : Mahesh Jethanandani > > Sonal Agarwal > > Ashesh Mishra > > Ankur Saxena > > Alan DeKok > > Filename : draft-ietf-bfd-secure-sequence-numbers-06.txt > > Pages : 6 > > Date : 2020-08-05 > > > > Abstract: > > This document describes a security enhancement for the sequence > > number used in BFD control packets. This document updates RFC 5880. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers= / > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-06 > > > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numb= ers-06 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-secure-sequence-number= s-06 > > > > > > 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. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > --0000000000000fc4bc05b69d5bc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reshad, Jeff,

Thanks very much for t= he review. We have posted a new version of the draft that should address yo= ur concerns.

URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/archive/id/draft-i= etf-bfd-secure-sequence-numbers-07.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numb= ers/
= Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/h= tml/draft-ietf-bfd-secure-sequence-numbers
Htmlized:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/html/draft-ietf-bfd-s= ecure-sequence-numbers-07

Regards,
Sonal.


On Wed, Dec 2, 2020 at 1:37 PM Jeffrey Haas &= lt;jhaas@pfrc.org> wrote:
It's been some time = since I've reviewed the entire document, so this is
almost fresh for me as well. :-)

My comments largely follow Reshad's:
- I don't know what [S] is intended to be.=C2=A0
- The chains in the diagrams aren't necessarily clear.=C2=A0 I think th= ey're
=C2=A0 intended to represent that you can work forward and backward through= the
=C2=A0 mechanism, but I don't think they're helping with clarity.
My memory of our prior conversations were that we'd discussed a hash th= at
had the properties we wanted here.=C2=A0 But that hash isn't in the doc= ument.
Alan, could you remind us of the example you gave?

I think my biggest procedural issue is discovering the initial sequence
number.=C2=A0 Since the Receiver is always receiving the output of the hash=
itself, how does it discover the initial sequence number?=C2=A0 If this is = a hash
rather than a symmetric operation, we don't have the property that
hash(s,k) =3D H1; hash (H1,k) =3D s

So, I think we need some clarity for this sentence:
=C2=A0 =C2=A0Note: The first sequence number can
=C2=A0 =C2=A0be obtained using the same logic as used in determining Local<= br> =C2=A0 =C2=A0Discriminator value for the session or by using a random numbe= r.

-- Jeff

On Tue, Nov 24, 2020 at 12:09:53AM +0000, Reshad Rahman (rrahman) wrote: > Hi,
>
> Authors, thank you for addressing my comments in rev-06.
>
> I believe there=E2=80=99s some room for clarification in Section 3. >
> Comments:
>
>=C2=A0 =C2=A01.=C2=A0 [0] states monotonically increasing sequence numb= er but the sequence number is actually in [S]
>
> [A] states Authentication but the authentication format contains the s= equence #. So this is supposed to be the hash of the BFD packet as describe= d in 4.4 of RFC5880.
>
>
>
>=C2=A0 =C2=A0 As currently defined in BFD [RFC5880], a BFD packet with<= br> >=C2=A0 =C2=A0 authentication will undergo the following steps, where: >
>=C2=A0 =C2=A0 [O]: original RFC 5880 packet with monotonically increasi= ng sequence
>=C2=A0 =C2=A0 number
>
>=C2=A0 =C2=A0 [S]: pseudo random sequence number
>
>=C2=A0 =C2=A0 [A]: Authentication
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= ender=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Receiver
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [= O] [S] [A] ------------- [A] [S] [O]
>
>
>=C2=A0 =C2=A01.=C2=A0 The text below states that =E2=80=9Cmechanism of = provisioning such a key is outside the scope of this document=E2=80=9D.=C2= =A0 But further down H1 and H2 are both calculated with key =E2=80=98k=E2= =80=99. So is the key to calculate the sequence number hash the same as the= key to calculate the hash for the packet (as per section 4.4 of RFC5880)? = And if they are the same and the attacker has it, can=E2=80=99t the attacke= r fudge the sequence number hash also? I think I could be missing something= here.
>
>=C2=A0 =C2=A0 This document proposes that for enhanced security in sequ= ence number
>=C2=A0 =C2=A0 encoding, the sender would identify a hash algorithm (sym= metric) that
>=C2=A0 =C2=A0 would create a 32 bit hash.=C2=A0 The hashing key is prov= isioned securely
>=C2=A0 =C2=A0 on the sender and receiver of the BFD session.=C2=A0 The = mechanism of
>=C2=A0 =C2=A0 provisioning such a key is outside the scope of this docu= ment.
>=C2=A0 =C2=A0 Instead of using the sequence number, the sender encodes = the sequence
>=C2=A0 =C2=A0 number with the hashing key to produce a hash.
>
>
>=C2=A0 =C2=A01.=C2=A0 When the receiver does the reverse hash operation= to extract the sequence number,=C2=A0 > previously received =E2=80=98s= =E2=80=99=C2=A0 is not enough as per previous text which mentions tolerate = dropped frames.
>
>
>
>=C2=A0 =C2=A0 k: hashing key
>
>
>
>=C2=A0 =C2=A0 s: sequence number
>
>
>
>=C2=A0 =C2=A0 O: original RFC 5880 packet with monotonically increasing= sequence
>
>=C2=A0 =C2=A0 number
>
>
>
>=C2=A0 =C2=A01.=C2=A0 What is meant by =E2=80=9Cremainder of packet=E2= =80=9D?
>
>
>
>=C2=A0 =C2=A0 R: remainder of packet
>
>
>
>=C2=A0 =C2=A0 H1: hash of s
>
>
>
>=C2=A0 =C2=A0 H2: hash of entire packet
>
>
>
>=C2=A0 =C2=A0 A: H2 + insertion in packet
>
>
>
>=C2=A0 =C2=A0 hash(s, k) =3D H1
>
>
>
>=C2=A0 =C2=A0 hash((H1 + R), k) =3D H2
>
>
>
>=C2=A0 =C2=A0 hash'((Packet - H2), k) =3D=3D H2 ? Good packet : bad= packet
>
>
>
>=C2=A0 =C2=A0 hash'(H1, k) > previously received s ? Good sequen= ce number : bad
>
>=C2=A0 =C2=A0 sequence number
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Sender=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Receive= r
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0[O] [H1] [A] -------- [A] [H1] [O]
>
>
>
>=C2=A0 =C2=A0 The above diagram describes how the sender encodes and re= ceiver
>
>=C2=A0 =C2=A0 decodes the sequence number.=C2=A0 The sender starts by t= aking the
>
>=C2=A0 =C2=A0 monotonically increasing sequence number and hashing it.= =C2=A0 It replaces
>
>=C2=A0 =C2=A0 the sequence number with the hash.=C2=A0 It then calculat= es the hash for
>
>=C2=A0 =C2=A0 the entire packet and appends the hash value to the end o= f the
>
>=C2=A0 =C2=A0 packet, before transmitting it.
>
>
>
>=C2=A0 =C2=A01.=C2=A0 s/retrieve s/retrieve =E2=80=98s=E2=80=99/ and s/= monotically/monotonically/
>
>
>
>=C2=A0 =C2=A0 The receiver hashes the entire packet without H2, and com= pares the
>
>=C2=A0 =C2=A0 hash value with the received hash (H2).=C2=A0 If the hash= values are
>
>=C2=A0 =C2=A0 equal, it is a good packet, else it is a bad packet.=C2= =A0 It then
>
>=C2=A0 =C2=A0 calculates the hash on the received sequence number to re= treive s.
>
>=C2=A0 =C2=A0 If it is greater than the previously received monotically= increasing
>
>=C2=A0 =C2=A0 sequence number, then the receiver knows it's a valid= sequence
>
>=C2=A0 =C2=A0 number.
>
> Regards,
> Reshad.
>
> From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
> Date: Sunday, June 14, 2020 at 2:50 PM
> To: "rtg-bf= d@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-secure-sequenc= e-numbers@ietf.org" <draft-ietf-bfd-secure-sequence-n= umbers@ietf.org>
> Subject: Shephered writeup for draft-ietf-bfd-secure-sequence-numbers<= br> >
> Authors, WG,
>
> The writeup is available at https://datatracker.ietf.org/doc/draft-ietf-bfd-secure= -sequence-numbers/shepherdwriteup/
>
> For convenience I=E2=80=99ve copied the comments on the document below= .
>
> Regards,
> Reshad.
>
>
> This document updates RFC5880. This is missing from the title page hea= der.
>
>
>
> Abstract
>
> s/a security enhancements/a security enhancement/
>
> Suggestion: =E2=80=9CThis document describes a security enhancement fo= r the sequence number used in BFD control packets=E2=80=9D.
>
>
>
> Requirements Language
>
> Please put this later in the document, e.g. after introduction. Add RF= C8174, and add it as normative reference.
>
>
>
> Introduction
>
> Don=E2=80=99t use Authentication TLV, instead use =E2=80=9CAuthenticat= ion Section=E2=80=9D. E.g.
>
> s/in BFD authentication TLVs/in the BFD authentication section/
>
>
>
>
>
> s/pseudo-random sequence numbers on the frame/pseudo-random sequence n= umbers in BFD control packets/
>
> I=E2=80=99m not sure I understood the last sentence starting with =E2= =80=9CFurther security may be =E2=80=A6.=E2=80=9D. What is =E2=80=9Cresetti= ng un-encrypted sequence=E2=80=9D? Does it mean that when the sequence numb= ers rolls over, it=E2=80=99s reset to a pseudo-random number?
>
>
>
> Section 2
>
> Rename to =E2=80=9CTheory of operation=E2=80=9D
>
> Suggest splitting the=C2=A0 1st sentence, e.g.
>
>=C2=A0 =C2=A0 Instead of inserting a monotonically, sometimes occasiona= lly, increasing
>
>=C2=A0 =C2=A0 sequence number in BFD control packets, a hash is inserte= d instead.
>
>=C2=A0 =C2=A0 The hash is computed, using a shared key, on the sequence= number. That
>
>=C2=A0 =C2=A0 computed hash is then inserted into the sequence number f= ield of the
>
>=C2=A0 =C2=A0 packet.
>
>
>
> In the following sentence, the part =E2=80=9Cused in computing an auth= enticated packet=E2=80=9D is referring to computing the SHA1/MD5 hash/diges= t for the packet? That sentence should be clarified then.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 In
>
>=C2=A0 =C2=A0 case of BFD Authentication [I-D.ietf-bfd-optimizing-authe= ntication],
>
>=C2=A0 =C2=A0 the sequence number used in computing an authenticated pa= cket would
>
>=C2=A0 =C2=A0 be this new computed hash.
>
>
>
> Also, when referring to the optimization draft, better to use e.g. =E2= =80=9Coptimized BFD authentication=E2=80=9D than =E2=80=9CBFD authenticatio= n=E2=80=9D. The latter implies per-RFC5880 BFD authentication.
>
>
>
> s/psuedo/pseudo/
>
> s/ scope of this draft/ scope of this document/
>
> s/seuquence/sequence/
>
>
>
> Not clear to me what the following means.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Note: The first sequence number ca= n
>
>=C2=A0 =C2=A0 be obtained using the same logic as the My Discriminator = value.
>
>
>
> The diagram reads well for regular authentication. For secure sequence= number, I think the diagram would gain clarity from an ordered list of ste= ps on the sender and receiver. The current list before the diagram is usefu= l,=C2=A0 I believe the sender steps would start at =E2=80=9CH1:=E2=80=9D an= d the receiver steps at hash=E2=80=99. And yes, hash=E2=80=99 needs an expl= anation. On the receiver side, for validating that =E2=80=99s=E2=80=99 is a= good sequence number, the range has to be checked as mentioned in the prev= ious paragraph.
>
>
>
> Section 5
>
> s/ stabiluty/ stability/
>
> s/admistratively/administratively/
>
> s/Sequential nature/The sequential nature/
>

> Date: Wed, 05 Aug 2020 16:28:55 -0700
> From: in= ternet-drafts@ietf.org
> To: i-d-ann= ounce@ietf.org
> CC: rtg-bfd@ietf= .org
> Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Bidirectional Forwarding Detection WG= of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Secure BFD Sequence Numbers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Mahesh Jethanandani
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Sonal Agarwal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ashesh Mishra
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ankur Saxena
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Alan DeKok
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-bfd-secure-sequence-numbers-06.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 6
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2020-08-05
>
> Abstract:
>=C2=A0 =C2=A0 This document describes a security enhancement for the se= quence
>=C2=A0 =C2=A0 number used in BFD control packets.=C2=A0 This document u= pdates RFC 5880.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.iet= f.org/doc/draft-ietf-bfd-secure-sequence-numbers/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/htm= l/draft-ietf-bfd-secure-sequence-numbers-06
> https://datatrac= ker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-06
>
> A diff from the previous version is available at:
> https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-bfd-secure-sequence-numbers-06
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>

--0000000000000fc4bc05b69d5bc9-- From nobody Sat Dec 19 05:04:09 2020 Return-Path: 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 189BC3A1068; Sat, 19 Dec 2020 05:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 4sMLgBpMw7eB; Sat, 19 Dec 2020 05:04:06 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2112.outbound.protection.outlook.com [40.107.22.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F143A1067; Sat, 19 Dec 2020 05:04:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=niNDa4so3HJ/4kZxKaHf8QDCV+LgJUNnHARMq5dWX8VtR/jKbtyJaStWz1rPbfEbQXXgIWuoTHmR/vO7UU2rdcZKoLcPv2nRqdnsMKQipxhSRrl9/g2Ddc9w2Xm0/A8dJMfp+r3M2faFun47yo/Cd2Br9DikBDSjBg9c6QsVLpMy9a2EOxU+wh9/W6OOlXKf60W3EM8t2N762ub1uO1Fj5MeKLYcKXrsSNfQwGqcksNrIuuMyiX35as5jJJivuqRt0Ztx32SBYK5kPZMdkTQmZvP6fShI+ZYRt1phhKys9X1TwJnZFmkLyBKXolkQ49frf4VI9dx1tdndKXFrLOcig== 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=P4j7wKUtCiCmkSzCzHys45F2NK/w+hvK6sO2Un6KuYw=; b=VDboo9aOoeeUdsTAy+wHFBnvx9ziN+U0gQ7drG4HdgZGHwKhEzBLMejxDvq8HCzzSBP6En/2axO6cNMsv55+52VThvu4pADvlY8+oY1YWnAE/qFqp2DztmoYO+5jtbIGmUAHrbjnrk/sMLzLlMCe/HbhDQWu7O9C0i3IQl278XrpJof+emcQaxFpcnIAwWt4Q9f5lDD7mV4URwZrByE0jSfSZt6HAtOW2PgLokkjsFlN1jAG/05PLYwG08PyH3ZZgpiLJLxHESYv+SHgMXrjXOiz2Lxq8VgjhQrcRq5kijYErKnqjl8S1/exOMhlw+oZJ9f8KEDOPXIf67heKMwaGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P4j7wKUtCiCmkSzCzHys45F2NK/w+hvK6sO2Un6KuYw=; b=ES8QE4i8WRFERTEahSs8zPfqJU9/REtC1dLyinam/WrtogggUX0HcZzpwzFkVgc7FX7VAWDVyNulafT1gAZNcua32xMqEPfqm/Rf57fFRIBCAjWSYFSwiG9HDRQonBGT0kv0a+ptcxviP6F6Lk9Rw5mP3LwBR9kOHPIGRVbeIuA= Received: from AM6PR07MB5784.eurprd07.prod.outlook.com (2603:10a6:20b:95::29) by AM7PR07MB6996.eurprd07.prod.outlook.com (2603:10a6:20b:1bd::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.21; Sat, 19 Dec 2020 13:04:04 +0000 Received: from AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::2c1e:7c35:41ed:9e88]) by AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::2c1e:7c35:41ed:9e88%7]) with mapi id 15.20.3700.021; Sat, 19 Dec 2020 13:04:03 +0000 From: tom petch To: "Reshad Rahman (rrahman)" , Jeffrey Haas CC: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-17.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-17.txt Thread-Index: AQHWdw+Iwlfgxu0FCUW16VNI6cmA0KlBRFQAgAEMZVmAAB6BAIB5GglvgEOWfqM= Date: Sat, 19 Dec 2020 13:04:03 +0000 Message-ID: References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> <20170801144129.GC24942@pfrc.org> <20170801163340.GD24942@pfrc.org> <5F3EA5A8.1050202@btconnect.com> <6D3A9C62-D1FA-4382-B253-9CBC7BEAFD69@cisco.com> , , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0360e52-7fb9-4f3b-0882-08d8a41e8fac x-ms-traffictypediagnostic: AM7PR07MB6996: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mYkM5ReJcWOWnfO4EDd2t3IBPyuilTZxMwkH6kX/U8uBKDRzs9TDtPnU0zatn3hj5jwnvERG5QS+fVRdLwWFEFkcIhv/Kwv9ho/1vp8ykRnSmsEcs6xWu9+cyn2uew76aS1hFFsF1cLxi03b0V2mNsS9xvsHhK1oLx9fpx+yv9K0UV5YFeVJbkjl8vzXOgIKGNQNZmNbM2N89jMo/IH6t6G9Y4fGCieE1TS9TDsz/1WVGSZiYweUuNnTnc2E6CGIXKh4qqjfiOwf9FmkCtdMtAlzSTtWmodXlncfRPEftPopsF75j6U2ggUb98F7QI6w3KTJpy89r77P6oxhaivuzP2D7DtpFzWe6cVHeHC4HRv8u9D8te4k79+UydoH2yVgWT+6LlP8o/y33Yxli2lg7g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5784.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(366004)(136003)(39860400002)(9686003)(4326008)(55016002)(478600001)(66476007)(33656002)(8676002)(8936002)(26005)(71200400001)(110136005)(316002)(7696005)(66946007)(5660300002)(64756008)(52536014)(86362001)(54906003)(76116006)(66446008)(2906002)(6506007)(186003)(83380400001)(66556008)(53546011)(91956017); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?jQY0sragLLT+zZ9uHhfP0wpTYtEaMNSWrRLiLlJVSZhAclniiCgMK6l6lr?= =?iso-8859-1?Q?5zx4DLv64VCuxj6ipiny6fXufsciNDETif1lIptWHtWcyAZIpdh65QN91n?= =?iso-8859-1?Q?IugjkI6CzC2g3KRzuINgLGTI8bRFgY6g3TuD323JsjR3IxD2IFwMt0YJxB?= =?iso-8859-1?Q?SPHfbde3+abX+3ELbdPCohWT3M3vOC+IyBdv1EhYgU1vDzps/MRYGWDdzt?= =?iso-8859-1?Q?/RTTqVuKrUuZxXOuDyTozY/nP0S4nQ3y2WC/y2tOu4zAzZ6YwI9eFB7ofN?= =?iso-8859-1?Q?N1y6HrR7FTT0bMeYKKxRPL9l+AbCmmk5xaqduUPq7l8vlaxyv1bvBgILlT?= =?iso-8859-1?Q?qqy8fsDwPj3Bwhr7DF4Vw2O6lmJUJrT9U1Tb5AvJKb1gsAm8q+5hjIanAz?= =?iso-8859-1?Q?aBt/3/gy5HPqSz5HAeuDLzUlyUeq33MvZfbFEpaO2umMw4OkhkJgWiWzNN?= =?iso-8859-1?Q?Gjx7bp0yRNX/lZBNxkTXHfrHw7qI6BRWwLRRda8gZtslgLu6WLPLv9mUTs?= =?iso-8859-1?Q?0RWKWc68PxREJ5O5I0DgRlvXtApltgnnGzWHaJ1uIlZxKHj5rTI15kvbIV?= =?iso-8859-1?Q?xHRZWAwef5QWiOzhDZqI+P0hz1H039NCaHJ/f0DbJmLLsIlXseUbq8uLAb?= =?iso-8859-1?Q?0y88OCmu0+3I1Fdva44Bm4VhFjQm8lL0c+Oh1yEu2+KQnqUTnJu9q4mNL1?= =?iso-8859-1?Q?mWmzrQGhwIVp7kYdcVhDY/1A7BS7jFiC1jHr+f4kii0SFiQfLIEJjEprO7?= =?iso-8859-1?Q?Epk0cXTZD4keKVzza9XLFtGdLsA1ArYvuZ1TnqwYXGmMfKyEwkXB+DP0Od?= =?iso-8859-1?Q?D2919+FSF+Slf5DEaNfIDAeahwoqLheQmBLXEve6OYj90d+a/dbnoA6SUK?= =?iso-8859-1?Q?pYxf8aJbGO9PT3wHXs0Gvcsrci11ySyQOYIB8exYap6YvV9U8n8p5C2y1Z?= =?iso-8859-1?Q?f6mFt6kUD8a5RE7miD/4ISKYFAj4qtEaoF5vulSZW0nT5QHPENvxFIy9GO?= =?iso-8859-1?Q?8/cTL4cCZndgy8YN0=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5784.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0360e52-7fb9-4f3b-0882-08d8a41e8fac X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2020 13:04:03.8216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GGkCDgX9a9Xs3Zx/wEtZ9IrUWNbcA1Nwc6+S1gS9jCiguQSM2imYqMGPDHspIOriJdsoJqJ96TkuodUG/RYhRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6996 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 13:04:08 -0000 From: Rtg-bfd on behalf of tom petch =0A= Sent: 06 November 2020 12:58=0A= =0A= From: Reshad Rahman (rrahman) =0A= Sent: 21 August 2020 12:31=0A= =0A= On 2020-08-21, 5:57 AM, "tom petch" wrote:=0A= =0A= From: Reshad Rahman (rrahman) =0A= Sent: 20 August 2020 18:42=0A= =0A= I had noticed the lsps vs lsps-state, mentioned it at last BFD WG meeti= ng and have been in touch with the teas-yang authors.=0A= =0A= I hadn't noticed that mpls:enabled had been removed. I'll have to go th= rough all MPLS-related items in the BFD yang.=0A= =0A= =0A= mpls-base has been approved by the IESG and is wending its way through the = system and that is a Normative dependency for bfd-yang so the there might b= e progress on bfd-yang. I had a look at the tools pages and MISSREF but do= not understand what it is telling me:-(=0A= =0A= =0A= =0A= mpls-base is now RFC8960. As yet I do not see any consequential changes in= the I-D in the RFC Editor Q but I am not sure what I should be looking for= so I shall keep looking :-)=0A= =0A= Tom Petch=0A= =0A= =0A= =0A= Yes please; enabled is still there but in a different place; I have not= gone back to mpls-base-yang-03 to see if the semantics are the same.=0A= =0A= Note my third rather indecisive comment that mpls-base-yang now models = mpls in a different way, splitting IP routes with some MPLS, from MPLS only= routes, with no IP, as described in mpls-base-yang-15; I have not got my h= ead around this and do not know how it fits with bfd but suspect that it ne= eds some thinking about.=0A= I don't think it has an impact because BFD uses an IP-prefix as MPLS-F= EC. But I will take a look.=0A= =0A= I read the meeting minutes but your significant (for me) contribution a= ppears to have passed the minute taker by:-)=0A= It was mentioned in the chairs slides though.=0A= =0A= Regards,=0A= Reshad.=0A= =0A= Tom Petch=0A= =0A= =0A= =0A= Regards,=0A= Reshad.=0A= =0A= On 2020-08-20, 12:33 PM, "t petch" wrote:=0A= =0A= Yes bfd-yang. Sometimes I would like to be wrong.=0A= =0A= When I look at this I-D, I see that it references=0A= /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled= =0A= In 2018, the MPLS WG removed that /config from the mpls-base-yang s= o=0A= this would seem to be no longer valid. What needs changing to recti= fy=0A= this I have not explored.=0A= =0A= The I-D has=0A= augment "/te:te/te:lsps-state/te:lsp"=0A= which I no longer see in draft-ietf-teas-yang-te - the -state has = gone.=0A= Again, I have not explored the ramifications of this.=0A= =0A= MPLS WG has a new base-yang out this week which differentiates betw= een=0A= an IP route with a MPLS next hop and a MPLS route with no IP, the l= atter=0A= forming a new, mpls Address Family. I would think that the latter = is=0A= not catered for by BFD but it would be nice to be wrong=0A= =0A= Tom Petch=0A= =0A= =0A= =0A= =0A= From nobody Sat Dec 19 07:08:40 2020 Return-Path: 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 EB8C43A0936 for ; Sat, 19 Dec 2020 07:08:38 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 3K5AutHuBN5F for ; Sat, 19 Dec 2020 07:08:37 -0800 (PST) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 704A43A091C for ; Sat, 19 Dec 2020 07:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608390516; bh=DrNNHaXefadaQdawD+wtB1T8981LksLdnpIg2w5ePqA=; h=Date:Subject:From:To:CC:References:In-Reply-To:From:Subject; b=HL5dhHw4/o9sctMBm2Wi2ImUQ8w88a/RPcxCagiZmjpG1x3AdYjZDjD2PR5WBXW/+oiF7XkTvInnx1F/u+q6s/MTgIGqd2VwHAl5c8CLd+xc4TYToUvElN6WMr+FCFdw9rJ9xb1FHPccBqXZJVmZTFlJRU2Z/WwMRFbbViYjPEjYp8KGAgi7UFsLjGosmn4zjMZO5t8B38nu91djLIaq6d2kmgXDHDQT23IaQa+L3tGtHWlZmzELQHsWSu3HwsVZUGuMY+9Hq3FdxlqxNK245Dc8FO+rG6nqt6NtoTTUs0XOrRzwtr0K0trzLAR6+H3sBudepFfUAFqgKViAgVfXSQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608390516; bh=oUmowo4V3R/kCFVeSSJOqR/LSfcMU07ryszmM00+Fzy=; h=Date:Subject:From:To:From:Subject; b=gKYnHba4KVlNTr/8RbnHFZpp7DBGTYA1miA8iUImZdKKT4D4Ca9Fn4mfUYDAcIszFzF4K4B2V+TfUZCCQU5gjlHkSe78oANejlRGFItQ3Y5nor6xYynqB4jmRGtETwVcVNDBAh1/Gde3r/wPrXNqaIutesrN5mOJoWEZpdlPdUSafxkFKt3daEBmsOnADv8MxC4gdxc+1RlIEgPg5wbDTr6I7ZtepWEOePGPtNFYWWD8q9nhr1hj2jV0aXslDQnMsncQG+g6CxfiEZTkEspxieVwiq7cgkJE55Jj1wW7/NugIs/8USJRHjIBJksT3EMcLIUkbSHl0xiwraR6TWYK3A== X-YMail-OSG: 45Ym2tYVM1k9KyWBulHic3uZl_2QRznKl6D5Z.ylnfBXs4b.xTcohFRebg6uNPK Wxb9XVHK.kXeaDFjC38ttwHoDkY7Dhx42b7z9By_xU3GPizTuSKyXUD3uOR0RqP_03usey0mOqDH l13cUx788AJ978wWEOv.v.tCBrOhlqvY8S0_4PgcBIdJz_g7tAZNyeFlX0ITbeyHe.payUF1bXUM GtCOxGdRls0tbPjc4cwZ6xA4xM9yN9.GlVCZ8.y8B6qVXLPbqvlepYU58JnUQgUg7cYbqJT.MsW4 3yPOe3l3zs1lZ3C2H4DBljaKR72j6wEYEY5eQz..8Q.QQWoJo5yKNnCWFHiC4l.6UgKLyrO689GI JuoFK1AEL7KoUzmQ0KY91rLEAvleC2ByNW21ytjJ82hzHKf41qNa8ZMiDHgNHzFPl.dSx_SQ4Iue eZyk58JX_mTJ6RGt68DneRjSgZEm.aYzBu_1lzNVtl5990Lb_9efHp3RI7eF1EPxMmyMrFVEAdyB hVgknmjUfxw4vnAh8qiphkoL1l0T0bxgbZyy_IZ4bNKfduRwk1nvFH54Hp9ZbaX0OSI2udERyDKd L5AtGMISymM3_MHYq5ggXXvS4U7tKkh5H4VgTVSD6ioVhzg1qOb7adaoknERAKx4LJ66YNk_HlFS 04NKJBtjKaihlgScmIa9Jnv19ijikkFR7bt7N6rvJbgPG8Uu8IwbvsM4up1rluy_I9kce5Gn.0ul X1jrmDnYmKNDSe9ywc45YRhKgCCl58.Cqc9tAUaflsF0U6qU8SBIH4oVKqX48ERuH07KFOQ8GIGr oZNH_raLKnrHPDlhCLhO4jH1cvQX8VNHoJ.lmodWIgn2TwKTUL8BlUTAD6ohQGDY3xaPuPnwXWtl NkezvZsZh9auvbw26E9ALvQ7ruWRALOCzt_IuYIC0umh__do6qWQn23QJKQnbhxbUbdGlg8JdeRq _kclnX6RlAFDb0XFBdAYdFqi3PuD3gree5DMYY.PifW3EIdvwV_xTb9UniF42goD277lTYFEl6io qax5nlpAga_nspd0oKRt491_opinL.qRa698YDgpBUUuWiI9ZAVUx58cbd2jLrUNR3H6jNx5I7Vl X3r4qhU4YZE.kMRvsnUd9NVBWGomssK6rUKBHuvLIS.PNmZpMWXCvFSSYA0ivGyKPly72_WhHSWt 18ULIhZECo8J0WaTkhHNobx6JM4ePCCVg0Id12bYGfoC_zSC3OcJiu7v63kJSPisYuywkGrc_DNl wwsiwe9PRws2ngur590MdJiAFGx8U2nuJeEDW6xT3yYEhUge1bMXzkRitOCuOHz_T9WWlfHWa4gQ KJvDGgO7mB_UgcI5JvlctKxEz12p5FE0bilT70YYj18P_jrv2Y9aYucGNjcyYyMddqClN5WfX91N vY4MSbNAKIaEDEq.MG4hQtZWw5wQgiEQerTe.0U49XKkn7vyu7fhz6id10yyFfE3xEgQMViXj64O vjy4D3caTwvEFb8wcmuckLs8za6a0oXydRpW235UO0S2kNMju6MUhSxc4avtSiXrM7NKTyUf3JTA iJ97dWLcIV2dcLW9LX_SPwjp0pCYhF1uJpDcJGUot1RIQvXX.pR09MDnSUHIGIqwKcmbPwOYXd3T d5Oithm01joyLkAvEFvT5DESVS90yGpb_GDv3cKkwyhf9qvONpPDr8oHaVH0h1vSlOGHYfDcKGrY GAlzxmdtfKYuLx3P_3HAe710KzaafwyQDju6xtGYCUTzxYWPwTvhXzwjHU42M_ZG3f54eD_JwcHU bHuCcHPa6lEgUK4co1Pya7bKuhZQ5M_T9h56oNKHvkpnuJp7xaKSZH7ml_hJhhKrYXFqKAWacO4F DpITmJtI19deDiyQX71lvTKCIEdb2Zb4gyhRaeO2qMbatq5wtpRVXeBH73DQZXzFFVh0R831CojE 6.WghsWs1pF7dK6w9_aFiusbUMx9rRpUgHRL7k4sr.bjCr15wNRp2aRhsnjybM0X6LTjBCG8JCie QogvYLQTvWqD7DfuySmGoRFRta8rnzJcbEZvxA4uFWjPIT8resGUGKRstRQvtNX0l7DH8RV7c0Kf m8G9JR5yBkL0sFdERLsSeI5zXNuEGBNHFm5Ppx4O5LsqubIV7Spym_ohltnFP_H3NZy8JjaYRm5n 9u2H5gQF_u68mD0EGMbGjKpFUEDQPu.83MpEoKqmHm4isMaYth0OHJ2_tBBykyklYif52SGzdmZP ngnM.fSCT5HQ64zrnPjH9STc1PzqwDfoxHyIHSPCIUlWaZJgzWvnskpAFkyxCUAvRNODNUPjoZ3C Lij08MsA9cUkxM5NTYtdRatWKXnhOXDKnrto2zt6tqSpHO_Mhdu8zRXmY6Gkc6B5Q4ai16qWaj79 srh8DmW0NPx5nkwFBkyDWKpbpOIC72oP5tgUlUdEnQ2SUUepgUsj67_3Qem6mTbMlfji0doAJb0O qMeM7dM1JycZkU1pmRDAXRi8QXlBKsEQkV1Tw8_S7no8AkC0dYr19vWT4twRRyzoMA5HKPHiOPM0 746HWPzT.E9F10UhkgzC_556ciwenb0RY5eMdg61bVK4uwA2jw8wJt0oerrqkg3Gf2DuaFPDLMxY Pw5iE_rLCeAQ70WH50aQTRt20zZF_zza39_KBlrU1UUJ44jJ7DW3StKgI_b4urdcvnQx9QbfY.44 JN8F4gSo0BAN4JhUOAAfWhKu4DzGRID.Cxg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Sat, 19 Dec 2020 15:08:36 +0000 Received: by smtp425.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 32ab602996117b56f0d18fd9066c9059; Sat, 19 Dec 2020 15:08:34 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.44.20121301 Date: Sat, 19 Dec 2020 10:08:30 -0500 Subject: Re: I-D Action: draft-ietf-bfd-yang-17.txt From: Reshad Rahman To: tom petch , Jeffrey Haas CC: "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , Lynne Bartholomew Message-ID: <189F7452-D997-42D9-A22F-E93A4716E8F3@yahoo.com> Thread-Topic: I-D Action: draft-ietf-bfd-yang-17.txt References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> <20170801144129.GC24942@pfrc.org> <20170801163340.GD24942@pfrc.org> <5F3EA5A8.1050202@btconnect.com> <6D3A9C62-D1FA-4382-B253-9CBC7BEAFD69@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Mailer: WebService/1.1.17278 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.8) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 15:08:39 -0000 Hi, We have had discussions recently with the RFC Editor wrt changes needed in = draft-ietf-bfd-yang. Unfortunately I don't have access to those emails anymo= re. I don't know whether we can access the latest text in the draft. Regards, Reshad. =EF=BB=BFOn 2020-12-19, 8:04 AM, "Rtg-bfd on behalf of tom petch" wrote: From: Rtg-bfd on behalf of tom petch Sent: 06 November 2020 12:58 From: Reshad Rahman (rrahman) Sent: 21 August 2020 12:31 On 2020-08-21, 5:57 AM, "tom petch" wrote: From: Reshad Rahman (rrahman) Sent: 20 August 2020 18:42 I had noticed the lsps vs lsps-state, mentioned it at last BFD WG m= eeting and have been in touch with the teas-yang authors. I hadn't noticed that mpls:enabled had been removed. I'll have to g= o through all MPLS-related items in the BFD yang. mpls-base has been approved by the IESG and is wending its way through = the system and that is a Normative dependency for bfd-yang so the there migh= t be progress on bfd-yang. I had a look at the tools pages and MISSREF but = do not understand what it is telling me:-( mpls-base is now RFC8960. As yet I do not see any consequential change= s in the I-D in the RFC Editor Q but I am not sure what I should be looking = for so I shall keep looking :-) Tom Petch Yes please; enabled is still there but in a different place; I have= not gone back to mpls-base-yang-03 to see if the semantics are the same. Note my third rather indecisive comment that mpls-base-yang now mod= els mpls in a different way, splitting IP routes with some MPLS, from MPLS o= nly routes, with no IP, as described in mpls-base-yang-15; I have not got my= head around this and do not know how it fits with bfd but suspect that it n= eeds some thinking about. I don't think it has an impact because BFD uses an IP-prefix as MP= LS-FEC. But I will take a look. I read the meeting minutes but your significant (for me) contributi= on appears to have passed the minute taker by:-) It was mentioned in the chairs slides though. Regards, Reshad. Tom Petch Regards, Reshad. On 2020-08-20, 12:33 PM, "t petch" wrote: Yes bfd-yang. Sometimes I would like to be wrong. When I look at this I-D, I see that it references /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enab= led In 2018, the MPLS WG removed that /config from the mpls-base-ya= ng so this would seem to be no longer valid. What needs changing to r= ectify this I have not explored. The I-D has augment "/te:te/te:lsps-state/te:lsp" which I no longer see in draft-ietf-teas-yang-te - the -state = has gone. Again, I have not explored the ramifications of this. MPLS WG has a new base-yang out this week which differentiates = between an IP route with a MPLS next hop and a MPLS route with no IP, t= he latter forming a new, mpls Address Family. I would think that the lat= ter is not catered for by BFD but it would be nice to be wrong Tom Petch From nobody Sat Dec 19 09:13:51 2020 Return-Path: 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 A85633A0D65; Sat, 19 Dec 2020 09:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_MESSAGE=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 z1Jbf36ECD2M; Sat, 19 Dec 2020 09:13:47 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 5AE413A0D55; Sat, 19 Dec 2020 09:13:47 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id b26so4083352lff.9; Sat, 19 Dec 2020 09:13:47 -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=tWY7oukzCEKOP6h+7n2n+eSUcR+vAO4Tk/g2sFBXxuU=; b=be/n6EHLPvXwl6XCmSvKkpRfGTXPWLfb3FeVjPzJyJBZSMoADdMIW4JZKmMWVjYNxY fMyhSGw9ld0rU/XfuzJnzrDm9eVOnMfYs5e8zTCdARE01plVnCcIZsFXZzJfn9O1F6yw De3q3TdwshncGH5q1AHvBKbujodFePM1WVb3FMtEnVK0hGfo77oejtvVMHL0xQAsEkkm JKmVVgucTAjD6HKz9BMzsnMEEWBLUuzKvV/tMYJzNvWkbmkzcDVSvI3C773p9M5H3OjS KNpDtwI7xmteXOTMsSL5eyjA2ZkuVr+Ad9eNLS3yKYVxyol9ol5wIzjdkDb+Fbtpyzrw wghA== 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=tWY7oukzCEKOP6h+7n2n+eSUcR+vAO4Tk/g2sFBXxuU=; b=JItUL6DF0T5ytM4sYysk8dAcmj8lbsHLXVfbTatAsJtZoR8KI+MRzU7XlKQVMyMbnR 07BqTDm5Ld379FCf6rQB0nepxBq5vGVbj6ozjbiNHFFmvvpwThkm/lSsjQ81vddPLvlT UME1a0fbPzd+1E7b+fG5o6/OMmJsgjV0PM53S+VEmi60Cm5X4gXCoPk/fhnOIv84FJEm O4m5dfbtAjojlGgqmfIFqx9gvKLdvz8SQ7uDzqgc4KuW2AAkHAKPUnAm+r/c1Lfh20QE KP/d5T3mg9LZn6/fvLeJeqYGtnczcDJo2ONK4duOMh+iTr7kjbSb9w3ghMY95D+kq1ad BT9A== X-Gm-Message-State: AOAM5324RYYf0uelCnt7USaT7DdFvH/90gSQbvo2jNEnLZJyqEmQYrrO 7DVtQUar/V9d5dXMXmJcJbihxe8dWZCapl34OMI= X-Google-Smtp-Source: ABdhPJxGy6kNBiG6skG77Gd4WyfHNvZXjT50JuC935kgc9yHm+ylJGo6arEjaS3mkPNUDYqtwdBP7zNj0UKN1g0VTk8= X-Received: by 2002:ac2:50c1:: with SMTP id h1mr3760141lfm.350.1608398025201; Sat, 19 Dec 2020 09:13:45 -0800 (PST) MIME-Version: 1.0 References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> <20170801144129.GC24942@pfrc.org> <20170801163340.GD24942@pfrc.org> <5F3EA5A8.1050202@btconnect.com> <6D3A9C62-D1FA-4382-B253-9CBC7BEAFD69@cisco.com> <189F7452-D997-42D9-A22F-E93A4716E8F3@yahoo.com> In-Reply-To: <189F7452-D997-42D9-A22F-E93A4716E8F3@yahoo.com> From: Greg Mirsky Date: Sat, 19 Dec 2020 09:13:33 -0800 Message-ID: Subject: Re: I-D Action: draft-ietf-bfd-yang-17.txt To: Reshad Rahman Cc: tom petch , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , Lynne Bartholomew Content-Type: multipart/alternative; boundary="000000000000f31cab05b6d45875" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 17:13:50 -0000 --000000000000f31cab05b6d45875 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reshad, I've got them. I will re-send several from the RFC Editor shortly. Regards, Greg On Sat, Dec 19, 2020 at 7:08 AM Reshad Rahman wrote: > Hi, > > We have had discussions recently with the RFC Editor wrt changes needed i= n > draft-ietf-bfd-yang. Unfortunately I don't have access to those emails > anymore. I don't know whether we can access the latest text in the draft. > > Regards, > Reshad. > > =EF=BB=BFOn 2020-12-19, 8:04 AM, "Rtg-bfd on behalf of tom petch" < > rtg-bfd-bounces@ietf.org on behalf of ietfa@btconnect.com> wrote: > > From: Rtg-bfd on behalf of tom petch < > ietfa@btconnect.com> > Sent: 06 November 2020 12:58 > > From: Reshad Rahman (rrahman) > Sent: 21 August 2020 12:31 > > On 2020-08-21, 5:57 AM, "tom petch" wrote: > > From: Reshad Rahman (rrahman) > Sent: 20 August 2020 18:42 > > I had noticed the lsps vs lsps-state, mentioned it at last BFD WG > meeting and have been in touch with the teas-yang authors. > > I hadn't noticed that mpls:enabled had been removed. I'll have to > go through all MPLS-related items in the BFD yang. > > > mpls-base has been approved by the IESG and is wending its way throug= h > the system and that is a Normative dependency for bfd-yang so the there > might be progress on bfd-yang. I had a look at the tools pages and MISSR= EF > but do not understand what it is telling me:-( > > > > mpls-base is now RFC8960. As yet I do not see any consequential > changes in the I-D in the RFC Editor Q but I am not sure what I should be > looking for so I shall keep looking :-) > > Tom Petch > > > > Yes please; enabled is still there but in a different place; I > have not gone back to mpls-base-yang-03 to see if the semantics are the > same. > > Note my third rather indecisive comment that mpls-base-yang now > models mpls in a different way, splitting IP routes with some MPLS, from > MPLS only routes, with no IP, as described in mpls-base-yang-15; I have n= ot > got my head around this and do not know how it fits with bfd but suspect > that it needs some thinking about. > I don't think it has an impact because BFD uses an IP-prefix as > MPLS-FEC. But I will take a look. > > I read the meeting minutes but your significant (for me) > contribution appears to have passed the minute taker by:-) > It was mentioned in the chairs slides though. > > Regards, > Reshad. > > Tom Petch > > > > Regards, > Reshad. > > On 2020-08-20, 12:33 PM, "t petch" wrote: > > Yes bfd-yang. Sometimes I would like to be wrong. > > When I look at this I-D, I see that it references > > /rt:routing/mpls:mpls/mpls:interface/mpls:config/mpls:enabled > In 2018, the MPLS WG removed that /config from the > mpls-base-yang so > this would seem to be no longer valid. What needs changing to > rectify > this I have not explored. > > The I-D has > augment "/te:te/te:lsps-state/te:lsp" > which I no longer see in draft-ietf-teas-yang-te - the -stat= e > has gone. > Again, I have not explored the ramifications of this. > > MPLS WG has a new base-yang out this week which differentiate= s > between > an IP route with a MPLS next hop and a MPLS route with no IP, > the latter > forming a new, mpls Address Family. I would think that the > latter is > not catered for by BFD but it would be nice to be wrong > > Tom Petch > > > > > > > > --000000000000f31cab05b6d45875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reshad,
I've got them. I will re-send several f= rom the RFC Editor shortly.

Regards,
Gre= g

On Sat, Dec 19, 2020 at 7:08 AM Reshad Rahman <reshad@yahoo.com> wrote:
Hi,

We have had discussions recently with the RFC Editor wrt changes needed in = draft-ietf-bfd-yang. Unfortunately I don't have access to those emails = anymore. I don't know whether we can access the latest text in the draf= t.

Regards,
Reshad.

=EF=BB=BFOn 2020-12-19, 8:04 AM, "Rtg-bfd on behalf of tom petch"= <rtg-bfd-= bounces@ietf.org on behalf of ietfa@btconnect.com> wrote:

=C2=A0 =C2=A0 From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of tom petch = <ietfa@btconnec= t.com>
=C2=A0 =C2=A0 Sent: 06 November 2020 12:58

=C2=A0 =C2=A0 From: Reshad Rahman (rrahman) <rrahman@cisco.com>
=C2=A0 =C2=A0 Sent: 21 August 2020 12:31

=C2=A0 =C2=A0 On 2020-08-21, 5:57 AM, "tom petch" <ietfa@btconnect.com> w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 From: Reshad Rahman (rrahman) <rrahman@cisco.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent: 20 August 2020 18:42

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I had noticed the lsps vs lsps-state, mentioned= it at last BFD WG meeting and have been in touch with the teas-yang author= s.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I hadn't noticed that mpls:enabled had been= removed. I'll have to go through all MPLS-related items in the BFD yan= g.

=C2=A0 =C2=A0 <tp>
=C2=A0 =C2=A0 mpls-base has been approved by the IESG and is wending its wa= y through the system and that is a Normative dependency for bfd-yang so the= there might be progress on bfd-yang.=C2=A0 I had a look at the tools pages= and MISSREF but do not understand what it is telling me:-(

=C2=A0 =C2=A0 <tp2>

=C2=A0 =C2=A0 mpls-base is now RFC8960.=C2=A0 As yet I do not see any conse= quential changes in the I-D in the RFC Editor Q but I am not sure what I sh= ould be looking for so I shall keep looking :-)

=C2=A0 =C2=A0 Tom Petch


=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tp>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes please; enabled is still there but in a dif= ferent place; I have not gone back to mpls-base-yang-03 to see if the seman= tics are the same.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note my third rather indecisive comment that mp= ls-base-yang now models mpls in a different way, splitting IP routes with s= ome MPLS, from MPLS only routes, with no IP, as described in mpls-base-yang= -15; I have not got my head around this and do not know how it fits with bf= d but suspect that it needs some thinking about.
=C2=A0 =C2=A0 <RR> I don't think it has an impact because BFD use= s an IP-prefix as MPLS-FEC. But I will take a look.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I read the meeting minutes but your significant= (for me) contribution appears to have passed the minute taker by:-)
=C2=A0 =C2=A0 <RR>=C2=A0 It was mentioned in the chairs slides though= .

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Reshad.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tom Petch



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Reshad.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2020-08-20, 12:33 PM, "t petch" &l= t;ietfa@btconnect.= com> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes bfd-yang.=C2=A0 Sometimes I w= ould like to be wrong.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When I look at this I-D, I see th= at it references
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/rt:routing/m= pls:mpls/mpls:interface/mpls:config/mpls:enabled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In 2018, the MPLS WG removed that= /config from the mpls-base-yang so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this would seem to be no longer v= alid. What needs changing to rectify
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this I have not explored.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The I-D has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 augment &quo= t;/te:te/te:lsps-state/te:lsp"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which I no longer see in=C2=A0 dr= aft-ietf-teas-yang-te - the -state has gone.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Again, I have not explored the ra= mifications of this.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MPLS WG has a new base-yang out t= his week which differentiates between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 an IP route with a MPLS next hop = and a MPLS route with no IP, the latter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 forming a new, mpls Address Famil= y.=C2=A0 I would think that the latter is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not catered for by BFD but it wou= ld be nice to be wrong

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tom Petch







--000000000000f31cab05b6d45875--