Re: [babel] Example configuration

[Mahesh Jethanandani <[e-mail]>]

Hi Tote,

> On Aug 8, 2019, at 1:20 PM, Toke Høiland-Jørgensen <[e-mail]> wrote:
>> 
>> While seemingly more complex, it is not. First of all, with your
>> proposed schema, if you need the same presets for multiple interfaces,
>> you would be having to repeat them for multiple interfaces. Secondly,
>> there is no way in YANG to define a set of presets, so there will be
>> no drop down menu to select from.
> 
> These both sound like UI issues rather than configuration protocol
> issues. I'm not familiar with how YANG works, but from this it sounds
> like a UI cannot deviate from what is defined in the YANG model?

YANG is a data modeling language. It models configuration and operational parameters, defining what type of value a particular parameter is. It does not specify a value for them. For example, it models babel-interace-split-horizon parameter as a boolean. Unless a default is desired, it will not even tell you whether the value for split horizon is true or false. That is for the operator or whoever wants to manage the Babel protocol on the device to configure. That is why I said, YANG will not define preset values, for example “wired”, “wireless” or “other" UI. That is up to the operator to define.

> 
>> We were going to document the three or four well known presets.
>> Thirdly, while these names and values may make sense to us, they may
>> not to an operator, who might want to configure their own set of
>> presets.
> 
> But how does this work in the case where nothing is set on the
> management interface, the implementation auto-detect the interface type,
> and fills out the defaults based on the type? As Juliusz explained, the
> preset keyword cannot generally be inferred from the set values, so what
> is the info model / management interface supposed to do in this case?

Let us take two concrete examples. One where the operator has a eth0 interface which is connected to a wired network and does not need any link properties defined, as the implementation knows what to do with a wired interface. The second where it needs to set split horizon to false because the eth1 interface is connected via a bridge to the radio network.

In the first example, and assuming the model Barbara and I suggested, the operator does not need to anything to specify any link properties for eth0. The implementation can pick out the defaults based on the interface type (wired in this case) and use it. 

In the second example, the operator will define a babel-link-properties-obj, call it “radio” or “wireless” or anything they want, and within that object set the babel-interface-metric-algorithm (because it a mandatory parameter), and set the babel-split-horizon to false. They will then associate “radio” object with eth1 interface.

Does that help?

> 
> -Toke

Mahesh Jethanandani
[e-mail]