Subject: Re: [babel] Example configuration

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 6 Aug 2019 12:04:13 -0700

Hi Juliusz,

As I said before, thanks for these examples. They truly will help anyone trying to configure babel using NETCONF/YANG.

See inline.

> On Jul 25, 2019, at 2:51 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 
>> In my presentation on the YANG model for Babel, I asked for help in
>> trying to improve the example configuration of Babel. The example was
>> shown in XML, but that does not mean I am expecting anyone to help me
>> improve the example in XML.
> 
> I'll use the syntax of the babeld configuration file.
> 
> Here's a pretty minimal config:
> 
>  interface eth0
>  interface wlan0
> 
> This says to run Babel on interfaces eth0 and wlan0.  Babeld will
> automatically detect that eth0 is wired and wlan0 is wireless, and will
> configure the right parameters automatically.

The XML encoding of the above example can be found in example-babel-configuration-2.4.xml which is attached to this e-mail.

> 
> Here's a slightly less minimal configuration:
> 
>  interface eth0
>  interface eth1 type wireless
>  interface tun0 type tunnel
> 
> Here, interface eth1 is an Ethernet bridged to a wireless radio, so
> babeld's autodetection fails, and the interface type needs to be
> configured manually.  Tunnels are not detected automatically, so this
> needs to be specified.
> 
> This is equivalent to the following:
> 
>  interface eth0
>  interface eth1 link-quality true split-horizon false
>  interface tun0 enable-timestamps true max-rtt-penalty 96

The XML encoding of the above example can be found in example-babel-configuration-2.5.xml. You will notice that eth1 type is set to ‘wireless’ using ‘link-properties’. Same for tun0 and ‘tunnel’.

> 
> Here's another configuration:
> 
>  interface eth0
>  interface ppp0 hello-interval 30 update-interval 120
>  in if ppp0 metric 1024
>  out if ppp0 metric 1024
> 
> Here, ppp0 is a metered 3G link used for fallback connectivity.  It runs
> with much higher than default time constants in order to avoid control
> traffic as much as possible, and the metric of routes through that link
> are increased so that they are not used unless all other options fail.

Here is where I am stuck. Currently, there is a babel-mcast-hello-interval parameter defined in the information model under the interface. But this a read-only attribute, meaning it is a operational value, not a configuration value. There is no unicast hello interval, which is what I am assuming you mean above. So the question is, do we need one, and if it is configurable parameter, it needs to read-write. Secondly, babel-update-interval is also an read-only (operational) parameter, therefore cannot be configured. If this needs to be a configurable parameter, the information model will need to be updated.

Also, there is no metric configuration on an interface today. Certainly not based on in and out traffic. If we need to add it, the information model needs to be updated.

> 
> Here's a configuration for David:
> 
>  interface eth0
>  interface wlan0 unicast true
> 
> This requests that all control traffic other than Hellos on the wlan0
> interface be sent as unicast.  This can be useful when wlan0 uses
> a technology on which multicast is prohibitively expensive.

Currently, we have no way to configure an interface to send unicast traffic in a preferred manner. If this is required, we will need to update the babel-interface-obj in the information model. I also notice something called unicast-only, which by its name tells me send unicast traffic only. Also not in the information model.

> 
> Another one:
> 
>  interface atm0 split-horizon false unicast true

Currently, I can configure the interface for split-horizon, but cannot configure it for unicast traffic. Looks like we need this to be added.

> 
> Here, atm0 is an NBMA interface.  Transitive connectivity is not
> guaranteed, so we disable the split-horizon optimisation.  Unicast is to
> be preferred to multicast whenever possible.
> 
> Here is a configuration that is not yet implemented, but planned for
> a future version:
> 
>  interface wg0 unicast-only true
>  neighbour fe80::1234 if wg0
> 
> Here, wg0 is a Wireguard tunnel, and doesn't support multicast at all.
> All traffic over that interface is sent as unicast, so automatic discovery
> is not possible.  Thus, we need to specify the link-local addresses of
> neighbours manually.

Again, this is something that the current information model does not support. If we need to be able to specify a link-local address for a neighbor, the information model will need to be updated. That command also needs to specify which interface the link local address needs to be associated with.

> Hope this helps,

Yes, it does. And plenty!

> -- Juliusz

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 21:38:53 +0200

>> interface tun0 type tunnel

[...]

> The XML encoding of the above example can be found in
> example-babel-configuration-2.5.xml. You will notice that eth1 type is
> set to ‘wireless’ using ‘link-properties’. Same for tun0 and ‘tunnel’.

Hmm.  Draft-ietf-babel-information-model-08 removes the interface type,
and uses the underlying properties instead.  Shouldn't the YANG model do
the same, or is there some reason why the YANG model should be using
interface types instead?

> Here is where I am stuck. Currently, there is
> a babel-mcast-hello-interval parameter defined in the information model
> under the interface. But this a read-only attribute, meaning it is
> a operational value, not a configuration value.

It should be configurable.

> There is no unicast hello interval, which is what I am assuming you mean
> above.

No, I mean the multicast interval.

> Also, there is no metric configuration on an interface today. Certainly
> not based on in and out traffic.

The metric configuration is not attached to the interface, it's a filter.
Filters are a separate kind of entity, and need not contain an interface
entry.  For example, one may say

  in ip 10.0.0.0/8 metric 128

in which case the filter applies to all routes with a destination in 10/8.

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 6 Aug 2019 13:12:29 -0700

> On Aug 6, 2019, at 12:38 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

I am still playing catchup with -08 changes in the information model.

I am also not clear on the underlying properties. If the interface is eth1, its underlying property will be of a wired 802.3 like interface. I thought the whole idea of specifying the type was an indication that eth1 is an Ethernet bridged to a wireless radio. How would you derive a ‘wireless’ like information from the underlying property?

> It should be configurable.

Just to confirm. Both babel-mcast-hello-interval and babel-update-interval need to be read-write (configurable) properties.

> in which case the filter applies to all routes with a destination in 10/8.

In other words, a global configuration that applies across all routes with that destination. I am not aware of any way to do this with our current information model. We are looking at an addition to the information model.

In summary, we are looking at the following changes to the information model that will then be followed by updates in the YANG model.

Change babel-mcast-hello-interval and babel-update-interval to rw property.
Add global level filter capability
Add a way to mark an interface for unicast-preferred (please feel free to suggest a better name), and unicast-only as boolean configurable properties.
Add a capability to specify a link-local address for a neighbor.
And whatever comes out of the discussion around underlying property of an interface.

Thanks

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 23:31:13 +0200

> I am also not clear on the underlying properties. If the interface is eth1,
> its underlying property will be of a wired 802.3 like interface. I thought the
> whole idea of specifying the type was an indication that eth1 is an Ethernet
> bridged to a wireless radio. How would you derive a ‘wireless’ like
> information from the underlying property?

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

The choice of parameters requires intimate knowledge of the protocol and
the implementation.  For that reason, the babeld implementation packages
useful combinations within the interface type parameter

  "type wired" is a shortcut for "link-quality 2-out-of-3 split-horizon true"
  "type wireless" is a shortcut for "link-quality etc split-horizon false"
  "type tunnel" is a shortcut for "link-quality 2-out-of-3 max-rtt-penalty 96"

However, other combinations are possible, and some of them are actually
useful -- "link-quality 2-out-of-3 split-horizon false" makes perfect
sense for an NBMA network.  Therefore, the interface type cannot in
general be synthesized from the configuration parameters of the interface.

So what's the information model to do?  My opinion is to consider the
interface type as a UI issue, and put the underlying parameters in the
information model, which is what Barbara has implemented in -08.  Other
solutions are possible, of course, and I'm quite open to considering them
if someone has a plan.

> Just to confirm. Both babel-mcast-hello-interval and babel-update-interval
> need to be read-write (configurable) properties.

Aye.

> In other words, a global configuration that applies across all routes with
> that destination. I am not aware of any way to do this with our current
> information model. We are looking at an addition to the information model.

Here's what other YANG models do:

  - the RIP YANG model ignores filtering, although most RIP
    implementations support it;
  - the BGP YANG model imports draft-ietf-rtgwg-policy-model.

I suggest we follow the lead of RIP, and consider filtering as out of
scope for the YANG model.  Filtering is a complex beast, it tends to grow
over time (it's the cleanest place to add implementation-specific hooks),
and I don't think we have the manpower to do a good job.

> * Change babel-mcast-hello-interval and babel-update-interval to rw property.

Yes.

> * Add global level filter capability

Not necessarily.  See above.

> * Add a way to mark an interface for unicast-preferred (please feel free to
>   suggest a better name), and unicast-only as boolean configurable properties.

Babeld calles the former simply "unicast".  The latter is not implemented
yet, so please don't define it yet, it might never happen.

> * Add a capability to specify a link-local address for a neighbor.

Not quite -- it's about defining a static neighbour for unicast-only
operation.  Again, it might never happen.

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 6 Aug 2019 17:19:39 -0700

> On Aug 6, 2019, at 2:31 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

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 :-). That means there is no way to specify most of the link properties that you describe above, with the exception of split-horizon, which is lone link property under babel-interace-obj.

I understand that it is difficult for an operator 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. 

My suggestion would be that the link properties be moved into an obj of their own, something like a list of babel-link-properties-obj. We can document the examples you have above. They do not have to be specified by default. Operators that do want to, can define any combination of link properties, like you do above with wired, wireless and tunnel. They can call them whatever they want. One item in this list in then referenced by the babel-interface-obj which tells it which link properties if any have been specified for that interface. Something like this:

object {
           ….
           [babel-link-properties   rw babel-link-properties<0..*>;]

} babel-information-obj;

object {
          [reference                      rw  babel-link-properties;]
           …..
} babel-interface-obj;

object {
          string                             rw name;
          [string                            rw babel-link-quality;]
          [boolean                        rw babel-split-horizon;]
          [uint                               rw babel-max-rtt-penalty;]
          [boolean                        rw babel-unicast;]
} babel-link-properties;

Tomorrow, if we want to add more properties, the babel-link-properties obj can be extended. 

>  - the BGP YANG model imports draft-ietf-rtgwg-policy-model.

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.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 03:00:26 +0200

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

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.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Aug 2019 13:25:12 +0000

> >> 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:
> >>
> > 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).
> 
> > 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.

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

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.

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

Barbara

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 7 Aug 2019 11:00:52 -0700

Hi Juliusz,

> On Aug 6, 2019, at 6:00 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

My bad. My understanding from the changes that Barbara made in -08 (by removing the UI and the underlying properties) was that they were not desired.

Are you be ok with the changes I suggested yesterday on the additions to the information model, that exposes both the underlying property and the UI associated with it?

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 7 Aug 2019 11:05:09 -0700

Hi Barbara,

> On Aug 7, 2019, at 6:25 AM, STARK, BARBARA H <[email-masked]> wrote:
> 

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.

> 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?

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Aug 2019 18:55:55 +0000

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

<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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 7 Aug 2019 12:51:07 -0700

> On Aug 7, 2019, at 11:55 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
>  
> 
>  
>           [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.

> 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…

[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-information-obj;

object {

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 7 Aug 2019 20:09:41 +0000

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

object {
          ….

} babel-information-obj;

object {

<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
[email-masked]<mailto:[email-masked]>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 08 Aug 2019 16:04:05 +0200

> 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:

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 8 Aug 2019 07:34:50 -0700

Hi Toke,

> On Aug 8, 2019, at 7:04 AM, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 

While seemingly more complex, it is not. First of all, with your proposed schema,  if you need the same presets for multiple interfaces, you would be having to repeat them for multiple interfaces. Secondly, there is no way in YANG to define a set of presets, so there will be no drop down menu to select from. We were going to document the three or four well known presets. Thirdly, while these names and values may make sense to us, they may not to an operator, who might want to configure their own set of presets.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 08 Aug 2019 22:20:40 +0200

Mahesh Jethanandani <[email-masked]> writes:

> While seemingly more complex, it is not. First of all, with your
> proposed schema, if you need the same presets for multiple interfaces,
> you would be having to repeat them for multiple interfaces. Secondly,
> there is no way in YANG to define a set of presets, so there will be
> no drop down menu to select from.

These both sound like UI issues rather than configuration protocol
issues. I'm not familiar with how YANG works, but from this it sounds
like a UI cannot deviate from what is defined in the YANG model?

> We were going to document the three or four well known presets.
> Thirdly, while these names and values may make sense to us, they may
> not to an operator, who might want to configure their own set of
> presets.

But how does this work in the case where nothing is set on the
management interface, the implementation auto-detect the interface type,
and fills out the defaults based on the type? As Juliusz explained, the
preset keyword cannot generally be inferred from the set values, so what
is the info model / management interface supposed to do in this case?

-Toke

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 8 Aug 2019 14:55:59 -0700

Hi Tote,

> On Aug 8, 2019, at 1:20 PM, Toke Høiland-Jørgensen <[email-masked]> wrote:
>> 

YANG is a data modeling language. It models configuration and operational parameters, defining what type of value a particular parameter is. It does not specify a value for them. For example, it models babel-interace-split-horizon parameter as a boolean. Unless a default is desired, it will not even tell you whether the value for split horizon is true or false. That is for the operator or whoever wants to manage the Babel protocol on the device to configure. That is why I said, YANG will not define preset values, for example “wired”, “wireless” or “other" UI. That is up to the operator to define.

> is the info model / management interface supposed to do in this case?

Let us take two concrete examples. One where the operator has a eth0 interface which is connected to a wired network and does not need any link properties defined, as the implementation knows what to do with a wired interface. The second where it needs to set split horizon to false because the eth1 interface is connected via a bridge to the radio network.

In the first example, and assuming the model Barbara and I suggested, the operator does not need to anything to specify any link properties for eth0. The implementation can pick out the defaults based on the interface type (wired in this case) and use it. 

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.

Does that help?

Mahesh Jethanandani
[email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Aug 2019 00:15:25 +0200

> 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?

I.e. the operator defines a set of values called "radio", this set only
exists within the UI.  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.

Or does YANG require that the UI reflect the model?

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Aug 2019 11:09:07 -0700

Hi Juliusz,

> On Aug 8, 2019, at 3:15 PM, Juliusz Chroboczek <[email-masked]> wrote:
> 

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.

> 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

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?

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 22:51:18 +0000

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Aug 2019 17:18:33 -0700

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 <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 14 Aug 2019 14:46:59 +0200

Mahesh Jethanandani <[email-masked]> writes:

> 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?

For most current Babel deployments I'm familiar with: One or two
wireless interfaces and maybe a single wired. Definitely less than 10...

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 14 Aug 2019 13:50:06 +0000

> From: Toke Høiland-Jørgensen <[email-masked]>
> For most current Babel deployments I'm familiar with: One or two wireless
> interfaces and maybe a single wired. Definitely less than 10...

I agree with Toke. And I think we also need to understand that active configuration in Babel is about handling exceptions to the implemented rules. In almost all cases, the Babel implementation will automatically select the correct link properties for an interface. Only for the small number of cases where the automatic implementation config is wrong will the configuration need to be updated/changed. For example, if I attach a wireless bridge to an Ethernet port of a router, I need to specifically change the link properties for only that one Ethernet interface on that one router. "Repeating" configurations doesn't make sense when active configuration is an exception. I think the normal number of interfaces a *management system* will need to configure is zero.

When RTT is added as a link property, it too will be auto detected by the fact the interface is a tunnel. [We may want to consider a global configuration option to enable/disable detection of tunneled interfaces and use of RTT -- for cases where RTT support is implemented -- to be defined in the RTT draft.]

When unicast becomes a property -- well, this is something that a network operator will probably expect to set independent of other "link properties". It isn't really a link property, at all. [We may want a global configuration option for this, too, to indicate whether a new interface is set to default unicast or multicast -- but that's not for now.]
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 14 Aug 2019 19:30:05 +0200

"STARK, BARBARA H" <[email-masked]> writes:

> I agree with Toke. And I think we also need to understand that active
> configuration in Babel is about handling exceptions to the implemented
> rules. In almost all cases, the Babel implementation will
> automatically select the correct link properties for an interface.
> Only for the small number of cases where the automatic implementation
> config is wrong will the configuration need to be updated/changed. For
> example, if I attach a wireless bridge to an Ethernet port of a
> router, I need to specifically change the link properties for only
> that one Ethernet interface on that one router. "Repeating"
> configurations doesn't make sense when active configuration is an
> exception. I think the normal number of interfaces a *management
> system* will need to configure is zero.
>
> When RTT is added as a link property, it too will be auto detected by
> the fact the interface is a tunnel. [We may want to consider a global
> configuration option to enable/disable detection of tunneled
> interfaces and use of RTT -- for cases where RTT support is
> implemented -- to be defined in the RTT draft.]

Yes. I usually just enable RTT globally :)

> When unicast becomes a property -- well, this is something that a
> network operator will probably expect to set independent of other
> "link properties". It isn't really a link property, at all. [We may
> want a global configuration option for this, too, to indicate whether
> a new interface is set to default unicast or multicast -- but that's
> not for now.]

Yeah, when we have some more experience with this there will probably be
some relevant settings related to unicast as well...

-Toke

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Aug 2019 11:05:33 -0700

> On Aug 14, 2019, at 6:50 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> 
> 
> I agree with Toke. And I think we also need to understand that active configuration in Babel is about handling exceptions to the implemented rules. In almost all cases, the Babel implementation will automatically select the correct link properties for an interface. Only for the small number of cases where the automatic implementation config is wrong will the configuration need to be updated/changed. For example, if I attach a wireless bridge to an Ethernet port of a router, I need to specifically change the link properties for only that one Ethernet interface on that one router.

Ok. Then let us go with link-properties be part of the interface-obj.

> "Repeating" configurations doesn't make sense when active configuration is an exception. I think the normal number of interfaces a *management system* will need to configure is zero.
> 

Mahesh Jethanandani
[email-masked]