Re: [manet] [Technical Errata Reported] RFC7466 (7477)

[Christopher Dearlove <[e-mail]>]

On 1 May 2023, at 14:00, Henning Rogge <[e-mail]> wrote:
> 
> On Mon, May 1, 2023 at 2:55 PM Christopher Dearlove
> <[e-mail]> wrote:
>> 
>> If you know that the kink is cut off you would use the link quality mechanism to stop that link being considered symmetric, and thus would stop reporting it in TC messages (among other changes). Using link quality as a binary good/bad state is a perfectly reasonable approach.
> 
> But a little bit harsh for a link that might just have missed one/two
> Hellos... it might be the only link between two parts of the network.

Which is why you retain the metric information while not using the link, ready to reinstate it if you discover it’s good again.

And I was addressing the suggestion that you know the link is broken. Presumably from L2 or similar. Using missing HELLO messages is one way to use link quality, but the two are not inseparably linked. You can use link quality based on anything you like, L2 information on/off is one possibility.

>> You can’t adjust the link metric value in TC messages, because (a) you don’t know what it should be, and (b) you will create inconsistencies that could lead to looping. Just stopping reporting (updating sequence number) is the best you can do. And using link quality does that.
> 
> I can adjust the content of the TC my local router is producing... at
> the moment I am experimenting with a mechanism that will (as soon as a
> link is overdue based on Hello-Interval) use a similar "penalty" to
> the outgoing link metric in the local database than the metric
> algorithm (slightly modified DAT at the moment) does on the incoming
> one based on the time interval... which means this penalty will be
> instantly gone a new PacketBB packet arrives from the neighbor.
> 
> It works quite well if both ends of the link run the same metric algorithm.

Both ends need to be running the same algorithm with the same data, which is not usually available. If it is, fine (and then actually you don’t need quite a lot else). But if not, you are definitely risking creating routing loops. (Always a danger if information is not fresh, but increased here.)

> Henning