[j-nsp] LDP/RSVP interop

[Harry Reynolds]

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 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. 

Regards



-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Sunday, September 28, 2008 6:54 PM
To: Mark Tinka
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] LDP/RSVP interop

On Mon, Sep 29, 2008 at 07:34:20AM +0800, Mark Tinka wrote:
> On Monday 29 September 2008 04:08:49 David Ball wrote:
> 
> >   You can certainly use both LDP and RSVP on the Juniper box with no

> > problems.  RSVP routes in inet3 are preferred over LDP routes, so 
> > LDP can actually act as a bit of a backup in case you had a massive 
> > RSVP failure.  I'm doing this in my network.
> >   Can't speak for the Cisco.
> 
> Inter-op for LDP and RSVP between C and J works fine.
> 
> Do take some time to look through these threads on the subject, 
> though:
> 
> http://puck.nether.net/pipermail/juniper-nsp/2008-June/010549.html
> http://puck.nether.net/pipermail/juniper-nsp/2008-May/010395.html
> http://puck.nether.net/pipermail/juniper-nsp/2008-April/010247.html
> 
> On the Cisco side, note that it is generally recommended to tunnel LDP

> within RSVP, particularly if you're deploying l3vpn's. This is done by

> configuring 'mpls ip' on the RSVP

Another one to add to the list of things you should consider when
working with mixed Juniper/Cisco MPLS is:

set protocols <isis|ospf> traffic-engineering ignore-lsp-metrics

For an LSP with the head on Juniper and tail on Cisco, this works around
Cisco's inability to set an igp cost of 0 on its loopback interface. If
you ever wondered why the #$%^& your lsp cost was 1 higher than your igp
cost, now you know. :)

On the subject of Juniper MPLS, has anyone else noticed that every time
you resignal an LSP, even with make-before-break, any associated bypass
LSPs are also torn down and take around 50 secs to come back up? I
specifically noticed this when auto-bandwidth runs and upates the bw
reservation in rsvp, which triggers a resignaling. If you have quick
auto-bw timers, this leaves a fairly substantial amount of time that a
noticable percentage of your LSPs are not protected, which I consider a
bad thing. Since in the case above, where your path isn't actually
changing (and the only reason you're resignaling is a bw update), and
the bypass LSP is 0 bandwidth anyways, shouldn't it be possible to
detect this and not teardown the bypass? The 50 sec delay seems a little
excessive too, and I can't find a cause or knob to speed it up.

-- 
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) _______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp