RE: Last call - RSVP problems

[Fong Liaw <fliaw@zaffire.com>]

Hi Jonathan

>  -----Original Message-----
>  From: Jonathan Lang [mailto:jplang@calient.net]
>  Sent: Friday, May 25, 2001 2:30 PM
>  To: 'Fong Liaw'; 'suresh Katukam'; v.sharma@ieee.org
>  Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org
>  Subject: RE: Last call - RSVP problems
>  
>  
>  Fong,
>  
>  
>  <snip>
>  > Same as (2), any proposals that remove the refresh mechanism 
>  > is going to be difficult to prove that all cases are covered.
>  > 
>  > Instead, we (will) recommend the following in OIF UNI document:
>  >    
>  >    Use RSVP Hello to detect control channel failure.
>  Why wouldn't you use the LMP Hello to detect control channel 
>  failure?  This
>  is exactly what it is designed for.  From 
>  draft-ietf-mpls-lsp-tunnel-08.txt,
>  

I agree that if LMP or any link layer fault detection technology
(such as using SONET/SDH overhead to determine DCC down) can detect
control channel failure, we don't need to use RSVP Hello.

Note, In a node failure case, a node may lose all of 
its RSVP states. To cover this case, we recommend 
using the Srefresh procedure upon restoration of 
control channel. This will synchronize states on 
both sides.  

Regards,
-Fong

 >    "This (RSVP Hello) mechanism is intended to be used when 
>  notification of
>  link layer
>     failures is not available and unnumbered links are not 
>  used, or when
>     the failure detection mechanisms provided by the link 
>  layer are not
>     sufficient for timely node failure detection."
>   
>  >    If a control channel failure is detected, LSPs states 
>  >    are maintained as if a node continues to receive 
>  >    RSVP refresh message from the failed control channel.
>  >    The recommended Hello timer will be in second range,
>  >    instead of ms range specified in RSVP-TE draft.  
>  > 
>  >    If a control channel failed permanently, manual intervention 
>  >    may be required. This is to be studied.
>  > 
>  > p.s The text is currently being drafted as we type.
>