Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)

Jeffrey Haas <jhaas@pfrc.org> Tue, 20 December 2022 21:01 UTC

Return-Path: <jhaas@slice.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 9A385C14F745; Tue, 20 Dec 2022 13:01:25 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uihIw_rcpJ8; Tue, 20 Dec 2022 13:01:24 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E6579C14F5E1; Tue, 20 Dec 2022 13:01:23 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id AF1C11E373; Tue, 20 Dec 2022 16:01:22 -0500 (EST)
Date: Tue, 20 Dec 2022 16:01:22 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-bfd-unsolicited@ietf.org" <draft-ietf-bfd-unsolicited@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, YANG Doctors <yang-doctors@ietf.org>
Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with DISCUSS and COMMENT)
Message-ID: <20221220210122.GA2846@pfrc.org>
References: <167086459809.47152.7191645317039213428@ietfa.amsl.com> <20221216173742.GF23286@pfrc.org> <BY5PR11MB419691B9736C86057F356C58B5E59@BY5PR11MB4196.namprd11.prod.outlook.com> <20221220012001.GA5534@pfrc.org> <BY5PR11MB4196886F53802352AE7C0DE3B5EA9@BY5PR11MB4196.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BY5PR11MB4196886F53802352AE7C0DE3B5EA9@BY5PR11MB4196.namprd11.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/1_OiRVR5EwfRgiC5Wy15VC_O41s>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 20 Dec 2022 21:01:25 -0000

Rob,

On Tue, Dec 20, 2022 at 11:58:03AM +0000, Rob Wilton (rwilton) wrote:
> (1) If the user configures:
>  
> bfd/ip-sh/unsolicited/min-interval = 1000
> 
> And no entries exist bfd/ip-sh/unsolicited/interfaces then all sessions have a min-interval of 1000.  This is fine and expected.
> 
>  
> (2) If the user changes the config from (1) to:
> 
> bfd/ip-sh/unsolicited/min-interval = 1000
> bfd/ip-sh/interfaces[foo]/unsolicited/min-interval = 500
> 
> Then the all sessions on interface foo will have a min-interval of 500.  All other sessions not on that interface will have a min-interval 1000.  This is fine and expected.

More particularly, sessions on foo are not unsolicited.  They will require
additional configuration or bootstrapping via protocol.

> (3) ) If the user changes the config from (1) to just:
> 
> bfd/ip-sh/unsolicited/min-interval = 1000
> bfd/ip-sh/interfaces[foo]/unsolicited/local-multiplier = 2
> 
> then with the interface min-interval/desired-min-tx-interval/required-min-rx-interval defaults this is semantically equivalent to the user configuring:
> 
> bfd/ip-sh/unsolicited/min-interval = 1000
> bfd/ip-sh/interfaces[foo]/unsolicited/local-multiplier = 2
> bfd/ip-sh/interfaces[foo]/unsolicited/desired-min-tx-interval = 1000000
> bfd/ip-sh/interfaces[foo]/unsolicited/required-min-rx-interval = 1000000

While I understand this is what you believe the intent is, the space isn't
quite global vs. per-interface, it's "unsolicited global" vs. per-interface.
I wouldn't expect the min-interval to be inherited in this fashion.

> So, despite the fact that the user hasn't explicitly configured min-interval, desired-min-tx-interval or required-min-rx-interval under the interface, just by configuring something else under the interface causes these defaults to come into scope and causes the rx/tx intervals to operationally change on interface foo.
> 
> This is what I would regard as surprising.  The interface behaviour has changed as a side effect of some somewhat unrelated configuration.
> 
> Normally, with hierarchical configuration, I would expect less-specific settings to take effect unless explicitly overridden by a more specific setting.
> 
> If instead of the default statements under the interface config, the description stated that if not configured, the default inherits from bfd/ip-sh/unsolicited/min-interval, then if the user entered the configuration in (3), then the min-interval on interfaces[foo] wouldn't have changed at all.  It would keep using the (explicitly configured, or implicit default) value from bfd/ip-sh/unsolicited/min-interval.

Again, your example is understood, but I don't think it matches the intent.
We'll see how the authors respond.

I'd rather not see the unsolicited global behavior completely removed. (It
already requires a feature.)  But perhaps that's the best option.

> As example of this hierarchical configuration, in the style that I describe, is in RFC 8342, C.2.  Added by Phil Shafer, if I recall correctly ...

Little surprise, I understand Phil's example quite well.  In that example,
the hierarchy ends up being largely consistent across the configuration
scopes, and the inheritance model needs to be called out in the
documentation.

In this BFD unsolicited case, the per-interface state has a leaf for
unsolicited while the "global" case is a unsolicited container that has
configuration parameters.  So, the point of similarity is a bit split.

FWIW, in the model Phil is citing, even then inheritance isn't completely
transparent.  As an example, address-family configuration when done in any
more specific scope requires a full re-specification of the families.  This
is because if configuration at the more specific scope caused a union over
the previously configured families, the syntax would then require a
"no-address-family" negative configuration to undo the inheritance.

Inheritance is a mess. :-)

-- Jeff