Subject: Between OSPF RSVP...

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Mar 2003 11:39:40 +0100

Hi all,
I' m interesting in protection/restoration (P/R) mechanisms and after having read some works, i' d like to do some observations.
In a TE path protection scenario, there are works dealing with the use of RSVP-TE messages to signal, in  example, 
a link failure.
But could it have sense this other way of recovery?
...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechanism to advertise the all network that one link is broken
( ... using opaque LSA? ); then all nodes, receiving the LSA with this information, could compute an analysis of what LSPs ( LSP having source in that node ) are interested by the failure. Then, in example, each node that wants to do restoration in a MPLS scenario could make a Label Switching if there is a Backup Path available. 
This approach has some problem:
-   a faster trigger on OSPF in detecting failure, since HELLO mechanism is slow;
-   the prioriting of the sequence ---flooding LSA---  and  then ---computing SPF algorithm--- to do faster;
-   the adding of intelligence in each node to do the Switching.

I know that these are only some observations containing ( i hope few ) errors and that aren't complete, but since i haven' t found any P/R mechanisms in a TE scenario using OSPF ( or any optimized version of this ), i' d like to make you a question:
is this a possible way of study ( as an alternative to RSVP signalling ) or is completely wrong and out of all standards?

Thanks in advance for your kind answers and observations.

Giovanni Di Giacomo

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 12 Mar 2003 09:21:37 -0500

In message <[email-masked]>, "john151@libero
.it" writes:
> Hi all,
> I' m interesting in protection/restoration (P/R) mechanisms and after having 
> read some works, i' d like to do some observations.
> ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechani
> sm to advertise the all network that one link is broken
> ( ... using opaque LSA? ); then all nodes, receiving the LSA with this inform
> ation, could compute an analysis of what LSPs ( LSP having source in that nod
> e ) are interested by the failure. Then, in example, each node that wants to 
> do restoration in a MPLS scenario could make a Label Switching if there is a 
> Backup Path available. 
> I know that these are only some observations containing ( i hope few ) errors
>  and that aren't complete, but since i haven' t found any P/R mechanisms in a
>  TE scenario using OSPF ( or any optimized version of this ), i' d like to ma
> ke you a question:
> is this a possible way of study ( as an alternative to RSVP signalling ) or i
> s completely wrong and out of all standards?
> 

OSPF/TE already uses the SONET framing detection to trigger fast
flooding of link down.  This is a FAQ.

Ingress then quickly find any affected LSPs (the quickly part is an
implementation detail, but reasonable implementations don't do a
search of all LSPs but rather have this information already available
as a data structure hung off the TE-LSDB entry for the link).

Presignaled disjoint backup LSPs from the ingress are known as
"standby" LSP and are implemented by most LSR as an alternate to FRR.
In practice, standby LSP provide anywhere from sub second to a few
second restoration AFAIK.  Otherwise the ingress must resignal the
affected LSPs on new paths.  This is supposed to take just a few
seconds but in practice if a lot of LSPs are affected most LSR seem to
fall back to IP forwarding and get the LSPs up in 10s of seconds.
Implementations are improving and getting this to consistently a few
seconds, even for large topologies and large numbers of affected LSPs
is being discussed elsewhere usually referred to as the "fast
convergence" problem.

LDP makes direct use of the OSPF derived next-hop.

Curtis

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Wed, 12 Mar 2003 17:57:46 -0500

Hi,

At 11:39 12/03/2003 +0100, [email-masked] wrote:
>Hi all,
>I' m interesting in protection/restoration (P/R) mechanisms and after 
>having read some works, i' d like to do some observations.
>...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding 
>mechanism to advertise the all network that one link is broken
>( ... using opaque LSA? ); then all nodes, receiving the LSA with this 
>information, could compute an analysis of what LSPs ( LSP having source in 
>that node ) are interested by the failure. Then, in example, each node 
>that wants to do restoration in a MPLS scenario could make a Label 
>Switching if there is a Backup Path available.
>-   the prioriting of the sequence ---flooding LSA---  and  then 
>---computing SPF algorithm--- to do faster;
>I know that these are only some observations containing ( i hope few ) 
>errors and that aren't complete, but since i haven' t found any P/R 
>mechanisms in a TE scenario using OSPF ( or any optimized version of this 
>), i' d like to make you a question:
>is this a possible way of study ( as an alternative to RSVP signalling ) 
>or is completely wrong and out of all standards?

any HE LSR detecting a TE LSP failure via any mean (receipt of Path Error, 
IGP notification, ...) does trigger the appropriate action: switch the 
traffic onto a secondary LSP (with Path Protection), reroute the TE LSP 
(global restoration) ...  So, yes, both the PERR and IGP notification are 
used by the HE LSR to monitor the TE LSP state.

JP.