Subject: RE: LSP failure detection

From: Eyad Saheb <[email-masked]>
Date: Tue, 24 Oct 2000 11:53:18 -0400

There're a few ways to do it.

Detection:

	# Hardware notifies you of a failure
	# Software detects a failure through keep-alives, time-outs, etc...

Protection:

	# A pre-computed path is ready for switch-over
	# A new path is computed at fail-time

Hardware notification is obviously the better choice for detection purposes,
since software keep-alives have longer time-outs to reduce bandwidth
consumption.  With repect to protection, a pre-computed path is the fastest,
however it might not have the most up-to-date information.

Eyad

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Charles
Smith
Sent: Monday, October 23, 2000 9:10 PM
To: [email-masked]
Subject: LSP failure detection

MPLS list:

Can someone please explain the mechanisms involved to detect a node or link 
failure within a particular LSP? How can MPLS as a technology guarantee < 1 
second LSP failure restoration (contrast to SONET)? I need to understand 
exactly how a failure is detected, how the backup path is activated or how 
fast re-route directs the LSP around the link or node failure.

I am just a marketing guy who has read the drafts and still needs the 
engineers to explain the concepts :-)

Cheers.

Chas
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

---

From: Glen Turner <[email-masked]>
Date: Thu, 26 Oct 2000 17:21:24 +0930

>         # Software detects a failure through keep-alives, time-outs, etc...

As far as I can tell, currently defined IP keepalives don't really
cut it.  For example most vendors have a minimum keepalive
interval of 1 second and require 3 lost keepalives before
marking the link as down.  Similarly for OSPF HELLOs.

Is there a special MPLS keepalive defined that allows subsecond
detection of a forwarding failure?  Or is such a beast yet to
be engineered?

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised