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 <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp