Re: Last call - RSVP problems

[Charles Kalmanek <crk@research.att.com>]

Fong,

This set of mechanisms based on RSVP Hello seems to protect against 
data plane disruption in the presence of either control channel or 
node (i.e. control plane) failure.  It also handles state resynchronization 
when the failed control plane comes back up using Srefresh.

If the control plane stays down for a very long time, there is the inverse
problem of how to clean up the dangling hard state in the other nodes 
along the path.  Either the users (via UNI) or the service provider (via a 
management system) may want to trigger deletion.

Do you plan to propose some text for the GMPLS drafts?  It would
be good to see if it holds up.  

Seems like this needs to be in GMPLS, not just OIF UNI since it
is relevant to the behavior of intermediate nodes  

chuck

Fong Liaw wrote:

(snip)
> >  >    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.
>
> 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.