RE: Last call - RSVP problems

[Jonathan Lang <jplang@calient.net>]

Dimitris,
  The RSVP Hello Extension is intended to detect node failures and not
necessarily link (control channel) failures.  In particular, the tunnel
draft says, "It should be noted that node failure detection is not the same
as a link failure detection mechanism, particularly in the case of multiple
parallel unnumbered links."  What happens if you want redundant control
channels for control-channel resiliency?  I believe you would still want a
mechanism to detect control channel (link-layer) failures.

  In LMP, you can have multiple active control channels between a pair of
nodes.  You can configure control channels over shared Ethernet and over
SONET/SDH overhead, etc.  You send keep-alive Hellos over each control
channel.  If you so desire, you can send all signaling messages over the
Ethernet control channels.  You can also choose to send all remaining LMP
messages over the SONET/SDH-based control channels.  Keeping RSVP Hellos as
"optional" would be fine.  Making them mandatory doesn't seem like the right
solution.

Thanks,
Jonathan

P.S.  Should we move this discussion on the OIF list??

> -----Original Message-----
> From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com]
> Sent: Friday, May 25, 2001 3:16 PM
> To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; v.sharma@ieee.org
> Cc: 'Jennifer Yates'; mpls@UU.NET; ccamp@ops.ietf.org
> Subject: RE: Last call - RSVP problems
> 
> 
> 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.
> > 
>