RE: Last call - RSVP problems

[Fong Liaw <fliaw@zaffire.com>]

Suresh/Vishal/Jen

>  -----Original Message-----
>  From: suresh Katukam [mailto:skatukam@cisco.com]
>  Sent: Friday, May 25, 2001 12:06 PM
>  To: v.sharma@ieee.org
>  Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org
>  Subject: Re: Last call - RSVP problems
>  
>  
>  >
>  
>  Vishal and Jen,
>  
>  One possible solution is that -
>  There are multiple types of persistency of circuits can be provided
>  
>  1. Tear down a Circuit if a control channel fails
>  2. Tear down a Circuit only if a data path fails.
>  3. Tear down a Circuit only when a Source Node or Destination Node
>  deletes by sending explicit messages.
>  
>  I guess, (3) is what normally happens in today's networks. 
>  Only Network
>  administrator deletes circuits through TL1/EMS etc when 
>  there are problems.
>  
>  (1) is achieved naturally by RSVP refresh mechanisms.
>  
>  (2) is achieved when Refresh Timers are set to Infinite (No 
>  RSVP refreshes)
>  and indicate in RSVP message that tear down when a Data Path Fails.
>  

"Infinite timer" is actually very problematice with RSVP. 
We have specifically recommend NOT to use this, after attempting
to do it.

>  (3) is achieved when Refresh Timers are set to Infinite. By default,
>  circuit is kept irrespective of failures.
>

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. 
   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.

Regards,
-Fong  

>  Ofcourse, (2) & (3) introduces some problems when the control channel
>  comes alive. How do two neighboring nodes sync up on what 
>  circuits are
>  still alive and what is gone? This is kind of addressed in 
>  ATM and we could
>  borrow ideas from there. If we all agree on above 
>  persistency levels or just
>  with (3), then I can provide information on how to sync up 
>  etc once nodes
>  come back alive.
>  
>  Thanks,
>  Suresh
>  
>  
>  
>  >
>  > > ****
>  > > Signaling channel failure:
>  > > If any element along the RSVP signaling path of an LSP 
>  fails, the RSVP
>  > > soft state timer in nodes downstream of the failure will 
>  timeout and the
>  > > nodes will delete the LSP, even if the forwarding plane is still
>  > > working! When GMPLS is used to control a transport network, this
>  > > scenario will occur, since the reliability of control 
>  planes is likely
>  > > quite a bit lower than the cross-connects themselves.  
>  In transport
>  > > networks, the data plane reliability expectations are 
>  very high, and any
>  > > factor that increases the already steep challenge of 
>  meeting those
>  > > expectations is not acceptable.
>  > >
>  > > One of the cardinal principles of transport network 
>  architecture is that
>  > > control plane failure must *not* cause the data plane to 
>  fail.  This
>  > > point has been raised and acknowledged at the OIF, but 
>  so far does not
>  > > seem to have been addressed in any of the GMPLS drafts.
>  > >
>  > > Jen
>  
>