[c-nsp] Resilience in order of few hundreds of milliseconds
Alaerte.Vidali at nokia.com
Alaerte.Vidali at nokia.com
Tue Mar 6 15:15:27 EST 2007
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?
Moving to other idea, what do you think about this OSPF tuning?
-Send OSPF hellos at each 100ms, setting TspfDelay and TspfHold to 0.
(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)
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/
More information about the cisco-nsp
mailing list