Re: [babel] Example configuration

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

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?


Barbara

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>