Congestion/latency-aware routing for MPLS?

Wed Oct 18 17:21:41 UTC 2023

That's not a good option for bad weather depending on the region. Rain fade and other effects at 24Ghz and above can hinder a set of links, which is sometimes better than having no links at all. The encoding and error correcting capabilities play a crucial part in having a good connection.

Ryan

________________________________
From: NANOG <nanog-bounces+ryan=rkhtech.org at nanog.org> on behalf of Mark Tees <marktees at gmail.com>
Sent: Wednesday, October 18, 2023 10:01:06 AM
To: Tom Beecher <beecher at beecher.cc>
Cc: nanog <nanog at nanog.org>
Subject: Re: Congestion/latency-aware routing for MPLS?

Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.

In addition to RSVP or may be worth using minimum modulation settings on the radios if possible. IE so that links completely drop and you re-route rather than run with less bandwidth.

On Wed, Oct 18, 2023, 6:34 PM Tom Beecher <beecher at beecher.cc<mailto:beecher at beecher.cc>> wrote:
I believe Jason's proposal is exactly what OP is looking for.

I would agree.

On Wed, Oct 18, 2023 at 11:28 AM Saku Ytti <saku at ytti.fi<mailto:saku at ytti.fi>> wrote:
On Wed, 18 Oct 2023 at 17:39, Tom Beecher <beecher at beecher.cc<mailto:beecher at beecher.cc>> wrote:

> Auto-bandwidth won't help here if the bandwidth reduction is 'silent' as stated in the first message. A 1G interface , as far as RSVP is concerned, is a 1G interface, even if radio interference across it means it's effectively a 500M link.

Jason also explained the TWAMP + latency solution, which is an active
solution and doesn't rely on operator or automatic bandwidth providing
information, but network automatically measures latency and encodes
this information in ISIS, allowing automatic traffic engineering for
LSP to choose the lowest latency path.
I believe Jason's proposal is exactly what OP is looking for.

--
  ++ytti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20231018/fe99b3c0/attachment.html>