[j-nsp] LDP/RSVP interop

[Richard A Steenbergen]

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)