RE: Last call - RSVP problems

[Dimitrios Pendarakis <DPendarakis@tellium.com>]

Hi Jonathan,

One point to consider is that the signaling control 
channel might be realized over a different link layer 
than LMP. For example, LMP might be running in-fiber
over SONET/SDH overhead bytes, while RSVP is running 
over an out-of-band network such a shared Ethernet.
RSVP Hello allows independent detection of signaling 
channel failure, so it's a useful option to keep.

Thanks,
Dimitris

Dimitris Pendarakis
Tellium, Inc.


> -----Original Message-----
> From: Jonathan Lang [mailto:jplang@calient.net]
> Sent: Friday, May 25, 2001 5: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,
> 
>   "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.
>