Re: [babel] Example configuration

[Mahesh Jethanandani <[e-mail]>]

> On Aug 14, 2019, at 6:50 AM, STARK, BARBARA H <[e-mail]> wrote:
> 
> 
> 
>> From: Toke Høiland-Jørgensen <[e-mail]>
>> Mahesh Jethanandani <[e-mail]> writes:
>> 
>>> Hi Barbara, et. all,
>>> 
>>> If you are managing a small number of interfaces (< 10 in my mind),
>>> then your approach is simpler. Configure link properties per interface
>>> and be done, even if means repeating the configuration on those 10
>>> interfaces.
>>> 
>>> If we are talking about a larger set, then the complexity might be
>>> worth it, simply to allow changes in one place.
>>> 
>>> The question therefore comes down to, what is the normal number of
>>> interfaces a device will configure to run babeld?
>> 
>> For most current Babel deployments I'm familiar with: One or two wireless
>> interfaces and maybe a single wired. Definitely less than 10...
> 
> I agree with Toke. And I think we also need to understand that active configuration in Babel is about handling exceptions to the implemented rules. In almost all cases, the Babel implementation will automatically select the correct link properties for an interface. Only for the small number of cases where the automatic implementation config is wrong will the configuration need to be updated/changed. For example, if I attach a wireless bridge to an Ethernet port of a router, I need to specifically change the link properties for only that one Ethernet interface on that one router.

Ok. Then let us go with link-properties be part of the interface-obj.

> "Repeating" configurations doesn't make sense when active configuration is an exception. I think the normal number of interfaces a *management system* will need to configure is zero.
> 
> When RTT is added as a link property, it too will be auto detected by the fact the interface is a tunnel. [We may want to consider a global configuration option to enable/disable detection of tunneled interfaces and use of RTT -- for cases where RTT support is implemented -- to be defined in the RTT draft.]
> 
> When unicast becomes a property -- well, this is something that a network operator will probably expect to set independent of other "link properties". It isn't really a link property, at all. [We may want a global configuration option for this, too, to indicate whether a new interface is set to default unicast or multicast -- but that's not for now.]
> Barbara

Mahesh Jethanandani
[e-mail]