[c-nsp] Feature request

[Dale W. Carder]

I was wondering if this would be a case where MTR (multi-topology
routing) might be handy.  Just start swinging your edges to use
a different "colored" path to avoid a certain device/path?  That
might give you just enough of an incremental approach?

Not dropping even 1 packet seems to be somewhat orthogonal to
today's dynamic and best effort packet delivery implementations,
but the idea of letting a "flow" continue out is a neat one.

However, it seems more suited for the tdm environment where you
could busy out DS0 channels 1 by 1 as modems hang up, and then
take the concentrator offline.

Dale


On Nov 9, 2006, at 6:04 PM, Rodney Dunn wrote:
> I wonder if you could reprogram the hardware fast enough to not
> drop a *single* packet. :)
>
> 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