[c-nsp] IOS XR

[Mack McBride]

One of the factors that gets ignored in failure detection is the length of time it takes for a failure to actually reach the ends of the fiber.  The most common failure is a transponder or amplifier failure.  Light still takes some number of milliseconds to propagate to the end of the connection in the direction effected.  The outage then has to be propagated back to the source in some manner (UDLD or SONET/SDH signaling) Obviously outage detection can't happen faster than the speed of light.  On long haul circuits (trans-pacific in particular) this can exceed 50ms by a large margin.

Mack

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark Tinka
Sent: Thursday, September 08, 2011 2:54 AM
To: cisco-nsp at puck.nether.net
Cc: Mikael Abrahamsson
Subject: Re: [c-nsp] IOS XR

On Thursday, September 08, 2011 01:22:51 PM Mikael Abrahamsson wrote:

> Yes, absolutely. But the 50ms was to define something being *in 
> service*. If it stops forwarding more than that, I don't consider it 
> to be *in service*. Then it's "upgrade with service interruption".

Ah, you meant the SONET/SDH comparison in service terms and not network terms :-).

Yes, certainly, if 50ms is your base measurement for a service outage during a software/hardware upgrade, then I'm not yet sure ISSU can comfortably get you there :-).

In our IPTv environment, we tested RE (Juniper's RP) failover and that went very well, both for graceful and non- graceful situations. Didn't get a chance to see what the CRS RP would do; but in terms of core box failure, service would quickly route around a funky node anyway. 

Mark.