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

adamv0025 at netconsultings.com adamv0025 at netconsultings.com
Fri Apr 17 05:26:08 EDT 2020


> Saku Ytti
> Sent: Monday, April 13, 2020 7:37 AM
> 
> On Mon, 13 Apr 2020 at 00:44, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> > What we've generally done is make sure the lowest level protocol
> > reacts as quickly as possible. This way, it's (quick) reaction would
> > inform lateral or upper-layer protocols to react accordingly.
> >
> > So we tune IS-IS to react quickly, and enable BFD just for it.
> 
> +1, only ISIS (and other SPT protocols) are topoogy aware. If ISIS
> converges fast, and the rest of the protocol stack is correct, then
everything
> converges fast. LFA, rLFA, PIC, edgePIC and you can locally converge once
> you are aware of the outage, ~immediately. That is, convergence can happen
> in linecard HW, as the backup path is already programmed there, the only
> thing it needs to know is if-down. And the rest of the network not
converged
> yet, are protected by the node which is aware of the failure.
> 
Is this applicable to RSVP-TE though? 
In other words, will ISIS/OSPF BFD-triggered session down event on a
particular interface (if the interface stays up) trigger RSVP into switching
over the affected LSPs to a bypass LSP protecting the affected link/node?
Or does RSVP need to become a client of BFD (same way as ISIS/OSPF is)?
I honestly don't remember, currently all core links are "ae" bundles, so
relying on lfm/micro-bfd to modify interface state -which does trigger RSVP
into action.

Note, obviously we're talking only about failure cases where interface
remains up. In case of interface down any keepalive methods are irrelevant
and the failover happens in single digit [ms] timeframes.

adam





More information about the cisco-nsp mailing list