Re: [babel] Example configuration

[Mahesh Jethanandani <[e-mail]>]

Hi Barbara,

> On Aug 7, 2019, at 6:25 AM, STARK, BARBARA H <[e-mail]> wrote:
> 
>>>> The protocol doesn't know about interface types.  From the point of
>>>> view of the protocol, there are a number of algorithms that can
>>>> optionally be selected or enabled on a given interface.  These include:
>>>> 
>>>> - link-quality estimation (2-out-of-3 or ETX);
>>>> - split-horizon (on or off);
>>>> - RTT estimation (draft-ietf-babel-rtt);
>>>> - use of unicast instead of multicast;
>>>> - ...
>> 
>>> In -08 version of the draft, all references to wired, wireless, tunnel
>>> and others are gone. That in addition to babel-link-properties. If
>>> they are underlying parameters, they are truly invisible :-).
>> 
>> Wired, wireless etc. are the UI interface types.  The underlying properties are
>> link-quality and split-horizon (in RFC 6126bis) and the RTT estimation
>> parameters (in draft-ietf-babel-rtt).
>> 
>>> I understand that it is difficult for an operatori without intimate
>>> knowledge to know how to configure these properties. And that is why
>>> these should be optional properties. However, without them, there is
>>> no way for an operator to influence how the protocol works.
> 
> "Optional property" has different meanings to different people and different data modeling schemes. I've started trying to be very explicit: (1) Does a parameter (YANG leaf) have a universally-agreed default value (e.g., the UDP port)? (2) Can the management system cause an object (YANG leaf-list) instance to be created and some of the parameters (leafs) will be implicitly set to known default values (e.g., the hmac-keys and dtls-certs Booleans)? (3) Are the allowed values for some parameters (leafs) constrained to a specific range, cannot be null, are an enumeration, etc. (e.g., interface metric-algorithm)? (4) If an implementation does not include a particular parameter (leaf), can it still be considered compliant with the info model (in YANG terms: Can a specific Babel implementation have a YANG deviation statement for something and still be compliant with the info model) [this is not directly reflected in the YANG model]?
> 
> In the context of interface metric-algorithm and split-horizon, the management system will never "create" these parameters (because all interface instances are created by the Babel implementation and cannot be created by the management system), and there are no universally-agreed defaults. So (1) and (2) don't apply. The models allow the management system to overwrite the value the implementation chose for the interface. We're constraining the allowed values the management system can use when overwriting these. So (3) applies. The YANG model needs to constrain the value of these sorts of parameters to being in the enumeration, but doesn't need a default.

What I was referring to as “optional property” is more like (4), minus the need to deviate away from the YANG model. They are optional in the sense that a particular Babel implementation will work just fine without having to configure the optional parameters. As an example, if the user/operator wants to change the particular behavior on a particular interface would they need to configure the (optional) link properties. 

BTW, leafs such as link properties are optional to configure, but not optional to support/implement. If the implementation does not want to support/implement, e.g. a particular link property, they would need to deviate what they do not support from the model. 

Hope the distinction between “optional property” and deviation is clear.

> 
>> I think we're not understanding each other.  I am not arguing about hiding
>> any information, quite the opposite, I am in favour of exporting the
>> underlying properties and leaving the link type to the UI.
>> 
>>>> I don't think we have the manpower to do a good job.
>> 
>>> Ok. Let me follow up on the separate e-mail thread that you started
>>> with describing Babel filtering and routing policies. If it becomes
>>> too complex, we can drop it.
>> 
>> Sure, but please keep my comment about manpower in mind.
> 
> 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. 

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?

> 
> For troubleshooting:
> 6. Enables statistics and message log.
> 7. Read statistics and message log.
> 8. Disable statistics and message log.
> 
> Barbara

Mahesh Jethanandani
[e-mail]