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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Jeff,

Please see inline ...

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Jeffrey Haas
> Sent: 16 December 2022 17:38
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; bfd-
> [e-mail]; [e-mail]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-bfd-unsolicited-11: (with
> DISCUSS and COMMENT)
> 
> [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.

[Rob Wilton (rwilton)] 

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.

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

[Rob Wilton (rwilton)] 

Section 7.6.1 of YANG 1.1 (RFC 7950) is probably the most helpful and perhaps describes the rules most clearly.


> 
> > 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.
[Rob Wilton (rwilton)] 

I think that my comment was a bit more nuanced.  The MAY statement is already predicated on "if permitted by local configuration and policy ".  The way that I read the current text is that even if the local configuration and policy states that a session should be created (e.g., because it is under the limit of the maximum number of allowed sessions) then an implementation is still entirely at liberty to not create a session.

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."


> 
> > (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".
[Rob Wilton (rwilton)] 

Probably my lack of knowledge but I think that I was perhaps misreading the model and it was already doing what I was suggesting anyway.  So, you can just ignore this one.

Thanks,
Rob


> 
> 
> -- Jeff