Subject: [babel] info model: configurability of intervals

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 24 Feb 2021 16:43:55 +0000

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:

https://mailarchive.ietf.org/arch/msg/babel/gIddQkzbIC9djewZ4wPN7BGyBRw/

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 24 Feb 2021 18:00:24 +0100

"STARK, BARBARA H" <[email-masked]> writes:

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 26 Feb 2021 18:23:16 +0000

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

> < URL mauled by email system>
> >

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Feb 2021 20:31:03 +0100

> Juliusz indicates in this that IHU intervals are dynamically computed.

In babeld, the IHU interval is equal to the update interval on lossy
links, and equal to three times the update interval on lossless links.
(On lossless links, the IHU is essentially repeating "this link is still
lossless", so it may be suppressed with no ill effect; on lossy links, it
is used to update the link cost in a timely manner.)

> 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
> accurate, or should intervals be configurable via the info/data models?

I am concerned that making these values writable will constrain
implementations to use static intervals.  The protocol is very carefully
engineered to make dynamic intervals usable.  (If the intervals are
static, then the Hello seqno, for example, serves no useful purpose.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 26 Feb 2021 20:32:58 +0100

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

Yes.  Experience shows that human admins like to tweak things, and that
a lot of time they get their tweaks wrong.

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

I would tend to agree.

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

Yes.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 26 Feb 2021 22:07:19 +0100

>> configuration, at this time?

Fine with me as well :)

-Toke