[c-nsp] Feature request

Oliver Boehmer (oboehmer) oboehmer at cisco.com
Fri Nov 10 04:59:51 EST 2006


I wouldn't be surprised if this was possible, but if you are really
targeting for zero-loss planned maintenance, you also need to worry
about microloops during routing convergence. Those can occur as the
routers update their routing table in an asynchronous fashion, so with a
topology

-- a --- b --- c --- d --
   |                 | 
   --- e --- f -- g --

where you want to perform maintenance on the c-d link (and thus increase
the metric, for example), you will likely run into a small timing window
where "b" has already converged (routes point to "a"), but "a" hasn't,
so you'll see loops for a fraction of a second.
We're planning to this problem using a concept of "Ordered SPF" (see
draft-francois-ordered-fib-00.txt)..

So this is a quite complex problem, and we're working on it.. 
As Ian and Rodney have pointed out: any IP-flow-based approach is doomed
to fail here. 

If you had a full-mesh of PE-PE tunnels and all traffic is using them,
you could possibly achieve this by increasing the metric and trigger a
re-optimization of the tunnels. So the tunnels would be re-optimized
around the link/node, and this happens in a make-before-break fashion.

	oli

cisco-nsp-bounces at puck.nether.net <> wrote on :

> I agree.
> 
> I've never tested an OC192 running at high utilization and swing
> the routing over from one path to the other on a transit link.
> I wonder if you could reprogram the hardware fast enough to not drop
> a *single* packet. :) 
> 
> Rodney
> 
> On Fri, Nov 10, 2006 at 07:18:39AM +1000, matt carter wrote:
>>> 
>>> Disruptive means different things to different people.
>>> If you define disruptive as losing a single packet it can't be done
>>> today. 
>>> 
>> 
>> presuming we're talking scheduled work as mentioned i'd argue you
>> could could can quite comfortable do this without a single packet
>> drop simply by adjusting the metrics and resulting flow paths
>> allowing you to effect a graceful removal of the device you are
>> going do perform work on, before you do the work??? make before
>> break, or have i got my wires crossed somehow.. 
>> 
>> --matt
>> 
>> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list