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

[Jeffrey Haas <[e-mail]>]

[Speaking as chair and shepherd, not an author]

Rob,

On Mon, Dec 12, 2022 at 09:03:18AM -0800, Robert Wilton via Datatracker wrote:
> DISCUSS:
[...]
> 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.

Reshad has been more engaged in such YANG details of late so this may be
better addressed by him when he gets cycles again.

Yes, the intent is for there to be hierarchy.  I understand your concern
about the default, and perhaps I have a misunderstanding how defaults
manifest in YANG modules.

My impression had been that defaults are only relevant when the containing
element was manifested in the model.  So, if it was the case that:
- The global instance for BFD's ip-sh unsolicted container was created
- But that a specific instance of BFD's ip-sh per interface container was
  NOT created...
- There is no effective configuration state for the per-interface
  unsolicited container.  I.e. this is not a presence node.

I'm rusty in my YANG, so if this impression is incorrect a pointer to the
relevant point in the current YANG 1.1. RFC would be helpful.

> 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?

Basically, "because it wants to do it that way".  A SHALL implies that the
local system shouldn't get a choice about this.  Framed a different way, it
means the discussion on "policy" becomes a lot uglier about needing to
expose numerous implementation-specific internal details about why it would
or would not want to bring up a session. 

An example might be a limit on maximum number of sessions.

MAY provides the appropriate hint that this the desired behavior.  SHOULD
could be one steps stronger to imply "well, we're really discussing this in
the spec" and I don't think the text would be harmed by moving to that.

It absolutely couldn't be MUST.

> (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).

Any such values will be locally significant to the implementation.  

My analogy from within SNMP land, putting in such a recommendation in a
compliance statement simply means implementations get forced to try to ship
something that says "this was wrong, we're doing this other thing instead".


-- Jeff