Re: [babel] Example configuration

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

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

> What I had in mind for the updates to the information model are step 5. If the operator needs to update link-quality, or flip on split-horizon, or set a RTT estimate value, or specify whether they want to use unicast instead of multicast, or any combination thereof for a particular interface, they would create a new babel-link-properties object and associate that with the interface.
>
> Can we agree on the changes to the information model I suggested yesterday?
>
> <bhs> Let me see if I understand... Does it have to be a “new” babel-link-properties instance, or can it be one that exists?
>
> That is, if we had an object called babel-link-properties
>      object {
>           string                rw babel-link-properties-name;
>           [string               rw babel-interface-metric-algorithm;]
>           [boolean               rw babel-interface-split-horizon;]
>           [boolean               rw babel-interface-rtt;]
>           [boolean               rw babel-interface-unicast;]
>       } babel-hmac-keys-obj babel-link-properties;
>
> [mj] with the corrections marked in red.
> <bhs> I think babel-interface-metric-algorithm is “mandatory in the sense it must be implemented and expressed to be compliant with the info model”. So I disagree with the square brackets for that one. The existence of the metric-algorithm is reasonably normative in rfc6126bis. The possible enumerations aren’t normative, but that’s not what the square brackets mean. At least one metric calculation algorithm must be implemented and it must be given a name and expressed to be compliant with the info model. I see rfc6126bis has split horizon as “SHOULD” (Babel node SHOULD use an optimisation known as split horizon), so I agree with square brackets for that. The other 2 aren’t actually going in at this time, so there’s no dependency on their drafts. They need to mention what data elements they need in those drafts. And, yeah, I’m sloppy with cut and paste.
>
> Where the implementation may create some set of initial entries that its developers have decided to e.g. name “wired”, “wireless”, “tunnel” (but some other implementation may give a different name to the same group of parameter values). link-properties-name must be unique (and not empty or NULL), but also no 2 instances are allowed to have the same set of values for the latter 4 parameters. Once an instance is created it cannot be modified. If it is referenced from an interface or was created by the implementation, it cannot be deleted. This makes instances created by the implementation immutable.
> This object can be written (new instances created with different combinations of values and a different name, like “unicast-wired”).
> An interface will have a reference to one of these instances, to identify the set of link-properties it uses. It’s allowed to modify which set of link-properties is used/referenced by an interface.
>
> Is that right? And did you say you wanted it under interface or under the base? I think it would make sense under base. Juliusz, I think this approach (if it’s what Mahesh meant) would provide the benefits of allowing users to use more meaningful names for groups of link properties, allow use of names that babeld has already popularized among its users while allowing other implementations to use different names (names aren’t standardized), and isn’t very complicated. It does make it harder if the user wants to just change one of the link properties and not others (they might have to create a new instance). But it makes it easier for the user who wants to change from one grouping of properties to another.
>
> [mj] Yes, that is what the intention of the change was. Note, I did want instances of babel-link-properties to exist under the base (babel-informtion-obj). In babel-interface-obj we only reference one of those instances:
>
> object {
>           ….
>           [babel-link-properties   rw babel-link-properties<0..*>;]
>
> } babel-information-obj;
>
> object {
>          [reference                      rw  babel-link-properties;]
>           …..
> } babel-interface-obj;
>
> <bhs> OK. I was too lazy to search for the exact proposal, so I was just going by memory. But I think babel-link-properties needs to be <1..*>. Babel is dead in the water if it doesn’t have at least one means of calculating metrics.
> Juliusz, does this make sense and are you ok with it?

Why is this complexity needed? Couldn't it just be solved in the user
interface, something like:

An input form contains these four entries:
          [string               rw babel-interface-metric-algorithm;]
          [boolean               rw babel-interface-split-horizon;]
          [boolean               rw babel-interface-rtt;]
          [boolean               rw babel-interface-unicast;]

Underneath those four input boxes is another dropdown box (or whatever)
with the presets ("wireless", "wired", "tunnel", etc). Selecting one of
these just fills in the preset values into the four input boxes above
it, which the user can then either just accept, or change individual
values as he or she pleases.

This way, the information model doesn't need to know anything about the
groups or preset names, it just carries the values...

-Toke