The MPLS WG Archive

["Cheng-Yin Lee" <Cheng-Yin.Lee@alcatel.com>]

Neil,
> 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).
Is there a requirement to test the data plane liveliness from ideally
the input
interface of the ingress PE to the output interface of the egress PE for
PWE3 applications?

thanks
cheng-yin

neil.2.harrison@bt.com wrote:
> 
> 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>