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

[Rodney Dunn]

On Tue, Mar 06, 2007 at 02:15:27PM -0600, Alaerte.Vidali at nokia.com wrote:
> Tony, Rodney,
> 
> Thanks for the analysis. I see you agree on the limitation of how to
> detect the failure.
> As I said, the solution must be without using FRR or BFD. 
> 
> When there is FRR support, we can use RSVP hellos; I am wondering way
> Cisco does not support RSVP hellos being a mechanism to indicate failure
> on logical tunnel interface from headend to tailend. The headend would
> detect failure on option 1 and try option 2. (or if there are two tunnel
> interfaces with diverse path and Multipath Routing, when one logical
> interface goes Down traffic would be carried by other interface)
> Any comments?

Honestly I was just working with a customer in their lab and they
wanted PATH protection but they had node protection configured.

Topo like this:

  |-----PE-2----PE-3-----|
 PE-1                  PE-4
  |--------PE-5----------| 


They wanted path protection from PE1-PE5-P4 to take the upper path
if anything along the bottom path failed. What they found was that
FRR would not kick in at PE1 unless the rsvp hellos signalling 
showed the failure between Pe1 and Pe5. Meaning if you failed the link
between PE4 and PE5 FRR on PE1 didn't trigger.

PE1 would get notified about the link failure because PE5 would I think
send a pathtear message back to PE1. I'm not sure why or if they could
trigger FRR on that and it be faster than the IGP dynamically rerouting
the primary tunnel due to IGP notification.

My exact next question today after I saw that was wondering how the
notification was done for path protection failure. :)

> 
> 
> Moving to other idea, what do you think about this OSPF tuning?
> -Send OSPF hellos at each 100ms, setting TspfDelay and TspfHold to 0. 

I've never been a big fan of that for a bunch of different reasons.
BFD, while not perfect, removes any process contention issues because
those frames are consumed under interrupt level.

> 
> (it is not necessary reach 50 to 100ms as in FRR; 200 to 400ms would be
> fine, but network stability under high traffic is very important, so no
> false positives needed)

I wonder if PATH protection would get you that.

You could build a full mesh of tunnels to protect all links and nodes
to get those times for any point in the network couldn't you?

tunnel automesh type feature? I've never worked with it before just read
a bunch about it today. :)

> 
> Br,
> Alaerte
> 
> 
> ========================================================================
> ==========================================
> -----Original Message-----
> From: ext Tony Li [mailto:tli at cisco.com] 
> Sent: Tuesday, March 06, 2007 4:52 PM
> To: Vidali Alaerte (Nokia-NET/RioDeJaneiro)
> Cc: rodunn at cisco.com; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Resilience in order of few hundreds of milliseconds
> 
> 
> To achieve that, you'd have to be running a keepalive mechanism (e.g.  
> ping) down the tunnel at an interval that's about a third of the desired
> failure detection time.  I don't think you'd really like that.
> 
> Tony
> 
> 
> -----Original Message-----
> From: ext Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Tuesday, March 06, 2007 4:56 PM
> To: Vidali Alaerte (Nokia-NET/RioDeJaneiro)
> Cc: rodunn at cisco.com; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Resilience in order of few hundreds of milliseconds
> 
> On Tue, Mar 06, 2007 at 11:53:54AM -0600, Alaerte.Vidali at nokia.com
> wrote:
> > Hi Rodney,
> > 
> > Yes, I have something in mind. What is the lowest time we can get 
> > using second precomputed path from headend to tailend on the same 
> > tunnel interface?
> 
> You could have a backu precomputed path but you still need the
> notification that the primary path isn't valid anymore (ie: Think BFD
> triggered FRR).
> 
> > The headend would sense problem in the first option and switch to 
> > second option.
> 
> How would it "sense" a failure at any point along the path?
> 
> > 
> > I did not test it.
> > 
> > Tks,
> > Alaerte
> > 
> > -----Original Message-----
> > From: ext Rodney Dunn [mailto:rodunn at cisco.com]
> > Sent: Tuesday, March 06, 2007 2:49 PM
> > To: Vidali Alaerte (Nokia-NET/RioDeJaneiro)
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Resilience in order of few hundreds of 
> > milliseconds
> > 
> > No way I can think of.
> > 
> > Did you have something in mind?
> > 
> > You have to have a backup path precomputed and ready to switch the 
> > frames to get that kind of failover.
> > 
> > rodney
> > 
> > On Tue, Mar 06, 2007 at 11:27:50AM -0600, Alaerte.Vidali at nokia.com
> > wrote:
> > >  Hi,
> > > 
> > > Looking for alternatives of fast recovery of MPLS under failure 
> > > without using FRR.
> > > Any input appreciated.
> > > 
> > > (BFD and OSPF timer tuning already considered)
> > > 
> > > Best Regards,
> > > Alaerte
> > > 
> > > 
> > > _______________________________________________
> > > 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/