[c-nsp] IOS XR

Vitkovsky, Adam avitkovsky at emea.att.com
Mon Sep 12 06:45:41 EDT 2011


Well you can always pay some extra $$$ for the 1+1 APS to improve the convergence times on the long-haul systems
But still if the first aplifier on the TX path fails you'd still have to wait some time till the blackout reaches the RX site at the oter end of Pacific
Than you'd just need to relay on some increased error counts or decreased signal levels right before the aplifier fails -which you'd use to switch and start RX from the alternate working path assuming the 1+1 APS

adam

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mack McBride
Sent: Thursday, September 08, 2011 5:29 PM
To: mtinka at globaltransit.net; cisco-nsp at puck.nether.net
Cc: Mikael Abrahamsson
Subject: Re: [c-nsp] IOS XR

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.


_______________________________________________
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