The MPLS WG Archive

[neil.2.harrison@bt.com]

Hi Curtis...please see below.  regards, Neil

Curtis Villamizar wrote 10 December 2002 15:52
<snipped>
> > NH=> Agreed, this was what I was driving at in my 2nd set 
> of questions that
> > I posed 5 Dec, and specifically Q6 therein.  I am still 
> waiting a response
> > on all my postings.....to repeat that specific question:
> > "6	In the same section......why is there an option to 
> reply by the RSVP
> > control-plane?  What scenario is this addressing that the 
> above (NH=> ie
> > using IP only) doesn't?  Further, some guidance on when to 
> select which
> > option would be useful."
> 
> I wouldn't mind getting rid of this.  C&W (for example) has talked
> about running a no-IP routing core with MPLS over it.  I think this is
> a very bad idea.  It is speculative on my part but I think someone is
> either directly driving this or it was added to head off any
> objections that might arise.  I thought you were one that insisted on
> a means to decouple diagnostics from an IP control plane.  Maybe I'm
> mistaken.
NH=> Yes, but this is an obvious and general requirement.  Let me clarify
again what the requirement is here:  When traffic bearing data-plane layer
networks (there are also control/management protocol bearing data-plane
networks, often disjoint from the traffic's data-plane network) are
specified/built correctly they should have self-contained fault handling
functionality that is not dependent on:
-	what client layer network (or applications) they carry;
-	what sever layer network they are supported on (remember client
layer link connections = server layer trails......please see G.805 if you
don't understand this);
-	what signalling (or routing) protocols are used to instantiate the
traffic bearing data-plane trails.

This is obvious IMO (not just to me but to loads of people, though many of
these don't even tune-in to this list), for without it you cannot have
independent layer network evolution or control/management-plane (protocol)
evolution.  Further, without adherering to this principle one cannot use
layer networks in a flexible manner (ie any client/server
combinations....think PWE3 say in the case of MPLS, or even SDH, or even
OTN).

The need to decouple data-plane fault handling behaviour from specific
client, server or control-plane cases is given in Y.1710 (which is based on
agreed operator requirements).  Some of these requirements are also given in
draft-nadeau-ip-basedtool-requirements-00.txt, where requirement 'r' therein
says:
"r) Separation of Data and Control Plane OAM. The inherent separation of
control and data planes in MPLS lends itself to being sometimes implemented
independently within an MPLS LSR.  For example, in a multi-slot LSR, one
slot may run a control process responsible for running MPLS control
protocols such as LDP and RSVP, and then programming line cards residing in
other slots to forward traffic accordingly. In doing so, the switch
separates out the data plane from the control plane in such as way that it
is possible for the line card to be mis-programmed whilst the control card
is unaware. This leads to a potential for the line card to black hole data
plane traffic.  This is one example of why it is important for LSRs to
possess functions that allow an operator to detect data plane liveliness.
Data Plane liveliness MUST use the exact same path as data."

Now whilst the above does at least agree that the control-plane must not
proxy for missing data-plane functionality (and its taken a while to even
get this bit recognised as required), it still fudges the client/server
data-plane layer network relationships.  This is not a good idea for PWE3
applications say where the MPLS client can vary.  Ideally one wants the
*same* solution/behaviour for all client (or server) layer cases (and all
control-plane cases...inc case of 'none', ie static trails).

However, making an an appeal to an IP layer return route for LDP
instantiated mp2p LSPs is not in the least surprising here to try and
mitigate against the fault-handling complexity that mp2p constructs create.
So breaking layering rules here seems unavoidable, and whilst I don't like
it, it is perhaps the only way forward (I have suggested running Y.1711 CV
on the p2p LSPs that must always exist above any mp2p LSP (needed to start
to get rid of the merging) for initial proxied defect detection of lower
layers, and then use trace-route as an ad hoc tool for the mp2p constructs,
as a possible alternative approach.  I know Dave Allan has recognised this
as one solution (to mp2p) a long time ago, but I don't think anyone else is
considering it).

The RSVP return path case does not work as I tried to point out previously
in the event of misdirected traffic, ie I think its reasonable to assume
there is a probability close to 1 that there will be no valid RSVP return
LSP from where any misdirected traffic will end up.  Hence, why I said why
not just use an IP return mode in all cases?.......but also wanted a
clarification of why there is also a plain IP + 'router alert' IP option
here (the latter of which I assume is to try and avoid picking up a server
layer LSP return path?).
<snipped> 

> Implementation is greatly simplified by putting most of the fault
> management smarts at the application layer.
NH=> I would not put it like this.  Basic fault handling behaviour (I am not
talking about more complex ad hoc diagnostics tools here) should be an
inherent design of the data-plane in a layer network.  If it is not, one
will not get the proper behaviour.  Check out SDH and GMPLS....the general
principles are the same (except one is not allowed mp2p constructs here, for
obvious reasons).
> 
> Lets just agree to disagree about what is a nifty hack.
NH=> As one my (well known/respected) engineering colleagues who is
responsible for defining our future network strategy here in BT remarked to
me on seeing these words originally:
"Yes, and "nifty hacks" are the bane of carrier class operations!! Tells us
everything we need to know I think!"
Not my words please note.
<snipped to end>