Re: Congestion/latency-aware routing for MPLS?

[Dave Taht <dave.taht () gmail com>]

On Wed, Oct 18, 2023 at 7:38 AM Tom Beecher <beecher () 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.
>
> Theoretically, you could have some sort of automation in place that dynamically detected available bandwidth over the 
> path, and then re-configure the RSVP configured bandwidth for the interface to reflect that so the next 
> auto-bandwidth calculation would take that into account. However, the efficacy of this would depend on the length of 
> the RF disruption that caused BW reduction. Assuming your detection time was near instant ( which is saying something 
> ) ,you'd still have to have very aggressive auto-BW timers to adjust to it quickly enough, and there are other 
> downsides to doing that.

I have always been curious as to what extent RED is deployed on junOS?
(in for example mpls networks) I had had some pretty bad results with
some mx gear out of my control, a while back, couldn't fix it, slapped
cake on it, grumpily blogged, moved on.

https://blog.cerowrt.org/post/juniper/

What kind of latency swings are observable today?

> On Wed, Oct 18, 2023 at 10:16 AM Jason R. Rokeach via NANOG <nanog () nanog org> wrote:
> > Hi Adam,
> > This sounds like a use case for MPLS-TE with TWAMP-Light. TWAMP-Light handles the latency concern and can encode 
> > your measured latency in IS-IS. Juniper docs: 
> > https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/topic-map/enable-link-delay-advertise-in-is-is.html.
> >  The configuration in steps 5 and 7 is all thats required (from a config standpoint) to get the data into IS-IS.
> > You then, when building an RSVP LSP, would specify a constraint for the latency. Alternatively you can route by 
> > latency on its own by setting the metric to latency, but as you've alluded to, this can be pretty dangerous in 
> > environments with mixed bandwidth availability.
> >
> > The other option afforded for the second point on traffic balance is to use auto-bandwidth 
> > (https://www.juniper.net/documentation/us/en/software/junos/mpls/topics/topic-map/basic-lsp-configurtion.html#id-configuring-automatic-bandwidth-allocation-for-lsps
> >  - see also https://archive.nanog.org/sites/default/files/tues.general.steenbergen.autobandwidth.30.pdf).
> >
> > Other vendors support this as well.
> > SR supports the use of TWAMP-Light as well if you prefer that over RSVP, but it doesn't support auto-bandwidth.
> >
> > _______________________
> > Jason R. Rokeach
> > m: 603.969.5549
> > e: jason () rokea ch
> > tg: jasonrokeach
> >
> > Sent with ProtonMail secure email. Get my PGP Public Key.
> >
> > ------- Original Message -------
> > On Wednesday, October 18th, 2023 at 9:13 AM, Adam Thompson - athompson at merlin.mb.ca 
> > <athompson_at_merlin_mb_ca_cbbhoxs () simplelogin co> wrote:
> >
> > Using a mix of Juniper hardware...
> >
> > Network provides VPLS to customer, over MPLS (obviously) in a dual-redundant-ring radio topology.  Each site is 
> > connected to one or more neighbors, generally with two radios, in two different bands, to *each* neighbor.  So an 
> > ordinary node might have 4 radios, 2 pointing in each direction.
> >
> > Every single radio link has different bandwidth, different latency, and different interference characteristics.
> >
> > These radio links do run at 100% capacity at least some of the time.
> >
> > It's possible to set each link's relative cost in OSPF or IS-IS, of course, but I haven't found a way to make the 
> > router react to latency changes on one link or the other.  (Right now, I think costs are set equal so traffic will 
> > use both links.)  This means interference in one band invisibly diminishes the Ethernet bandwidth available and 
> > silently increases the latency on that link, sometimes dramatically.  This seems to do interestingly unpleasant 
> > things to the client's flows.
> >
> > It's generally true that one band will be much more severely affected than the other, in any interference event.  
> > Before anyone asks, I'm told the network is a mixture of licensed and unlicensed bands, that's not changing anytime 
> > soon.
> >
> > In a perfect world, I'd like the routers to dynamically adjust traffic balance, but even just temporarily halting 
> > use of the impaired link would be helpful (or so I believe right now, at least).
> >
> > Is this a pipe dream?  I'm not seeing anything in JunOS that could accomplish this...  I'm not even sure if a mesh 
> > protocol could handle dual active links like this?
> >
> > Ideas, comments, etc. all appreciated.
> >
> > Also, I'm not the direct operator of use network. I'm involved, but mostly just trying to help them find better 
> > solutions.  Nor am I an MPLS expert, as is obvious here.
> >
> > Thanks,
> > -Adam
> >
> > Adam Thompson
> >
> > Consultant, Infrastructure Services
> >
> > MERLIN
> >
> > 100 - 135 Innovation Drive
> >
> > Winnipeg, MB R3T 6A8
> >
> > (204) 977-6824 or 1-800-430-6404 (MB only)
> >
> > https://www.merlin.mb.ca
> >
> > Chat with me on Teams


-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos