Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Mon, 12 December 2022 17:03 UTC
Return-Path: <noreply@ietf.org>
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 17E0FC14F730; Mon, 12 Dec 2022 09:03:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfd-unsolicited@ietf.org, bfd-chairs@ietf.org, rtg-bfd@ietf.org, Jeffrey Haas <jhaas@pfrc.org>, jhaas@pfrc.org
Subject: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 9.2.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <167086459809.47152.7191645317039213428@ietfa.amsl.com>
Date: Mon, 12 Dec 2022 09:03:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/CjsoagR_SYILCSlJDo6zWFIwGHg>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
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, 12 Dec 2022 17:03:18 -0000
Robert Wilton has entered the following ballot position for draft-ietf-bfd-unsolicited-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Thanks for this document. Please see my comments below for more details, but I'm balloting discuss on 3 points: (1) The document is somewhat unclear as to whether the configuration is applied hierarchically (I presume that it is, if not then my second discuss point is not valid and can be ignored). (2) As specified, I don't think that the hierarchical configuration will work, because the interface level leaf "defaults" will override an explicit value configured globally. I.e., logically, the interface level leaf, if in scope, will always have a value. (3) The document should provide an instance-data example in the appendix to illustrate the use of this configuration. Regards, Rob ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Moderate level comments: (1) p 3, sec 2. Procedures for Unsolicited BFD When the passive side receives a BFD Control packet from the active side with 0 as "Your Discriminator" and does not find an existing BFD session, the passive side MAY create a matching BFD session toward the active side, if permitted by local configuration and policy. I'm surprised that this is only a MAY and not a SHOULD or MUST. I.e., if the local configuration & policy allows passive BFD sessions why would they not be created? (2) p 4, sec 4.1. Unsolicited BFD Hierarchy * Globally, i.e. for all interfaces. This requires support for the "unsolicited-params-global" feature. * For specific interfaces. This requires support for the "unsolicited-params-per-interface" feature. >From this description, it is unclear to me whether the features enabling global or per-interface configuration are meant to be an either/or (in which case, the constraint could probably be expressed in the features), or whether a server is allowed to support configuration both globally and override the global configuration with interface specific configuration. My subsequent discuss comments assume the latter. Either way, it would be helpful for this text in this section (and probably the YANG module) to be a bit more explicit on this regard. (3) p 8, sec 4.2. Unsolicited BFD Module augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "bfd-ip-sh:interfaces" { if-feature bfd-unsol:unsolicited-params-per-interface; description "Augmentation for BFD unsolicited on IP single-hop interface"; container unsolicited { description "BFD IP single-hop interface unsolicited top level container"; leaf enabled { type boolean; default false; I'm not sure that you want a default value specified in the YANG here since this would have precedence over any explicitly configured global default value. (4) p 8, sec 4.2. Unsolicited BFD Module description "BFD unsolicited enabled on this interface."; } uses bfd-types:base-cfg-parms; You have the same issue here as above, in that the default values directly associated with the leaves in this grouping will always take precedence over any configured global value. I.e., the configuration, if properly implemented cannot be hierarchical. The pragmatic solution is to copy the used grouping inline here and delete the default statements. This has the advantage that the descriptions can also make the hierarchical behavior of the configuration explicit. (5) p 9, sec 4.2. Unsolicited BFD Module augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "bfd-ip-sh:sessions/bfd-ip-sh:session" { description "Augmentation for BFD unsolicited on IP single-hop session"; leaf role { type bfd-unsol:role; config false; description "Role of local system during BFD session initialization."; } } } <CODE ENDS> Please add an instance data example to an appendix to illustrate the use of this YANG model. This helps readers and can further emphasize the hierarchical nature of the configuration. Minor level comments: (6) p 3, sec 2. Procedures for Unsolicited BFD Passive unsolicited BFD support MUST be disabled by default, and MUST require explicit configuration to be enabled. On the passive side, the desired BFD parameters SHOULD be configurable. The passive side MAY also choose to use the parameters that the active side uses in its BFD Control packets. The "My Discriminator", however, MUST be chosen to allow multiple unsolicited BFD sessions. Rather then configured values on the passive side, did the authors consider setting minimum configuration limits? E.g., rather than define desired send/receive limits, instead, configure lower bounds on what the minimum tx interval may be (to prevent DDOS attacks). Nit level comments: (7) p 3, sec 2. Procedures for Unsolicited BFD The passive side MUST then start sending BFD Control packets and perform the necessary procedure for bringing up, maintaining and tearing down the BFD session. If the BFD session fails to get established within certain specified time, or if an established BFD session goes down, the passive side SHOULD stop sending BFD Control packets and MAY delete the BFD session created until BFD Control packets are initiated by the active side again. Nit, within certain specified => within a specified (8) p 6, sec 4.2. Unsolicited BFD Module Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. This copyright statement will need to be fixed.
- Robert Wilton's Discuss on draft-ietf-bfd-unsolic… Robert Wilton via Datatracker
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Jeffrey Haas
- RE: Robert Wilton's Discuss on draft-ietf-bfd-uns… Rob Wilton (rwilton)
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Jeffrey Haas
- RE: Robert Wilton's Discuss on draft-ietf-bfd-uns… Rob Wilton (rwilton)
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Jeffrey Haas
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Reshad Rahman
- Re: [yang-doctors] Robert Wilton's Discuss on dra… Reshad Rahman
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Reshad Rahman
- Re: [yang-doctors] Robert Wilton's Discuss on dra… Reshad Rahman
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Reshad Rahman
- RE: Robert Wilton's Discuss on draft-ietf-bfd-uns… Rob Wilton (rwilton)
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Reshad Rahman
- RE: Robert Wilton's Discuss on draft-ietf-bfd-uns… Rob Wilton (rwilton)
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Reshad Rahman
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Jeffrey Haas
- RE: Robert Wilton's Discuss on draft-ietf-bfd-uns… Rob Wilton (rwilton)
- Re: Robert Wilton's Discuss on draft-ietf-bfd-uns… Reshad Rahman
- WG, please review [was: Re: Robert Wilton's Discu… John Scudder
- Re: WG, please review [was: Re: Robert Wilton's D… John Scudder