[c-nsp] Resilience in order of few hundreds of milliseconds

[Alaerte Vidali]

ok. Thanks for all inputs.
Here is the summary:
Topic: Is it possible achieve resilience in order of few hundreds of miliseconds without using FRR/BFD?  
Requirement: stability of solution under high traffic to avoid false positive

Options
Path Protection: headend is notified about LSP failure along the path
"if a link failure occurs, the LSR to which the failed link is directly attached will generate an RSVP PATH error and an RESV tear message to the headend"

Tuning OSPF: no Cisco support to define millisecond value for OSPF hello (even though Cisco supports subseconds hello)

Did someone measure recovery time of Path Protection?
Is there any reason to not support RSVP Hellos from headend to tailend as a mechanism to detect failure faster?

I dont remember clearly but there was an issue about configuring RSVP Hello on tunnel interface and using MPLS VPN over TE. Any comments on this?

Br,
Alaerte


> -----Original Message-----
> From: ext Brad Henshaw
> Received: Wed Mar 07 02:09:06 EET 2007
> To: Vinny Abello, Alaerte.Vidali at nokia.com
> Cc: tli at cisco.com, cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Resilience in order of few hundreds of milliseconds
> 
> > Vinny Abello:
> > My understanding is that there is built in 
> > QOS for IGP protocols to push them to the front of the queue 
> > on a congested interface to keep the adjacency up under most 
> > conditions.
> 
> This is the PAK_PRIORITY mechanism. Be aware that different
> platforms implement this differently, and some of Cisco's
> layer 3 switches don't implement it at all, relying on user
> Configuration of egress queueing to ensure priority of routing
> traffic.
> 
> I'll leave this alone and let the conversation stay on track
> though :-)
> 
> Regards,
> Brad
> 
> 
>