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

[Aamer Akhter (aakhter)]

Hi Alaerte,

Path protection is not going to give you 'few hundred millisecond'. Keep in mind just the propagation delay of the PATH ERROR along the LSP path back to the headend could be several seconds. And that is just the bad news travelling. It sounds like you are not using POS, so depending on your setup, _detecting_ the failure could take a while, w/o BFD we're talking  ~400ms already.


Detection: ~400 ms (rsvp hello)
Propagation: several seconds (depends on topology, where the failure is etc)
Switchover: micro/milliseconds

Path protection is really for switching to another tunnel w/o going thru the delay of signaling a new tunnel. It's main goal is different than FRR (local repair, quick repair, minimize packet loss).

Hope this helps,

-- 
Aamer Akhter / aa at cisco.com
Ent & Commercial Systems, cisco Systems

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Alaerte Vidali
> Sent: Tuesday, March 06, 2007 8:50 PM
> To: vinny at tellurian.com; brad.henshaw at qcn.com.au
> Cc: Tony Li (tli); cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Resilience in order of few hundreds of
> milliseconds
> 
> 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
> >
> >
> >
> 
> _______________________________________________
> 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/