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

From: [email-masked]
Date: Tue, 02 Jan 2018 12:57:40 -0800

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
        Author          : Barbara Stark
	Filename        : draft-ietf-babel-information-model-01.txt
	Pages           : 10
	Date            : 2018-01-02

Abstract:
   This Babel Information Model can be used to create data models under
   various data modeling regimes (e.g., YANG).  It allows a Babel
   implementation (via a management protocol such as netconf) 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-01
https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-01

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

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: Tue, 2 Jan 2018 21:02:40 +0000

I've updated the info model draft. I put some actual effort into it, this time, since babelbis is getting close to done. I added some tables for basic support of security mechanisms. I fixed up data types. Still need to think about collection of statistics. I may be able to get that added by draft deadline, but input is welcome. There are some open issues listed at the end.
Barbara

-----Original Message-----

Abstract:

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 03 Jan 2018 17:52:33 +0100

Section 2.1.

> string                babel-implementation-version;
[...]
> babel-version: the version of this implementation...

Slight inconsistency here.

> babel-self-seqno: the current sequence number included in route updates
> for routes originated by this node

Hmm... in principle, a Babel implementation could use a different seqno
for different routes.  Since this is optional, that's fine, but perhaps it
might be useful to add a note to this effect.

Section 2.3.

> babel-interface-seqno: the current sequence number in use for this
> interface

This is obsolete with rfc6126bis.  Instead, we need two fields --
babel-interface-multicast-hello-seqno and babel-interface-unicast-hello-seqno,
both of them optional.

Same for the Hello interval, it needs to be split in two.

> babel-request-trigger-ack

Please flush this field.  It's an implementation detail, and I'd expect
that an actual implementation would use an adaptative algorithm.

> babel-external-cost

This needs more work, I think.

Section 2.4

I'm missing a local interface -- the same remote IP can be a neighbour
multiple times, over multiple local interfaces.

> babel-router-id: router-id of the neighbor

This is not known in general -- if a neighbour doesn't originate any
routes, its router-id is unknown.  Please flush that field.

Suggest adding an optional "babel-cost" field, since the spec does not
define how exactly the cost is computed from rxcost/txcost.

Section 2.6

> babel-source-garbage-collection-time

Suggest flushing this field, it's an implementation detail.

Section 2.7

> babel-route-neighbor: neighbor that advertised this route (is this
> a router-id ?)

No, it's a pair of a local interface and a (link-local) IP address.  (A
single router can appear as multiple neighbours, if either the local or
the remote have multiple interfaces.)  See my comment above in Section 2.4.

Appendix A.

> babel-self-router-id: Should this be an opaque 64-bit value instead of int?

Yes, I think so.

> Would it be useful to define any of the following as per-interface constants

Tricky.

-- Juliusz