Re: [babel] info model: configurability of intervals

["STARK, BARBARA H" <[e-mail]>]

Thanks Toke. I wanted to wait to see if anyone else expressed thoughts, before I replied. My reply is at the bottom.

> > Hi Babel,
> >
> > There's a question about the need to support configurability of
> > interval parameters. Right now, they're all read-only. RFC 8966
> > indicates they can change, and back in August 2018, we discussed
> > intervals:
> >
> >
> < URL mauled by email system>
> >
> > That particular email says:
> > ===============
> > [Toke]>>> Both Hello and Update intervals are configurable in Bird,
> >
> > [Barbara]>> Cool. Do you make them configurable per interface, or globally?
> >
> > [Toke]> Per interface.
> >
> > [Juliusz]Same thing in babeld.  (There's also a global value, but it's only used to
> > configure interfaces that don't have specific values configured.)
> >
> > (As to IHUs, babeld dynamically computes an interval from the Hello
> > interval and the estimated loss rate.)
> > ==================
> > Juliusz indicates in this that IHU intervals are dynamically computed.
> > I can't find it in any of the emails, but I think somehow there was a
> > determination that configuration of all intervals was done by the
> > implementation based on costs/metrics, and that no *external*
> > configuration of intervals was supported (or desirable). Is that
> > accurate, or should intervals be configurable via the info/data
> > models?
> 
> I think there can be some value in making them configurable. I.e., if
> you know you network is really stable and never drops packets, you can
> set a really high interval and rely on triggered updates for the
> in-between stuff, thus saving some overhead. Conversely, if you know
> devices have a tendency to drop off the network with no warning you can
> set a really low interval to quickly flush out disappearing devices by
> timeout, at the cost of more signalling overhead. Doing such things
> require operational knowledge, so setting them by the management
> interface seems reasonable.
> 
> On the other hand, we also want implementations to be able to make
> decisions about things on their own: e.g., babeld will try to detect if
> an interface is wireless, and if so automatically apply different
> parameters to it, which includes changing the intervals (IIRC). That
> should also be allowed, so the information model should leave room for
> implementations to pick their own settings as well...
> 
> -Toke

Designing an unambiguously behaving model in a world where some implementations would want to allow for interval configuration and others wouldn't, and where implementations reserve the right to change the interval based on calculations using metrics (though some may allow disabling of this changing -- which might not be great if the admin doesn't know what they're doing) could be done; I'm just not sure I want to do it at this point in the info model (all DISCUSSES are cleared and there are enough IESG positions to proceed). IIRC, Juliusz had suggested human admins were likely to have little understanding of what was needed and the implementation was in a better position to adjust values appropriately based on metrics.

If I were to do this, I'd separate out the current value of an interval from the configured value (which YANG does, anyway; but which we've only lightly touched on in the info model). That would allow flexibility as to whether an implementation could change intervals even if it had a configured value. That is, the configured value would just be a starting point and would not be immutable during execution. If we were to allow the code the change away from a configured value, we would probably also need a parameter to allow/disallow the code from changing away from a configured value.

So if configuration were supported, it would mean the current parameter (read-only of the current value) would stay and other parameters would be added.

But based WG list traffic, there doesn't seem to be a strong WG belief that we need to support human configuration of intervals at this time. 

Would it be ok if we left these read-only current-value interval parameters as is and didn't add any other parameters to support configuration, at this time? We don't have to be completely perfect.
Barbara