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

[Jeffrey Haas <[e-mail]>]

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