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: [email protected] [mailto:[email protected]] On Behalf Of Mack McBride Sent: Thursday, September 08, 2011 5:29 PM To: [email protected]; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Mark Tinka Sent: Thursday, September 08, 2011 2:54 AM To: [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
