[j-nsp] LDP/RSVP interop

[Richard A Steenbergen]

On Mon, Sep 29, 2008 at 08:41:42AM -0700, Harry Reynolds wrote:
> Hey Richard, I had raised 101569 for the bypass bouncing after bandwidth
> related resignal, and was told by DE this was expected behavior. At the
> time the explanation made sense. If a bypass m is protecting lsp n, and
> lsp n is torn down, for any reason and in any manner (make before break
> or not), then the bypass shares the same fate, as for some time there is
> no lsp n for bypass m to protect.

I agree it is the expected behavior as it is currently designed, I just
think there is a possible optimization which can avoid tearing down the
bypass lsp unnecessarily. Clearly it depends why you needed to tear down
the LSP in the first place, since an error, preemption, or path change 
is a different animal from an autobw adjustment. And a pox on whoever 
designed it so you need to resignal to adjust the bw resv. :)

I don't see why it wouldn't be safe to say, if you are the head of the 
tunnel, and you've just done a make-before-break resignal to update a 
bandwidth reservation, and you've seen no change in the forwarding path 
on the new lsp, then avoid tearing down the bypass.

> I also see the ~ 60 second delay to resignal the bypass, and also felt
> that was per design as we want to make sure the new lsp is up/stable
> before we go though the bypass bother.
> 
> Perhaps an er can be filed if you feel this is unacceptable. 

I know a few other people who have been hitting this too, so perhaps an
ER to speed up the bypass resignal is in order. Yes I know the big telco
answer is to just run absurdly long auto-bw timers so you don't see this
issue very often, and hope that overflow detection will catch any sudden
changes in traffic before too much $%^* sticks to the fan, but I've had
great lucky with aggressive auto-bw intervals aside from this issue.
Even if you aren't running particularly aggressive timers, if you have a
lot of LSPs it seems pretty likely that you are going to have some
non-deterministic but sizable percentage of paths unprotected at any
given moment.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)