The MPLS WG Archive

[neil.2.harrison@bt.com]

Cheng-Yin....simple answer from me is 'I don't know'....others may be able
to provide a more concrete answer.  However, the question misses the point
IMO.

What we have here is a simple client/server relationship between 2 layer
networks:
-	we have a PSN server layer technology, eg MPLS say;
-	we have some client layer network technology X.

In architectural terms there is a client layer trail of X (between wherever
its source/sink points are defined) and a server layer layer trail which is
acting as a (ie one) link connection of the client layer trail between the
PE devices.  That is, the server layer trail has a trail termination source
at one PE device, and a trail termination sink at tbe other PE device.  Now,
the specification and behaviour (of the traffic-bearing data-plane) of the
server layer trail (all aspects, including OAM) should be independent of
which client layer signal is being carried.....of course, this assumes that
the server layer trail is actually capable of delivering the
availability/QoS performance metrics/objectives that the client layer would
expect (and this may not be possible for arbitrary client/server layer
relationships, ie some make more sense than others).  Further, it should
also be independent of how the server layer trail was instantiated.

These are the fundamental requirements for any client/server
relationship....so this is not peculiar to PWE3, as it is a general
architectural requirement.

Putting this another way, what I am saying here is that the server layer
should be able to 'look after itself' as a stand-alone entity.

The same considerations apply to the client layer of course....noting that
client/server relationships recurse, and can indeed be arbitrary (within the
bounds of what are/are-not sensible client/server relationships).  And this
is why layer independence is such a fundamantal requirement.

There is of course a need for communication *between* layer networks under
failures, as this is vital to constrain alarms to their layer of orgin so
that we don't have Ops people all all levels running around trying to work
out what is happening.
Note - in the general case there could be (i) many recursive client/server
relationships here, and this communication has to reach the top level layer
networks, (ii) the various layer networks may not be in the same operator's
management domain, and (iii) the various client layer networks (and
specifically their trail termination points) may be in geographically
disperse locations, even different countries.

The way this is normally catered for is that on server layer failure a FDI
(Forward Defect Indication) is conveyed to the client layer network(s) that
the affected server layer trail supported when it was working normally.
Since defect detection/handling is a uni-directional function, FDI is
required to be generated at the server layer trail sink termination point
and (from G.805) adapted into the appropriate FDI of the affected client
layer (trails).  This is not something novel, it is a fundamental operator
requirement, and it is how those layer networks that operators have had a
large hand in defining are specified, eg PDH, SDH, OTN, ATM.

Now if both the client layer and server layer are self-sufficient as I have
described above then this directly answers your question, ie there is no
need for anything else.

The problems arise when layer networks aren't self-sufficient......be this
from poor initial design, or the fact that are being used in a role that
they were never designed for (ethernet is a good example of this latter
point).

And it is these cases that lead to architectural violations.  Whether such
violations are acceptable or not is for the potential user of them to
decide.  Some are clearly unacceptable....for example there was a
requirement in a particular ATMoverMPLS ID a while back that said
(paraphrased) "on near-end ATM network partition failure (ie CE->PE) inject
Sonet/SDH AIS (=FDI) in the far-end ATM network partition (ie PE->CE)".  I
hope its obvious why this would be unacceptable behaviour for an operator
(but please ask me to explain if not clear).

In the case of mp2p MPLS LSPs, as I have pointed out previously these are
bizarre architectural contructs.  There is no concept of merging in cnls IP
networks (this is clearly pkt multiplexing), nor does the concept of merging
appear in the more usual p2p (or p2mp) co network topology constructs.  In
the case of mp2p LSPs therefore, one cannot appeal to 'normal'
specifications....fault-management is obvious, but it also applies to
performance specifications for availability and QoS metrics/objcetives (a
moment's thought will illustrate its not obvious how one could define
these).

And it is for these mp2p constructs that LSP Ping is being defined as the
fault management tool.  In the case of p2p constructs, and specifically in
the PWE3 case of XoverMPLS, then one can use the simple yet powerful
techniques given in Y.1711.  This is of particular significance/importance
IMO for operators who may be considering MPLS as a convergence solution for
all co pkt-sw technologies, eg FR/ATM/MPLS relationships.

regards, Neil

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:Cheng-Yin.Lee@alcatel.com]
> Sent: 16 December 2002 03:44
> To: Harrison,N,Neil,IKL2 R
> Cc: curtis@fictitious.org; Shahram_Davari@pmc-sierra.com;
> dallan@nortelnetworks.com; swallow@cisco.com; mpls@UU.NET
> Subject: Re: Last call on LSP Ping
> 
> 
> 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>
>