Question re. operator tools - somewhere betwixt fast failover and TE

Chris Wright chris.wright at
Fri Aug 5 17:44:40 UTC 2022

I’m not entirely certain these are problems that operators necessarily concern themselves with. Datacenters and specialized service networks, perhaps, but not internet service providers. Mainly because the internet is a relatively lossy beast with several performance inhibitors that constantly lie outside an operator’s control (i.e. bad filters seem to break the entire United States eastern seaboard at least once a year.) I’d wager most of us are not concerned with the kind of failure scenario you’re describing simply because there is no demand from our customers for sub-millisecond remediation. At least not from the ones who are willing to pay for it. 😉



From: NANOG < at> On Behalf Of Matthew Nance Hall
Sent: Friday, August 5, 2022 12:24 PM
To: nanog at
Cc: 'Ramakrishnan Durairajan' <ram at>; 'PAUL R BARFORD' <pb at>; klaus-tycho.foerster at
Subject: Question re. operator tools - somewhere betwixt fast failover and TE

You don't often get email from mhall at<mailto:mhall at>. Learn why this is important<>


I'm Matthew Nance-Hall (Matt), a PhD Candidate at the University of Oregon working with Prof. Ram Durairajan (UO), Prof. Paul Barford (UW-Madison) and Prof. Klaus-Tycho Foerster (TU Dortmund).

I was hoping someone could shed operator perspective on a research question we're exploring. We're interested in the timescales and mechanisms used to adjust data paths and wondering where gaps might exist between traffic engineering (TE), fast fail-over, and routing.

We're specifically curious about spatio-temporal characteristics where gaps might exist. For example, the topological scope of an event (congestion or outage) and the timescale for adjustments to be made. I'm aware there are operator tools such as fast fail-over and TE for making changes confined to single links or across the whole network but wonder if there is a place for events that have broader scope (beyond a single link but less than the whole network) where new inquiry and exploration would be welcome.

Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the NANOG mailing list