Re: [babel] Example configuration

[Toke Høiland-Jørgensen <[e-mail]>]

"STARK, BARBARA H" <[e-mail]> writes:

>> 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. "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.]

Yes. I usually just enable RTT globally :)

> 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.]

Yeah, when we have some more experience with this there will probably be
some relevant settings related to unicast as well...

-Toke