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

From: [email-masked]
Date: Sun, 04 Aug 2019 18:47:04 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Babel routing protocol WG of the IETF.

        Title           : Babel Information Model
        Authors         : Barbara Stark
                          Mahesh Jethanandani
	Filename        : draft-ietf-babel-information-model-08.txt
	Pages           : 28
	Date            : 2019-08-04

Abstract:
   This Babel Information Model can be used to create data models under
   various data modeling regimes.  It allows a Babel implementation (via
   a management protocol or interface) to report on its current state
   and may allow some limited configuration of protocol constants.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-babel-information-model-08
https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 Aug 2019 15:46:18 +0000

Hi babel WG and chairs,
I've posted a -08 (without consulting Mahesh, but it just has the items agreed on in Montreal).
I'd like to start another WGLC now, please?

One thing I still want to get better is the language in babel-route-received-metric and babel-route-calculated-metric around using something other than an unsigned int in case something has to be done to represent NULL (vs. zero). The proposed (in Montreal) language is in babel-route-calculated-metric and a slightly different way of wording it is in babel-route-received-metric. If you like one better than the other let me know (I'm leaning towards my different wording). I'm also going to ask my BBF friends if they have a suggestion for clearly wording this (since that's where the problem is coming from).

I also noticed after posting that I failed to update the list of configurable parameters in the Overview (Section 2). I'll fix that after WGLC, if that's ok. Specifically, "create/delete babel-hmac objects" and "create/delete babel-dtls objects" should be "create/delete HMAC key sets" and "create/delete DTLS certificate sets", and "Interface: Link type" gets replaced with "interface: Metric algorithm" and "interface: Split horizon".
Barbara

> -----Original Message-----
> From: babel <[email-masked]> On Behalf Of internet-
> [email-masked]
> Sent: Sunday, August 04, 2019 9:47 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [babel] I-D Action: draft-ietf-babel-information-model-08.txt
> 
>

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 5 Aug 2019 22:09:40 -0400

Hi,

A WG Last Call was issued some time ago for
draft-ietf-babel-information-model-01.txt. There was no consensus on
the mailing list although the Last Call was not formally closed at
that time. The draft has been significantly modified since then. So,
this message is the start of a 2nd WG Last Call, running through
August 21st, 2019, this time on
draft-ietf-babel-information-model-08.txt

Thanks,
Donald

PS: This call is for a little longer than two weeks because, although
I plan to monitor email, I will be traveling 13-20 August.
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

On Mon, Aug 5, 2019 at 11:47 AM STARK, BARBARA H <[email-masked]> wrote:
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 22:04:47 +0200

# Section 1.

"one of these security mechanisms" -> "one or both of these security mechanisms"

"(contingent on a management protocol with Babel support being implemented)"
I don't know what this means

"a referential [...] structure."  I don't know what this means

# Section 3.2

"Default is ff02:0:0:0:0:0:1:6".  Why not write this as ff02::1:6, as is usual?

# Section 3.3

The metric computation algorithm is described twice, here and globally in
the babel-information-obj.  Is the global value a default for newly
created interfaces, or does it provide a value in case the interface-obj
doesn't specify it?  Please clarify.

The same goes for babel-hmac-algorithm.

# Section 3.4

Aren't we missing an entry for the total number of packets sent?

Should these entries be optional?

# Section 3.5

I don't think that the nbr-stats entries is useful.  A neighbour is
a transient data structure, and neighbours get destroyed when they become
unreachable.  Thus, there is no good place to persist the statistics.
I suggest moving all statistics into the interface-obj, and not keeping
per-neighbour stats.

babel-exp-{m,u}cast-hello-seqno: the use of 0 for undefined is not a good
idea, since 0 is a perfectly valid seqno.

babel-ucast-hello-seqno: what's the value when the implementation is not
sending unicast hellos?

babel-cost: this is written in a different style.  I suggest something
like "the link cost, as computed from...".

# Section 3.6

See above.  I suggest moving this into the interface-stats object, and
only keeping aggregate statistics.

# Section 3.7

babel-route-router-id: suggst "the router-id of the router that originated
this route".

# Section 3.9

babel-key-use-{sign, verify}: good idea, I'll add this to the implementation.

babel-hmac-test: why non-empty?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 22:10:24 +0200

Sections 3.1 and 3.3 -- please remove the hmac-algorithm.

The algorithm is a property of a key, not of an interface.  There's no
need to specify the algo here, it is determined by the set of configured
keys.  (And it is quite legal to use keys with different algos on the same
interface, for example when transitioning from one algorithm to
a different one.)

The second point is something we've discussed before.  The implementation
has the interface point at the set of keys; in the model, the key set
points at the interface.  Is the discrepancy intentional?

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 13:08:47 +0000

> The algorithm is a property of a key, not of an interface.  There's no need to
> specify the algo here, it is determined by the set of configured keys.  (And it
> is quite legal to use keys with different algos on the same interface, for
> example when transitioning from one algorithm to a different one.)

In that case, the MAC algorithm needs to associated with keys (add key-mac-algorithm parameter to babel-hmac-keys-obj).
And I'll be changing all "hmac" to "mac" in the model.
 
> has the interface point at the set of keys; in the model, the key set points at
> the interface.  Is the discrepancy intentional?

I don't see where a key set points to the interface? I only see where the interface points to a set of keys:
---------------------------------
3.3.  Definition of babel-interfaces-obj
     object {
...
         [reference            rw babel-if-hmac-key-sets<0..*>;]
...
         [reference            rw babel-if-dtls-cert-sets<0..*>;]
----------------------------------
There is the Boolean parameter in the key set object that indicates whether it is automatically applied to a new interface. But that's not a pointer to any existing interface.

Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Aug 2019 17:01:07 +0200

>> The second point is something we've discussed before.  The
>> implementation has the interface point at the set of keys; in the
>> model, the key set points at the interface.  Is the discrepancy
>> intentional?

> the interface points to a set of keys:

Section 3.8:

   babel-hmac-interfaces:  List of references to the babel-interfaces
      entries this babel-hmac entry applies to.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 16:02:40 +0000

>       entries this babel-hmac entry applies to.

I don't see that in -08

Where are you looking? My github is behind datatracker, right now -- are you looking there?
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Aug 2019 19:11:12 +0200

> https://tools.ietf.org/html/draft-ietf-babel-information-model-08

My bad -- I've been a victim of a bug in the tools website.

(For some reason, if you click on -05, then there are no later versions
displayed, so it looks like -05 is the latest version.)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 21:59:05 +0000

> "one of these security mechanisms" -> "one or both of these security

Done
 
> I don't know what this means

If your Babel implementation has a data model and you want to claim compliance with the info model, then you must have these parameters.
I didn't want this concept confused with the idea that if you do a Babel implementation you have to implement a data model that is compliant with the info model. That would be wrong.
And I didn't want it confused with the idea that the parameters must have values (cannot be NULL).
Mahesh and I have had a lot of discussion over what MTI in this draft means, so I was trying to explain it better. But I agree I still didn't get it right.
I suggest changing this parenthetic to "(for an implementation attempting to comply with this information model)"

> "a referential [...] structure."  I don't know what this means

For example, SQL uses a purely referential structure for its data (each table is stand-alone, and they are linked through means of foreign keys), rather than hierarchical. It would be possible to create a SQL data model from this (mostly) hierarchical info model.
Should something change here?
 
> "Default is ff02:0:0:0:0:0:1:6".  Why not write this as ff02::1:6, as is usual?

I think I just copied it from somewhere (like the IANA IPv6 multicast address registry). But I'm fine with the shorter version.
Done.

> # Section 3.3
> 
> The metric computation algorithm is described twice, here and globally in the
> babel-information-obj.  Is the global value a default for newly created
> interfaces, or does it provide a value in case the interface-obj doesn't specify
> it?  Please clarify.

The global parameter is a read-only list of algorithms supported by the implementation. It's used to constrain the value in interfaces. The initial value used for an interface will always be set by an implementation, using whatever logic is internal to the implementation. But whatever value the implementation uses needs to be in the global list of supported algorithms. It's also allowed for the implementation to let a user change the value set by the implementation -- in which case the user needs to know the allowed set of values it can be changed to (and constrained to setting it to a supported algorithm).

> The same goes for babel-hmac-algorithm.

Similar answer. But since the parameter is moving from interfaces to mac-keys (so it can be specific to a key), it won't be set by the implementation. It's set by the user when adding the key. But it still needs to be constrained to an algorithm the implementation supports (as indicated by the list in the global parameter).
[Also: changing the babel-mac-algorithm, per decision to make hmac draft a mac draft.]

> Aren't we missing an entry for the total number of packets sent?

So in addition to totals of multicast hellos and updates separately, include a total of all Babel packets sent on the interface? I could add that, if people think it would be useful. I'm going to hold off on adding this to see if anyone else has an opinion. I think if this were done, it doesn't make sense to require the more granular "sent" counts (if statistics are implemented). They would become optional. But I think seeing counts for hellos and updates separately is more useful for seeing how the implementation is behaving. And if you have those counts, the combined count provides no additional value. So I'm sort of conflicted.

> Should these entries be optional?

Having the babel-if-stats-obj is optional (under interfaces). But if the implementation has the babel-if-stats-obj, then I think all 3 of these statistics should be required. 
 
> # Section 3.5
> 
> I don't think that the nbr-stats entries is useful.  A neighbour is a transient
> data structure, and neighbours get destroyed when they become
> I suggest moving all statistics into the interface-obj, and not keeping per-
> neighbour stats.

I'm fine with that. That would suggest putting optional babel-sent-ucast-hello, babel-sent-ucast-update, and babel-sent-IHU under the interfaces statistics (where all 3 are totals sent to all neighbors on the interface). The 3 received statistics parameters go away (babel-received-hello, babel-received-update, babel-received-IHU). Do others have opinions? If no-one says otherwise, I'll do this.
 
> idea, since 0 is a perfectly valid seqno.

OK. Then this goes in the same bucket as the other read-only int parameters that need to have a NULL distinct from zero. Is the following ok?

      Expected {m,u}cast Hello sequence
      number of next Hello to be received from this neighbor. 
      If {m,u}cast Hello packets are not expected, or processing of
      {m,u}cast packets is not enabled, this MUST be NULL. This is a 16-bit unsigned
      integer; if the data model uses zero (0) to represent NULL values
      for unsigned integers, the data model may use a different data
      type that allows differentiation between zero (0) and NULL.

> babel-ucast-hello-seqno: what's the value when the implementation is not

Same sort of thing?

      The current sequence number in use for
      unicast Hellos sent to this neighbor.  If unicast Hellos are not being sent,
      this MUST be NULL.  This is a 16-bit unsigned
      integer; if the data model uses zero (0) to represent NULL values
      for unsigned integers, the data model may use a different data
      type that allows differentiation between zero (0) and NULL.

> babel-cost: this is written in a different style.  I suggest something like "the
> link cost, as computed from...".

OK
 
> # Section 3.6
> 
> See above.  I suggest moving this into the interface-stats object, and only
> keeping aggregate statistics.

As above discussed above, then.
 
> # Section 3.7
> 
> babel-route-router-id: suggst "the router-id of the router that originated this
> route".

OK
 
> babel-key-use-{sign, verify}: good idea, I'll add this to the implementation.

Thank you. I took the idea from the babel-hmac spec. And Toke refined it.

> babel-hmac-test: why non-empty?

If there's no mac algorithm that will choke on zero-length input string, then I guess empty is ok. I'm thinking I won't have issues with NULL/zero/empty ambiguity, since it's a binary string.
So just change that sentence to "Input to this operation is a binary string." (instead of "Input to this operation MUST be a non-empty binary string.")? Same for the babel-cert-test? Unless I hear otherwise, I'll do the same change to both.

Barbara