Re: [babel] Example configuration

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

I think the problem we're facing is that Babel implementations are perfectly capable of operating well without being explicitly configured (other than enabling/disabling it). Babel is specifically designed that way. But that doesn't necessitate "hiding" things.

Here is what I think would be common "configuration" scenarios:
- The most common "configuration" would be to simply enable Babel.
- The next most common configuration would be to enable/disable it on specific interfaces (using the enable parameter in babel-interfaces). This may be done at the same time Babel is enabled (if the Babel implementation creates the interfaces instances even though Babel isn't enabled). Or later. It may need to be a separate configuration call, because the Babel implementation may not create the interfaces instances unless it is enabled. If it is a separate configuration call, the operator will probably need to read the configuration first, to see what interfaces Babel has identified it can run on, and which of these it has auto-enabled / auto-disabled.
- The next thing someone would want to do is not configuration, but just reading info about the status of Babel. Some of the expressed status is the metric-algorithm (not link-quality, which is not a parameter) and split-horizon (true/false as to whether it's used) that was selected by the implementation for use on each interface. The Babel model is small enough that the person would probably find it easiest just to ask for everything.
- It's possible that in looking at the status, the operator doesn't like the choices the implementation made wrt metric-algorithm or split-horizon, for an interface. The operator needs to have the ability to change those choices. The values the operator can change to are constrained.
- It's possible that in looking at the status, the operator thinks things don't look right and wants to troubleshoot by getting more detailed statistics and maybe even a message log. So the operator enables statistics and message log. The operator waits a few seconds and reads statistics and the message log. Maybe the operator does something that fixes the problem. The operator then disables statistics and message log.

So maybe the "example configuration" is a sequence of YANG messages:
1. Enable Babel
2. Read the interfaces leaf-list.
3. Enable/disable Babel on specific interfaces, as desired.
4. Read everything.
5. Update metric-algorithm and split-horizon values for a specific interface.

This is a perfectly valid sequence of RPC (not YANG) messages that are exchanged.

<bhs> Not necessarily RPC. I was thinking of it more in terms of what a user might be trying to do, independent of how the thing the user wants to do is communicated or transported.

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;

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