Re: Between OSPF RSVP...

[Peter Czezowski <peterc@fla.fujitsu.com>]

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