Re: [babel] Example configuration

[Mahesh Jethanandani <[e-mail]>]

Hi Juliusz,

As I said before, thanks for these examples. They truly will help anyone trying to configure babel using NETCONF/YANG.

See inline.

> On Jul 25, 2019, at 2:51 PM, Juliusz Chroboczek <[e-mail]> wrote:
> 
>> In my presentation on the YANG model for Babel, I asked for help in
>> trying to improve the example configuration of Babel. The example was
>> shown in XML, but that does not mean I am expecting anyone to help me
>> improve the example in XML.
> 
> I'll use the syntax of the babeld configuration file.
> 
> Here's a pretty minimal config:
> 
>  interface eth0
>  interface wlan0
> 
> This says to run Babel on interfaces eth0 and wlan0.  Babeld will
> automatically detect that eth0 is wired and wlan0 is wireless, and will
> configure the right parameters automatically.

The XML encoding of the above example can be found in example-babel-configuration-2.4.xml which is attached to this e-mail.

> 
> Here's a slightly less minimal configuration:
> 
>  interface eth0
>  interface eth1 type wireless
>  interface tun0 type tunnel
> 
> Here, interface eth1 is an Ethernet bridged to a wireless radio, so
> babeld's autodetection fails, and the interface type needs to be
> configured manually.  Tunnels are not detected automatically, so this
> needs to be specified.
> 
> This is equivalent to the following:
> 
>  interface eth0
>  interface eth1 link-quality true split-horizon false
>  interface tun0 enable-timestamps true max-rtt-penalty 96

The XML encoding of the above example can be found in example-babel-configuration-2.5.xml. You will notice that eth1 type is set to ‘wireless’ using ‘link-properties’. Same for tun0 and ‘tunnel’.

> 
> Here's another configuration:
> 
>  interface eth0
>  interface ppp0 hello-interval 30 update-interval 120
>  in if ppp0 metric 1024
>  out if ppp0 metric 1024
> 
> Here, ppp0 is a metered 3G link used for fallback connectivity.  It runs
> with much higher than default time constants in order to avoid control
> traffic as much as possible, and the metric of routes through that link
> are increased so that they are not used unless all other options fail.

Here is where I am stuck. Currently, there is a babel-mcast-hello-interval parameter defined in the information model under the interface. But this a read-only attribute, meaning it is a operational value, not a configuration value. There is no unicast hello interval, which is what I am assuming you mean above. So the question is, do we need one, and if it is configurable parameter, it needs to read-write. Secondly, babel-update-interval is also an read-only (operational) parameter, therefore cannot be configured. If this needs to be a configurable parameter, the information model will need to be updated.

Also, there is no metric configuration on an interface today. Certainly not based on in and out traffic. If we need to add it, the information model needs to be updated.

> 
> Here's a configuration for David:
> 
>  interface eth0
>  interface wlan0 unicast true
> 
> This requests that all control traffic other than Hellos on the wlan0
> interface be sent as unicast.  This can be useful when wlan0 uses
> a technology on which multicast is prohibitively expensive.

Currently, we have no way to configure an interface to send unicast traffic in a preferred manner. If this is required, we will need to update the babel-interface-obj in the information model. I also notice something called unicast-only, which by its name tells me send unicast traffic only. Also not in the information model.

> 
> Another one:
> 
>  interface atm0 split-horizon false unicast true

Currently, I can configure the interface for split-horizon, but cannot configure it for unicast traffic. Looks like we need this to be added.

> 
> Here, atm0 is an NBMA interface.  Transitive connectivity is not
> guaranteed, so we disable the split-horizon optimisation.  Unicast is to
> be preferred to multicast whenever possible.
> 
> Here is a configuration that is not yet implemented, but planned for
> a future version:
> 
>  interface wg0 unicast-only true
>  neighbour fe80::1234 if wg0
> 
> Here, wg0 is a Wireguard tunnel, and doesn't support multicast at all.
> All traffic over that interface is sent as unicast, so automatic discovery
> is not possible.  Thus, we need to specify the link-local addresses of
> neighbours manually.

Again, this is something that the current information model does not support. If we need to be able to specify a link-local address for a neighbor, the information model will need to be updated. That command also needs to specify which interface the link local address needs to be associated with.

> 
> Hope this helps,

Yes, it does. And plenty!

> 
> -- Juliusz
> 
> 

Mahesh Jethanandani
[e-mail]