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

[Reshad Rahman <[e-mail]>]

 Hi Rob, Jeff, all,
Rob thanks for catching this. Yes the intention is to have inheritance and I will spell that out in the next rev. The default values will be removed for leaf nodes under bfd/ip-sh/unsolicited and the descriptions will be updated to point to the global unsolicited config (which will still have default values).
Regards,Reshad.
    On Tuesday, December 20, 2022, 04:01:33 PM EST, Jeffrey Haas <[e-mail]> wrote:  
 
 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

_______________________________________________
yang-doctors mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/yang-doctors