nanog mailing list archives
Re: Optical Crossconnects and IP
From: Danny McPherson <danny () tcb net>
Date: Sun, 14 May 2000 16:31:54 -0600
I don't care about transient loop induction while in the process of converging. That problem is much harder to solve. What I do care about is a table like the following handed to the NOC/operational folks.
If it were actually implemented it wouldn't be something you'd hand to the NOC .. unless I'm missing something. You don't hand them your SPF algorithm, or your BGP decision algorithm .. it's all "magic". You'd much more likely be handing them something stating "We've enabled this feature, here's the knob that did it, here's how it works...". My concern with these packet-based pre-calculated restoration mechanisms is that they near deterministically introduce transient forwarding loops, loops that result in the same amounts of non-forwarding (network unavailability) time that normal path recalculation/IGP convergence would result in. The benefit of a circuit-based restoration mechanism (i.e. MPLS fast reroute with a pre-defined backup LSP) is that when you switch to a backup connection you know (with some level of confidence) that packets forwarded on the connection will not be tossed around like hot potatos until the entire IGP converges, SPF calculation throttles are reset, etc.., introducing instability in the network. -danny
Current thread:
- Re: Optical Crossconnects and IP, (continued)
- Re: Optical Crossconnects and IP Tony Li (May 11)
- Re: Optical Crossconnects and IP Fletcher E Kittredge (May 14)
- Re: Optical Crossconnects and IP Vijay Gill (May 14)
- Re: Optical Crossconnects and IP Michael Shields (May 14)
- Re: Optical Crossconnects and IP Vijay Gill (May 14)
- Re: Optical Crossconnects and IP Jerry Scharf (May 11)
- Re: Optical Crossconnects and IP Vijay Gill (May 14)
- Re: Optical Crossconnects and IP Vijay Gill (May 14)