[c-nsp] RSVP-TE was (no subject)
emmanuel manoni
emmanuelmadoshi at gmail.com
Sun Apr 12 15:31:50 EDT 2020
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/
>>
>
More information about the cisco-nsp
mailing list