[28736] in North American Network Operators' Group
Re: Optical Crossconnects and IP
daemon@ATHENA.MIT.EDU (Danny McPherson)
Sun May 14 18:33:52 2000
Message-Id: <200005142231.QAA16843@tcb.net>
To: nanog@nanog.org
From: Danny McPherson <danny@tcb.net>
Reply-To: danny@tcb.net
Date: Sun, 14 May 2000 16:31:54 -0600
Errors-To: owner-nanog-outgoing@merit.edu
> 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
