[prev in list] [next in list] [prev in thread] [next in thread] 

List:       juniper-nsp
Subject:    Re: [j-nsp] Fate sharing between BGP and RSVP
From:       Chuck Anderson <cra () WPI ! EDU>
Date:       2016-09-14 14:34:56
Message-ID: 20160914143456.GQ1285 () angus ! ind ! wpi ! edu
[Download RAW message or body]

See also:

http://www.juniper.net/documentation/en_US/junos15.1/topics/usage-guidelines/mpls-configuring-traffic-engineering-for-lsps.html


On Wed, Sep 14, 2016 at 09:20:17AM +0200, Dragan Jovicic wrote:
> So you want BGP to resolve routes using only inet.3 table which contains
> RSVP routes, and not inet.0.
> 
> https://www.juniper.net/documentation/en_US/junos15.1/topics/example/vpns-layer-3-route-resolution-route-reflector.html
>  
> 
> Dragan
> 
> On Wed, Sep 14, 2016 at 1:26 AM, Rob Foehl <rwf@loonybin.net> wrote:
> 
> > On Tue, 13 Sep 2016, Chuck Anderson wrote:
> > 
> > I guess I don't understand what you are trying to accomplish then.
> > > Ttaffic engineering specific routes is exactly what RSVP is used for.
> > > The MPLS path should be torn down if there is no available
> > > RSVP-capable route.  Did you try just not configuring RSVP on the
> > > interfaces that can't support MPLS?
> > > 
> > 
> > The LSP is torn down; the BGP session carrying a bunch of routes for which
> > that LSP is the only viable forwarding path survives.  (RSVP is only
> > configured where it ought to be, no "interfaces all" or anything like that.)
> > 
> > The goal is for the BGP-learned routes to disappear along with the LSP --
> > preferably by just tearing the session down with it, but otherwise
> > invalidating the next-hops would suffice.
> > 
> > I have another idea in my back pocket if this isn't workable, but that
> > involves turning a bunch of P routers into full BGP RRs...
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


[prev in list] [next in list] [prev in thread] [next in thread]