Subject: Re: [babel] I-D Action: draft-ietf-babel-information-model-02.txt

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 5 Jun 2018 17:40:20 +0000

Response in-line. There are some questions interspersed.
Barbara

> From: Toke Høiland-Jørgensen
> > babel-ucast-hello-interval: the current unicast hello interval in
> >      use for this interface
> 
> Shouldn't this be per-neighbour?

Good question. I don't see anything in source-specific that suggests different intervals will be used for different destinations, so I don't know. What are y'all developers doing? Is it possible that y'all's code will cause different Hello intervals to be sent to different destinations? It seems easier to keep this at an interface level, and all the costs used to determine an interval are at the interface level. 
Also... Right now the neighbor table is only about messages received from neighbors and the responses to those messages. Would there be concern with assuming neighbors = specific destinations (and using a single table for both) -- is there a necessary correlation of neighbors to source-specific destinations? Or, if we need to express information related to specific destinations, should that be a distinct table?

> >      babel-message-log: log entries that have timestamp of a received
> >      Babel message and the entire received Babel message, including
> >      Ethernet frame and IP headers; an implementation must restrict the
> >      size of this log, but how and what size is
> > implementation-specific
> 
> A userspace implementation doesn't necessarily have access to the Ethernet
> and IP headers.

Good point. I've added the words "if possible" to the Ethernet frame and IP headers clause. I also did this for the credentials log. It's definitely desirable.

> >      babel-neighbor-ihu-interval: current IHU interval for this
> >      neighbor
> 
> The IHU interval (i.e. the value put into an IHU TLV) is not necessarily
> available; it is perfectly sensible to just store the expiry time.

Why would the value put in the TLV not be available? I could make this optional, if it may be hard to record this value when sent. By "expiry time" do you mean the current value of the timer, or something else? What I was trying to get at by knowing the sent IHU TLV interval was what this babel instance's expectations were as to how frequent it needed to be getting Hellos from this neighbor. Comparing the different intervals used for different neighbors on an interface can be valuable information in understanding a network, if those intervals vary. Or should they vary? I'm not sure how I would use "expiry time" or why I should care about it?

> >      babel-security-supported: list of supported security mechanisms
> 
> So every security object contains the entire list of supported security
> mechanisms? Until this point I was under the impression that the logic was
> one security object per mechanism...

Hmm. That's a great suggestion. I like that idea. That solves certain things that were bothering me. I'll change security to be a separate object instance per mechanism. I'll need to move the list of supported security mechanisms up to the top level object. But this will let me put an enable/disable parameter inside the object and get rid of the strange list of enabled security mechanisms. Having credentials split up by mechanism means credentials are maintained per mechanism instead of centrally. Since credentials for HMAC and DTLS are so disparate I don't think there's a chance they could use the same credentials so maintaining per mechanism is ok. I'll make this change.
 
> >    1.   babel-interfaces-obj: Juliusz:"This needs further discussion, I
> >        fear some of these are implementation details."  [In the absence
> >        of discussion, the current model stands.  Note that all but
> >        link-type and the neighbors sub-object are optional; if an
> >        implementation does not have any of the optional elements then
> >        it simply doesn't have them and that's fine.]
> 
> The information currently in the draft (apart from the message log), I also
> added as debug output in Bird, so I think it makes sense to include it. I also
> output current v4/v6 nexthop addresses used for routes announced over
> each interface; may be useful to include, since the mapping from addresses
> assigned to the interface is not always obvious, so may be useful to see what
> a particular implementation picked?

How will this (per interface route next hop) be different from the route object babel-route-next-hop parameter for each announced route? I don't quite understand.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 05 Jun 2018 23:26:32 +0200

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

> Good question. I don't see anything in source-specific that suggests
> different intervals will be used for different destinations, so I
> don't know. What are y'all developers doing? Is it possible that
> y'all's code will cause different Hello intervals to be sent to
> different destinations?

Well, not presently.

> It seems easier to keep this at an interface level, and all the costs
> used to determine an interval are at the interface level.

Sure. But there's nothing in 6126bis that mandates this. So I'm mostly
thinking that maybe the information model is not the place to specify
that this must be the case?

> Also... Right now the neighbor table is only about messages received
> from neighbors and the responses to those messages. Would there be
> concern with assuming neighbors = specific destinations (and using a
> single table for both) -- is there a necessary correlation of
> neighbors to source-specific destinations? Or, if we need to express
> information related to specific destinations, should that be a
> distinct table?

Erm, not sure I'm following here. What's a destination? And what do you
mean by source-specific destination in particular? Are you talking about
the extension, or the 'source' data type in 6126bis?

> Good point. I've added the words "if possible" to the Ethernet frame
> and IP headers clause. I also did this for the credentials log. It's
> definitely desirable.

Cool.

> Why would the value put in the TLV not be available? I could make this
> optional, if it may be hard to record this value when sent. By "expiry
> time" do you mean the current value of the timer, or something else?

Currently, when an IHU packet comes in, I set a timer for when it is
going to expire (say, IHU interval 10 seconds, timer set at T+10s). Now,
if you ask me four seconds later what the IHU interval is, I can only
tell you that I expect another IHU within the next 6 seconds; but not
that the last one was sent four seconds ago.

> What I was trying to get at by knowing the sent IHU TLV interval was
> what this babel instance's expectations were as to how frequent it
> needed to be getting Hellos from this neighbor. Comparing the
> different intervals used for different neighbors on an interface can
> be valuable information in understanding a network, if those intervals
> vary. Or should they vary? I'm not sure how I would use "expiry time"
> or why I should care about it?

Well, the expiry time as explained above is an indicator that tells you
something like, but not the same as, the actual advertised interval.
I.e., when you display the current timers you're basically getting a
random sample in the interval [0;IHU interval sent].

> Hmm. That's a great suggestion. I like that idea. That solves certain
> things that were bothering me. I'll change security to be a separate
> object instance per mechanism. I'll need to move the list of supported
> security mechanisms up to the top level object. But this will let me
> put an enable/disable parameter inside the object and get rid of the
> strange list of enabled security mechanisms. Having credentials split
> up by mechanism means credentials are maintained per mechanism instead
> of centrally. Since credentials for HMAC and DTLS are so disparate I
> don't think there's a chance they could use the same credentials so
> maintaining per mechanism is ok. I'll make this change.

Great!

> How will this (per interface route next hop) be different from the
> route object babel-route-next-hop parameter for each announced route?
> I don't quite understand.

Well it shouldn't be. But there may be configured interfaces that don't
currently export any routes (due to filters, or just if the instance has
just started up). In this case it may be useful to know which address is
going to be used when a route shows up in the future. Also, the
interface next hop value may be configurable (it is in Bird at least).

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 07 Jun 2018 03:43:50 +0200

>> different intervals will be used for different destinations,

Note that this has nothing to do with source-specific, which creates a new
class of routes but doesn't change anything to neighbour discovery.

>> so I don't know. What are y'all developers doing? Is it possible that

> Well, not presently.

The protocol allows it.  We don't have much experience with unicast hellos
yet.

> that this must be the case?

On the other hand, it's an optional field, so an implementation that uses
per-neighbour values can simply omit it.

Barbara, I have no strong feelings either way, but I rather agree with Toke.

>> Or, if we need to express information related to specific destinations,
>> should that be a distinct table?

A destination is either an interface (for a multicast packet) or
a neighbour (for a unicast packet).  Creating a new table for destinations
does not feel right.

(In my implementation, destinations are interfaces and neighbours, as
outlined above, except that both structures delegate common functionality
to a "struct buffered", which would correspond to your intuition of
a destination.  I might rename it to destination.)

> that the last one was sent four seconds ago.

Same here.

>>> The information currently in the draft (apart from the message log),
>>> I also added as debug output in Bird, so I think it makes sense to
>>> include it. I also output current v4/v6 nexthop addresses used for
>>> routes announced over each interface; may be useful to include, since
>>> the mapping from addresses assigned to the interface is not always
>>> obvious, so may be useful to see what a particular implementation
>>> picked?

>> I don't quite understand.

The next hop of a route is the address of the neighbour.  I think that
Toke is speaking about the next-hop address that will be announced to
neighbours, i.e. that will appear in the neighbour's routing table.

-- Juliusz