Hi Jeff, To give some concrete examples:
(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. (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 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. 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 ... Does this help clarify at all? Thanks, Rob > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Jeffrey Haas > Sent: 20 December 2022 01:20 > To: Rob Wilton (rwilton) <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; bfd- > [email protected]; [email protected] > Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with > DISCUSS and COMMENT) > > Rob, > > On Mon, Dec 19, 2022 at 11:37:12AM +0000, Rob Wilton (rwilton) wrote: > > You are correct that in the case that the client has not configured an > > entry in > "... bfd:bfd/ip-sh/interfaces" then this list element does not exist, and > hence it > seems that the global value would take effect. > > > > But if the client configured anything under that subtree tree (e.g., if they > choose to configure "... bfd:bfd/ip-sh/interfaces[eth0]/authentication/key- > chain" then those other defaults values would suddenly come in effect (even if > not explicitly configured by the client) and logically override the global > values > for those interfaces. Is this the intent? I would think that it might be > somewhat surprising. Normally, for hierarchical configuration, I would only > expect the per-interface settings to override a global setting if the per- > interface setting has been explicitly configured. > > In trying to filter this through the Principle of Least Astonishment, I'm of > mixed opinions which side a default on interface configuration that > overrides global configuration would be. I've seen it both ways in various > configuration paradigms. > > I'm insufficiently versed in such inheritance examples in other IETF models. > If the YANG doctors have any thoughts here, they'd be highly pertinent. > > In the absence of a conflicting paradigm, the behavior covered by the > default false on more specific configuration is that it fails in a safe > fashion. If global configuration is present, and is in this very permissive > mode, any per-interface override is probably being made for particular > reasons. If you override global in some places, doing so in others somewhat > makes sense. > > That said, let's see what the authors' collective intents are. > > > I think that SHOULD is clearer than MAY, or another way of stating this > > could > be: > > > > ".., the passive side SHOULD* create a matching BFD session toward the > active side, unless not permitted by local configuration or policy." > > While more succinct, the implication is fail-open without policy. (Shades > of the subtleties that got us RFC 8212.) > > Perhaps instead: > "..., when permitted by local configuration or policy, the passive side > SHOULD create a matching BFD session toward the active side" ? > > > -- Jeff
