IETF Logo Mail Archive

Re: Some comments to the authors of draft-ietf-bfd-unsolicited

Jeffrey Haas <jhaas@pfrc.org> Mon, 28 February 2022 16:35 UTC

Return-Path: <jhaas@pfrc.org>
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 84F8E3A1312; Mon, 28 Feb 2022 08:35:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 kNN29X-3ZbFi; Mon, 28 Feb 2022 08:35:50 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 37A7E3A1310; Mon, 28 Feb 2022 08:35:50 -0800 (PST)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id F40491E341; Mon, 28 Feb 2022 11:35:48 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9AF139AA-637D-4763-B177-46479EE910F3"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: Some comments to the authors of draft-ietf-bfd-unsolicited
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CA+RyBmWerxKKS6FCyaeQApuGkVT0JehrFToPBDf-ebrLkCSLnw@mail.gmail.com>
Date: Mon, 28 Feb 2022 11:35:48 -0500
Cc: Reshad Rahman <reshad@yahoo.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "draft-ietf-bfd-unsolicited@ietf.org" <draft-ietf-bfd-unsolicited@ietf.org>
Message-Id: <682D13B3-A62E-4A0D-9192-2D0D5844B86B@pfrc.org>
References: <CA+RyBmX8oAQFqJMjVhcj_78wYfrvz+afnSoP2-VjWyfCEunqmQ@mail.gmail.com> <381777191.1553826.1645979075642@mail.yahoo.com> <CA+RyBmWerxKKS6FCyaeQApuGkVT0JehrFToPBDf-ebrLkCSLnw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nYtP641vt41h8sFknv9FwU1TsdU>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 16:35:53 -0000

Greg,

Not speaking for the authors here, but:

> On Feb 28, 2022, at 10:34 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> GIM>> Thinking of what might had confused me, I feel that it may be the use of "passive role" that was already described in Section 6.1 RFC 5880 <http://The state of New Hampshire removes ALL Russian liquor brands from the state-owned (yes, alcohol is a state monopoly in NH) stores.>. What do you see as the distinction between the Passive role behavior as described in RFC 5880 and the passive role described in the draft?

The primary distinction of this proposal is whether or not a session is PROVISIONED at the passive side or not.

It's possible to be provisioned, and passive.  

This draft makes the passive side at best loosely provisioned.  "I am willing to accept incoming BFD sessions without having one configured".

-- Jeff

v2.23.0 | Report a Bug | By Email