Subject: [babel] information model open issues

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 1 Aug 2018 19:05:31 +0000

I have some open issues that I'd like to make sure I get right.

1. Proposed description of babel-hello-mcast-history (and similar for -ucast-history)

babel-hello-mcast-history: the multicast Hello history of whether or not the multicast Hello messages prior to babel-exp-mcast-hello-seqno were received; representation of a binary sequence where the most recently received Hello is expressed as a "1" placed in the left-most bit, with prior bits shifted right (and "0" bits placed between prior Hello bits and most recent Hello for any not-received Hellos); represented as a string using utf-8 encoded hex digits ([0-9a-fA-F]);  note that this representation (supplied to a user interface or transmitted across a management interface) is intended to be a string representation of the stored binary value; see <xref target="rfc6126bis">draft-ietf-babel-rfc6126bis</xref> section A.1

2. v4/v6 next hop addresses

I think the proposal was to include route next hop ipv4 and ipv6 address parameters in the neighbor table? These would be the next hop addresses used for routes associated with this neighbor. I wanted to confirm I had that right.
Add to neighbor object:
[ip-address             babel-next-hop-v4address;]
[ip-address             babel-next-hop-v6address;]

babel-next-hop-v4address: the IPv4 address that will be used for any selected IPv4 route advertised by this neighbor
babel-next-hop-v6address: the IPv6 address that will be used for any selected IPv6 route advertised by this neighbor

3. intervals -- what do the parameters mean and what actually makes sense to be able to represent as a parameter
The model currently has the following interval parameters:
interfaces:          [int                  babel-mcast-hello-interval;]   the current multicast hello interval in use for hellos sent on this interface
interfaces:          [int                  babel-update-interval;]    the current update interval in use for this interface
neighbors:          int                  babel-neighbor-ihu-interval;    current IHU interval for this neighbor
neighbors:          [int                  babel-ucast-hello-interval;]     the current unicast hello interval in use for hellos sent to this neighbor on this interface

Toke specifically asked about the babel-neighbor-ihu-interval. Given what Toke said, I've been thinking. 

All of these timer intervals are too ephemeral to be useful. I think they should all go.
But maybe instead of trying to track intervals, would it be possible to get a count of hello, ihu, and update TLVs sent (multicast and unicast) -- kind of like the counts interfaces provide of Ethernet frames transmitted and received? These counts are usually just started at boot and keep increasing until something causes them to start over (like reboot, specific reset trigger, or reaching max value). This would have the advantage of being a real statistic -- so we could claim the info model has the ability to provide statistics. They would all be optional. I use the Ethernet frame counts often in troubleshooting: they tell me if the interface is receiving/transmitting frames at all, and how frequently.

Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 01 Aug 2018 21:10:02 +0200

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

> But maybe instead of trying to track intervals, would it be possible
> to get a count of hello, ihu, and update TLVs sent (multicast and
> unicast) -- kind of like the counts interfaces provide of Ethernet
> frames transmitted and received? These counts are usually just started
> at boot and keep increasing until something causes them to start over
> (like reboot, specific reset trigger, or reaching max value). This
> would have the advantage of being a real statistic -- so we could
> claim the info model has the ability to provide statistics. They would
> all be optional. I use the Ethernet frame counts often in
> troubleshooting: they tell me if the interface is
> receiving/transmitting frames at all, and how frequently.

My immediate thought is that this sounds like a reasonable idea. Not
sure I agree that (all) the timers should go, though... :)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Aug 2018 00:47:52 +0200

> babel-next-hop-v4address: the IPv4 address that will be used for any
> selected IPv4 route advertised by this neighbor
> babel-next-hop-v6address: the IPv6 address that will be used for any
> selected IPv6 route advertised by this neighbor

I suggest "any route advertised by that neighbour in the absence of an
explicit next-hop TLV (See [RFC6126bis] Sections 4.6.8 and 4.6.9)."

> All of these timer intervals are too ephemeral to be useful. I think they should all go.

I'm not sure.  The protocol leaves a lot of latitude wrt. sending all of
these kinds of packets, but actual implementetions tend to follow
a regular schedule augmented with occasional triggered updates.  These
values are intended to reflecct the regular schedule.

> But maybe instead of trying to track intervals, would it be possible to
> get a count of hello, ihu, and update TLVs sent (multicast and
> frames transmitted and received?

That's an excellent idea if these values are read-only.  It's not useful
if they are meant to be read-write.

(I can envision a node that decreases its Hello interval when it becomes
mobile, and increases its interval when it becomes fixed.  Is that
a legitimate application of a management interface?)

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 2 Aug 2018 12:57:41 +0000

> I'm not sure.  The protocol leaves a lot of latitude wrt. sending all of these
> kinds of packets, but actual implementetions tend to follow a regular
> schedule augmented with occasional triggered updates.  These values are
> intended to reflecct the regular schedule.
> 
> That's an excellent idea if these values are read-only.  It's not useful if they
> are meant to be read-write.
> 
> mobile, and increases its interval when it becomes fixed.  Is that a legitimate
> application of a management interface?)

OK. So Toke also says it may not be reasonable to get rid of all the interval parameters. But it sounds like adding some statistics may be good, too.
I checked, and all the intervals were already defined as read-only. Statistics (counts) are always read-only. So I think we're ok on that front.
[IMO: The beauty of Babel is its lack of need for configuration -- an implementation should automatically adjust to changes in link characteristics. These parameters can be used in troubleshooting and debugging; the correct action after identifying undesirable behavior is a new revision of the implementation for improved automatic adjustment to changes in conditions and not manual tweaking.]

What intervals make sense to be able to report?
It sounds like ones that are simply a reaction to (or the value of) an interval sent by a neighbor do not make sense. I think that would get rid of the babel-neighbor-ihu-interval that Toke initially challenged.
But maybe it makes sense to keep the (optional) Hello interval parameters (multicast and unicast)?
What about the update interval?
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 02 Aug 2018 21:26:11 +0200

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

> It sounds like ones that are simply a reaction to (or the value of) an
> interval sent by a neighbor do not make sense. I think that would get
> rid of the babel-neighbor-ihu-interval that Toke initially challenged.

Both Hello and Update intervals are configurable in Bird, which to me
implies that reporting the current values in the information model is
probably worthwhile :)

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 2 Aug 2018 21:12:24 +0000

> Both Hello and Update intervals are configurable in Bird, which to me implies
> that reporting the current values in the information model is probably
> worthwhile :)

Cool. Do you make them configurable per interface, or globally? I see that it is possible to send Updates by unicast. If an implementation were to support this, would it make sense for Update intervals to be configurable per neighbor? Or would an interface Update interval still be sufficient for all?
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 02 Aug 2018 23:24:27 +0200

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

> Cool. Do you make them configurable per interface, or globally?

Per interface.

> I see that it is possible to send Updates by unicast. If an
> implementation were to support this, would it make sense for Update
> intervals to be configurable per neighbor? Or would an interface
> Update interval still be sufficient for all?

Hmm, I'm not sure I can come up with a reason why that would be useful?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 03 Aug 2018 11:56:59 +0200

>>> Both Hello and Update intervals are configurable in Bird,

> Per interface.

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