The MPLS WG Archive

["john151@libero.it" <john151@libero.it>]

Hi Curtis hi all,
essentially my considerations are: if i have two pre-calculated disjoint backup paths and i use opaque LSA to flood the link failure information,
it could be a reasonable faster  way of proceeding instead of using RSVP if i have an intelligence in the source routers (routers have to be able to switch among the two LSPs if they receive that particular opaque LSA; note that for a restoration of many LSPs RSVP will work in series, but OSPF will work in parallel with its flooding mechanism).
So the basic question is: is it a reasonable way the use of OSPF  and opaque LSA? Is there a reason to the use always RSVP for path protection, since, i think, increasing the LSPs corrupted by one link failure (if there are many active LSPs on the link that goes down) the OSPF mechanism of flooding is more efficient than using many RSVP messages from node that detects the failure towards the LSPs senders?

Thanks in advance for your kind answers and observations.

Giovanni Di Giacomo


In message <HBMTM4$875FAF0F2AFF01D1398F99ACE02AFA7C@libero.it>, "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.
> In a TE path protection scenario, there are works dealing with the use of RSV
> P-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 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. 
> This approach has some problem:
> -   a faster trigger on OSPF in detecting failure, since HELLO mechan
oriting 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 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?
> 
> Thanks in advance for your kind answers and observations.
> 
> Giovanni Di Giacomo


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