Re: [babel] Example configuration

[Mahesh Jethanandani <[e-mail]>]

> On Aug 6, 2019, at 12:38 PM, Juliusz Chroboczek <[e-mail]> wrote:
> 
>>> Here's a slightly less minimal configuration:
>>> 
>>> interface eth0
>>> interface eth1 type wireless
>>> interface tun0 type tunnel
> 
> [...]
> 
>>> 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’.
> 
> Hmm.  Draft-ietf-babel-information-model-08 removes the interface type,
> and uses the underlying properties instead.  Shouldn't the YANG model do
> the same, or is there some reason why the YANG model should be using
> interface types instead?

I am still playing catchup with -08 changes in the information model.

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?

> 
>>> interface eth0
>>> interface ppp0 hello-interval 30 update-interval 120
>>> in if ppp0 metric 1024
>>> out if ppp0 metric 1024
> 
>> 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.
> 
> It should be configurable.

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

> 
>> There is no unicast hello interval, which is what I am assuming you mean
>> above.
> 
> No, I mean the multicast interval.
> 
>> Also, there is no metric configuration on an interface today. Certainly
>> not based on in and out traffic.
> 
> The metric configuration is not attached to the interface, it's a filter.
> 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.

In summary, we are looking at the following changes to the information model that will then be followed by updates in the YANG model.

Change babel-mcast-hello-interval and babel-update-interval to rw property.
Add global level filter capability
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.
Add a capability to specify a link-local address for a neighbor.
And whatever comes out of the discussion around underlying property of an interface.

Thanks

> 
> -- Juliusz

Mahesh Jethanandani
[e-mail]