Re: [babel] Example configuration

[Mahesh Jethanandani <[e-mail]>]

Hi Barbara, et. all, 

If you are managing a small number of interfaces (< 10 in my mind), then your approach is simpler. Configure link properties per interface and be done, even if means repeating the configuration on those 10 interfaces.

If we are talking about a larger set, then the complexity might be worth it, simply to allow changes in one place.

The question therefore comes down to, what is the normal number of interfaces a device will configure to run babeld?

Cheers.

> On Aug 13, 2019, at 3:51 PM, STARK, BARBARA H <[e-mail]> wrote:
> 
> I've been ruminating long and hard on this idea of abstracting the link properties.
> I'm thinking this abstraction really is too complex, and I'd prefer to just stick with the properties under interface.
> But, I think it would be reasonable to add language that describes what link characteristics make a particular choice preferred over other choices.
> If a user really wants to change one of these (and Babel is designed not to require manual changes to link properties in most cases), then they just need to know what they're doing. 
> Complexities creep in wrt user language (so users do need to customize the name, which means it can't be immutable), growing permutations as more properties are defined, etc.
> 
> Language I suggest:
> 
>   babel-metric-comp-algorithms:  List of supported cost computation
>      algorithms.  Possible values include "2-out-of-3", and "ETX".
>      "2-out-of-3" (a specific case of K-out-of-j ) link sensing is suitable for wired links that are either
>       up, in which case they only occasionally drop a packet, or down, in
>       which case they drop all packets. "ETX" is a link-quality estimation algorithm that is
>       designed to work well with the IEEE 802.11 MAC.
> 
>   babel-interface-split-horizon:  Indicates whether or not the split
>      horizon optimization is used when calculating metrics on this
>      interface.  A value of true indicates split horizon optimization
>      is used. Split horizon optimization is useful when running over a
>      transitive, symmetric link technology, e.g., a
>      point-to-point link or a wired LAN technology such as Ethernet. 
>      It is not appropriate for links not known to be symmetric and transitive; in particular,
>      split horizon is not appropriate for decentralized wireless link
>      technologies (e.g., IEEE 802.11 in ad hoc mode) when routing updates
>      are sent over multicast.
> 
> Barbara
> 
>>>> 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.
>>> 
>>> Can the UI simulate the babel-link-properties-obj without it being
>>> part of the model?
>> 
>> Before I answer that question, let me know if the following answers help. If
>> they do not, I am afraid that we will need a whiteboard discussion on
>> management interface and the role YANG plays in it.
>> 
>>> 
>>> I.e. the operator defines a set of values called "radio", this set
>>> only exists within the UI.
>> 
>> “radio” in my example is what you call UIs, just like “wireless”. Therefore
>> when you say “set of values called “radio””, I read it as set of link properties
>> that you want to club together and associate with a name, and that name is
>> “radio". Is that correct?
>> 
>>> The operator then applies "radio" to a number of interfaces, and the
>>> frontend applies the individual values contained in the "radio"
>>> dictionary to each of those interfaces.
>> 
>> 
>> But that is exactly what the new babel-link-properties-obj allows you to do. It
>> allows you to define any number of babel-link-properties-obj, and name
>> them whatever you want, e.g. “radio”, “wired”, “wireless” etc, or what you
>> call “UI". In each of the babel-link-properties-obj you set the properties you
>> want, e.g. split horizon, rtt, etc.  As a final step you associate any of the
>> defined UI with any number of interfaces. When you associate the given UI
>> with an interface, all the link properties defined as part of that UI are then
>> applied on the interface.
>> 
>> Did that answer your question, or confuse you even more?
>> 
>>> 
>>> Or does YANG require that the UI reflect the model?
>> 
>>> 
>>> -- Juliusz
>> 
>> Mahesh Jethanandani
>> [e-mail]
>> 
>> 
> 

Mahesh Jethanandani
[e-mail]