Re: [babel] Example configuration

[Juliusz Chroboczek <[e-mail]>]

> I am also not clear on the underlying properties. If the interface is eth1,
> its underlying property will be of a wired 802.3 like interface. I thought the
> whole idea of specifying the type was an indication that eth1 is an Ethernet
> bridged to a wireless radio. How would you derive a ‘wireless’ like
> information from the underlying property?

The protocol doesn't know about interface types.  From the point of view
of the protocol, there are a number of algorithms that can optionally be
selected or enabled on a given interface.  These include:

  - link-quality estimation (2-out-of-3 or ETX);
  - split-horizon (on or off);
  - RTT estimation (draft-ietf-babel-rtt);
  - use of unicast instead of multicast;
  - ...

The choice of parameters requires intimate knowledge of the protocol and
the implementation.  For that reason, the babeld implementation packages
useful combinations within the interface type parameter

  "type wired" is a shortcut for "link-quality 2-out-of-3 split-horizon true"
  "type wireless" is a shortcut for "link-quality etc split-horizon false"
  "type tunnel" is a shortcut for "link-quality 2-out-of-3 max-rtt-penalty 96"

However, other combinations are possible, and some of them are actually
useful -- "link-quality 2-out-of-3 split-horizon false" makes perfect
sense for an NBMA network.  Therefore, the interface type cannot in
general be synthesized from the configuration parameters of the interface.

So what's the information model to do?  My opinion is to consider the
interface type as a UI issue, and put the underlying parameters in the
information model, which is what Barbara has implemented in -08.  Other
solutions are possible, of course, and I'm quite open to considering them
if someone has a plan.

> Just to confirm. Both babel-mcast-hello-interval and babel-update-interval
> need to be read-write (configurable) properties.

Aye.

>     Filters are a separate kind of entity, and need not contain an interface
>     entry.  For example, one may say

>      in ip 10.0.0.0/8 metric 128

>     in which case the filter applies to all routes with a destination in 10/8.

> In other words, a global configuration that applies across all routes with
> that destination. I am not aware of any way to do this with our current
> information model. We are looking at an addition to the information model.

Here's what other YANG models do:

  - the RIP YANG model ignores filtering, although most RIP
    implementations support it;
  - the BGP YANG model imports draft-ietf-rtgwg-policy-model.

I suggest we follow the lead of RIP, and consider filtering as out of
scope for the YANG model.  Filtering is a complex beast, it tends to grow
over time (it's the cleanest place to add implementation-specific hooks),
and I don't think we have the manpower to do a good job.

> * Change babel-mcast-hello-interval and babel-update-interval to rw property.

Yes.

> * Add global level filter capability

Not necessarily.  See above.

> * Add a way to mark an interface for unicast-preferred (please feel free to
>   suggest a better name), and unicast-only as boolean configurable properties.

Babeld calles the former simply "unicast".  The latter is not implemented
yet, so please don't define it yet, it might never happen.

> * Add a capability to specify a link-local address for a neighbor.

Not quite -- it's about defining a static neighbour for unicast-only
operation.  Again, it might never happen.

-- Juliusz