Subject: Re: [babel] info-model: link properties

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 10 Jul 2019 18:12:36 +0000

> I was under the impression that we had decided that the classification of link
> types in wired/wireless/tunnel is an internal implementation detail of
> babeld, and that what we wanted to export were the underlying properties,
> which are:
> 
>   - link cost estimator (ETX or 2-out-of-3);
>   - use split-horizon (boolean);
>   - use RTT (boolean).
> 
> wired means 2-out-of-3, split-horizon, no RTT.
> wireless means ETX, no split-horizon, no RTT.
> tunnel means 2-out-of-3, split-horizon, RTT.
> 
> It is clear to me that the interface type abstration is useful for the user, who
> doesn't want to deal with technical details such as whether the split-horizon
> optimisation is allowable on a given link type, but it's difficult to export from
> the management interface.

I recently posted an update to the information-model draft, but missed including the appropriate updates to the Link Properties registry descriptions in IANA considerations. What I intend to do in the next revision is use Juliusz' proposed descriptions (above) for wired, wireless, and tunnel. What should I put for "other"?  Or should I have an "other"? 
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 17 Jul 2019 13:16:18 +0000

I've gotten no replies to this email. Absence of reply mean you agree with using Juliusz' definitions for wired, wireless, and tunnel. But I'm still unclear as to how to define "other". Maybe "implementation specific"?
Barbara

> > I was under the impression that we had decided that the classification
> > of link types in wired/wireless/tunnel is an internal implementation
> > detail of babeld, and that what we wanted to export were the
> > underlying properties, which are:
> >
> > It is clear to me that the interface type abstration is useful for the
> > user, who doesn't want to deal with technical details such as whether
> > the split-horizon optimisation is allowable on a given link type, but
> > it's difficult to export from the management interface.
> 
> I recently posted an update to the information-model draft, but missed
> including the appropriate updates to the Link Properties registry descriptions
> in IANA considerations. What I intend to do in the next revision is use Juliusz'
> proposed descriptions (above) for wired, wireless, and tunnel. What should I
> put for "other"?  Or should I have an "other"?
> Barbara
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=cLDr9j3VC6V4K9_5cjuNb9wKlkx_eIoPr1cDsX2nUEc&s=2
> e8o9o9q1cDVE_etpEPEh90o3fPqUvFfh5vvdRZIFrk&e=

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 21 Jul 2019 21:03:17 +0200

> I've gotten no replies to this email. Absence of reply mean you agree
> with using Juliusz' definitions for wired, wireless, and tunnel. But I'm
> still unclear as to how to define "other". Maybe "implementation
> specific"?

Sorry, Barbara, but that is not what I suggested.

The underlying properties are what is fundamental to the protocol, and
I believe they are what should be exported by the management interface.
The link classification is just something that appears in the user
interface, and gets translated into the underlying properties.

The inverse transformation is not always possible: 2-out-of-3 with split
horizon disabled does not correspond to any currently defined link type
(that particular combination would be useful for e.g. ATM networks).

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sun, 21 Jul 2019 19:23:44 +0000

> > with using Juliusz' definitions for wired, wireless, and tunnel. But
> > I'm still unclear as to how to define "other". Maybe "implementation
> > specific"?
> 
> The underlying properties are what is fundamental to the protocol, and I
> believe they are what should be exported by the management interface.
> The link classification is just something that appears in the user interface, and
> gets translated into the underlying properties.
> 
> horizon disabled does not correspond to any currently defined link type (that
> particular combination would be useful for e.g. ATM networks).

Oh! I think maybe I understand what you're saying. Let me try to paraphrase:

We don't need to define "link property" names like wired, wireless, or tunnel.
Which means we don't need an IANA registry of such things, and don't need parameters based on such an IANA registry.
All we really need to do is identify, per interface:
(1) the metric calculation algorithm used
(2) whether or not split horizon optimization is used
(3) whether RTT is used in metric computation (default: in the absence of any mention of RTT by the implementation, RTT is not used)

Did I finally get this right?
If yes, then my question is whether these 3 items should be individually configurable on an interface?

I actually don't want to include RTT right now, and would prefer for any WG RTT draft to identify what config (info model) parameters it would need. I want to avoid a dependency on a RTT draft. Which would leave me with just algorithm and split horizon parameters.
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 21 Jul 2019 22:00:47 +0200

> Which means we don't need an IANA registry of such things, and don't
> need parameters based on such an IANA registry.

Right.

> (3) whether RTT is used in metric computation (default: in the absence of any mention of RTT by the implementation, RTT is not used)

Right.

> configurable on an interface?

Yes.

> I actually don't want to include RTT right now, and would prefer for any
> WG RTT draft to identify what config (info model) parameters it would
> need. I want to avoid a dependency on a RTT draft. Which would leave me
> with just algorithm and split horizon parameters.

Agreed.