Re:Re: Between OSPF RSVP...

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

Hi Peter 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 of 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



Giovanni,

We also propose an approach to P/R based on "per failure" flooding. The 
proposal was made after considering a list of requirements that included 
the scalability and flexibility of the recovery scheme. Rather than trying 
to optimize OSPF-TE, we chose to extend LMP to provide the limited flooding 
of the failure notifications. It is documented in 3 Internet Drafts:

Optical Network Failure Recovery Requirements
http://www.ietf.org/internet-drafts/draft-czezowski-optical-recovery-reqs-01.txt
Fault Notification Protocol for GMPLS-Based Recovery
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol-02.txt
Extensions to LMP for Flooding-based Fault Notification
http://www.ietf.org/internet-drafts/draft-soumiya-lmp-fault-notification-ext-00.txt

Any feedback would be appreciated.

Regards,
Peter Czezowski


At 11:38 AM 3/12/03 +0100, john151@libero.it 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.
>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