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

[Hari Sapkota]

Hi Emmanuel,

The RSVP should be informed in the case of link failure since BFD runs on
the line card and detects failure in quicker way. In order to terminate
RSVP signaling without having to wait for the hold timer, the BFD should be
bound to the RSVP so that the headend router can signal the use of backup
tunnel. I hope you have already provisioned the backup tunnel for the
temporary use by the PLR till the recalculation of new RSVP path is
completed.

Thanks,

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

> Thanks Hari, does this mean that it is important to have in MPLS TE
> network,for even fast convergence??or is bfd for igp enough?
> There is an automation tool to monitor Core traffic for the Provider I
> work for,and usually disconnection between Core equipment vary up to 5
> seconds which seems a bit too much, I'm thinking of ways of improving it
> further if possible,and I have just noticed bfd for rsvp missing
>
>
> On Sun, Apr 12, 2020, 22:25 Hari Sapkota <sapkota.hari006 at gmail.com>
> wrote:
>
>> 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/
>>>
>>