[c-nsp] Feature request

[Rodney Dunn]

Disruptive means different things to different people.
If you define disruptive as losing a single packet it can't
be done today.

If you define disruptive as something that is "significantly
noticeable" to the user. ie: phone call drops, TCP session hangs
for an extensive amount of time then things are in the works and
some available to proactively reroute traffic (ie: NSF/SSO, signalling
a node going down proactively to the routing protocols, etc..)

Routers don't keep track of flows in the forwarding path and they
would have to somehow inform upstream routers to route on a flow
basis. I can't see any scalable solution to that.

rodney


On Thu, Nov 09, 2006 at 12:48:48PM -0500, christopher.a.kane at jpmchase.com wrote:
> Since dependency upon network availability, IRT revenue, never 
> decreases....it seems more and more often people like to schedule complete 
> downtime maintenance windows to perform seemingly benign tasks. We often 
> have folks requesting we route traffic away from a device that we intend 
> to perform maintenance on even if it's as simple as plugging in a new, 
> non-production T1 or changing the speed/duplex settings on a port that 
> resides on a different module and has nothing to do with their production 
> route. Erring this much on the side of caution seems like a sledgehammer 
> approach. I'd much rather be able to reassure folks that certain tasks can 
> be performed without impact to traffic flow. But over the years...too many 
> bugs or mishaps such as configuration errors or a field engineer sneezing 
> on a router causes said router to reload. You want a true example? How 
> about inserting a flash card into a box that shot CPU utilization up to 
> >95% and caused packet loss.
> 
> I have a feature request and was hoping Rodney or one of the other Cisco 
> employed lurkers could point me in the right direction. My request is for 
> a 'Detour' feature. What I'm looking for is the ability to route any new 
> traffic flows in a different direction and allow existing traffic flows to 
> bleed off. Once all the traffic has detoured to my alternate connection, I 
> could perform maintenance and then remove the detour and allow the traffic 
> to return to the primary path. The catch is that I don't want this to be 
> disruptive. The programming language would read something like: for all 
> existing flows across interface A/B, permit them to continue. But for any 
> new data flows, detour them to interface X/Y. It seems that we could use 
> data like Netflow and we'd probably have to alter CEF entries to make it 
> happen. Maybe even allow the feature to be shared with a peering router so 
> that we could not only alter the path through various interfaces on one 
> router but ship them to the peering detour router such as would be 
> available in an HSRP/VRRP configuration. As far as I know, up to now, all 
> intentions to route traffic across other available paths is disruptive to 
> existing source/destination flows. I'm not aware of a feature that gently 
> moves traffic another direction without causing some interruption to 
> existing flows. A feature like a detour could be leveraged to stage a 
> device to be ready for maintenance. If we could configure the router to 
> start detouring traffic to an alternate route at a particular time (either 
> immediately or in a set future day/minute/second) we could gently direct 
> traffic away from our maintenance domain without customers having to be 
> engaged and prepared to possibly reset applications because their TCP 
> sessions were hung by the change in flow.
> 
> Make sense?
> 
> -chris
> 
> Chris Kane
> CCIE #14430
> Network Engineering - Business Partner connectivity
> JPMorgan Chase
> w (614) 213-2923
> c (614) 329-1906
> 
> -----------------------------------------
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure
> under applicable law.  If you are not the intended recipient, you
> are hereby notified that any disclosure, copying, distribution, or
> use of the information contained herein (including any reliance
> thereon) is STRICTLY PROHIBITED.  Although this transmission and
> any attachments are believed to be free of any virus or other
> defect that might affect any computer system into which it is
> received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by
> JPMorgan Chase & Co., its subsidiaries and affiliates, as
> applicable, for any loss or damage arising in any way from its use.
> If you received this transmission in error, please immediately
> contact the sender and destroy the material in its entirety,
> whether in electronic or hard copy format. Thank you.
> 
> _______________________________________________
> 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/