[c-nsp] RSVP-TE was (no subject)

[Hari Sapkota]

I believe that the bfd can be tied with the RSVP signaling on the LSRs,
which triggers the RSVP signaling and reroute via alternate path that you
have provisioned within the MPLS domain.

HTH

On Mon, Apr 13, 2020 at 1:06 AM emmanuel manoni <emmanuelmadoshi at gmail.com>
wrote:

> Thanks man.One more question
> 1.I want to improve switchover time in case of failure in my MPLS TE
> configured network,I know over L2 switch bfd does the trick,in my network
> only bfd for igp has been configured,do I need to configure bfd for rsvp as
> well?if yes,what will be its significance compared to the present bfd for
> igp?
>
> Again thanks in advance
>
> On Wed, Apr 8, 2020, 11:54 Saku Ytti <saku at ytti.fi> wrote:
>
> > On Wed, 8 Apr 2020 at 10:46, <adamv0025 at netconsultings.com> wrote:
> >
> > > Use RSVP-TE for traffic-engineering -i.e. steering traffic across the
> > core
> > > and not for QOS (RSVP-TE "QOS" aka Int-Serv is crazy complex).
> > > Use standard simple QOS aka Diff-Serv to enforce quality of service in
> > the
> > > core.
> >
> > +1
> >
> > IGP - topology represents goal, this is where my customers are
> > happiest (IGP shouldn't be used to TE or QOS, it is the desired
> > topology, which is only changed if desired/ideal topology changes)
> > RSVP-TE - adjusts that goal to fit realities (delay in upgrade,
> > business driver precludes SPT upgrade now) ==> offSPT is capacity
> > report, here we need capacity but do not now have
> > QOS - to discriminate and protect higher priority traffic over lower
> > and to control queueing delay
> >
> > --
> >   ++ytti
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>