[j-nsp] BGP/MPLS Question MX Platform

[Dean B]

Thanks for everyone's suggestions.  RSVP-TE looks like it would be the
cleanest solution.  I'm still a little lost on how that would be
implemented.  Saku in what you are suggesting would the following be
correct:

ISIS with traffic engineering enabled on all the ring links
RSVP enabled on all the ring links
LSPs with normal priority configured on each node to every other node for
BGP to use
LSPs configured for l2vpn use on each node that requires them and set them
to a high reservation priority

So in case of a failure of one of the low-cost links the high reservation
priority on the l2vpn LSPs will only allow them to form on the expensive
path and the BGP LSPs will just be down?  What will keep BGP from just
using the IGP best path at that point?

On Wed, Aug 3, 2016 at 5:57 AM, Saku Ytti <saku at ytti.fi> wrote:

> On 2 August 2016 at 23:38, Mark Tinka <mark.tinka at seacom.mu> wrote:
> >> I'm not opposed to using RSVP if necessary.  All links are MPLS
> >> capable...just trying to find a way to not let BGP use the A-C link
> >> for IP transit traffic and only use it for protection of the MPLS
> >> traffic.  A-C is a smaller capacity link than the others which is why
> >> I don't want to saturate it with IP traffic that can just come from A
> >> or C directly.
> >
> > Good use-case for RSVP-TE.
>
> RSVP-TE is good solution here, if OP wants to put all traffic in RSVP
> tunnels. Make sure expensive path is in SPT, but give L2VPN LSPs
> reservation priority, so once the link is full, other traffic will be
> off SPT and not use that link. Ensuring maximum amount of traffic gets
> best possible service.
>
> If OP does not want all traffic in RSVP, rather make SPT where
> expensive path isn't used, and just put L2VPN in ERO tunnels using
> that link. If this is the goal, then I'd absolutely look into Segment
> Routing, unsure if it's yet configurable like this in JunOS, dunno how
> far 16.1 is in SR implementation, but worth researching.
>
> --
>   ++ytti
>