The MPLS WG Archive

[neil.2.harrison@bt.com]

Some observations on this discussion:

The user-plane and the control-plane need individual OAM mechanisms that are
appropriate to the layer networking scenario considered.

At one extreme we have a purely cnls mode.....so here the control-plane is
simply composed of a routing facet (ie no signalling) and, moreover, both
the control-plane and user-plane share a common transport component, ie the
IP packet.  Here we need OAM only for the user-plane and the routing
protocol.

At the other extreme we have a co mode with separation of
control/user-planes onto their own network transport constructs (ie the
so-called 'control/bearer separation'.  This is a bit more complex because
the user-plane trails require their own OAM (usually embedded within the
path overhead of the trail) and the control-plane needs OAM for:
-	its own 'user-plane'...since this is logically disjoint network from
the 'user-plane' being offered to (external) customers;
-	the signalling protocol;
-	the routing protocol;
Now, since the routing and/or functionally is no longer common across these
facets it should be obvious that each will have its own specific failure
modes that will need addressing by OAM designed for that facet (clearly we
can extend this to any other protocols that are used in either control or
user planes).

In between these extrems there are others;  like the ones created by MPLS
LSP trails which (i) are more cnls-like for LDP created LSPs and (ii) more
co-like for explictly signalled LSPs using RSVP/CR-LDP.

So I am not sure that the discussion I have been viewing is really helpful.
RSVP hellos are maintaning the integrity of RSVP sessions, LMP hellos are
maintaining the integrity of 'LMP sessions'......and, also checking the
'user-plane' of the control-channel (the user-plane of the trails used to
carry external customer traffic are checked by other mechanisms in LMP).

neil

> -----Original Message-----
> From: Dimitrios Pendarakis [mailto:DPendarakis@tellium.com]
> Sent: 31 May 2001 14:55
> To: 'lyndon_ong@eudoramail.com'; David Charlap
> Cc: mpls@UU.NET
> Subject: RE: Last call - RSVP problems
> 
> 
> David,
> 
> I agree with Lyndon's comment. If you read through the rest of
> my email, you 'll see that the discussion is not about the 
> ability of RSVP Hello to detect link failures:
> 
> DP> LMP hello allows you to detect 
> DP> individual link (or control channel) failures; RSVP Hello allows
> DP> you to detect that you 've lost contact with your signaling peer
> DP> for whatever reason (failure of all redundant control channels, 
> DP> failure of the RSVP daemon, etc.).
> 
> Thanks,
> Dimitrios
> 
> > -----Original Message-----
> > From: Lyndon Ong [mailto:lyndon_ong@eudoramail.com]
> > Sent: Wednesday, May 30, 2001 12:05 PM
> > To: mpls@UU.NET; David Charlap
> > Subject: Re: Last call - RSVP problems
> > 
> > 
> > Hmm, I'm confused here - I did not think the discussion was 
> > about RSVP Hello's function, it's understood to be detecting
> > node failure rather than link or control channel failure.
> > 
> > I thought the question was whether RSVP Hello was necessary if
> > you have an alternative way of detecting control channel
> > failure, in which case you can tell when there are no control
> > channels left standing.  Detection of control channel failure
> > could be through LMP Hello or if you have some alternative 
> > means, like monitoring control channel error rates.
> > 
> > Cheers,
> > 
> > Lyndon
> > --
> > 
> > On Wed, 30 May 2001 10:55:39   David Charlap wrote:
> > >Dimitrios Pendarakis wrote:
> > >> 
> > >> Could you please clarify why you think RSVP Hello 
> doesn't work for
> > >> parallel (redundant) control channels?
> > >
> > >RSVP Hello messages are sent between adjacent IP 
> addresses.  If there
> > >are multiple unnumbered links between two routers, only one set of
> > >Hellos are generated for all the links.  If the multiple 
> > links are all
> > >numbered, then Hello messages are sent for each of the links.
> > >
> > >As a result of this, RSVP Hello can only detect link 
> failure when all
> > >links between two routers are numbered.  If there are 
> > unnumbered links
> > >between two routers, Hellos will not be interrupted until 
> all of the
> > >links fail - meaning it will only detect node failure.
> > >
> > >-- David
> > >
> > 
> > 
> > Join 18 million Eudora users by signing up for a free Eudora 
> > Web-Mail account at http://www.eudoramail.com
> > 
>