Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation betweenIETF and ITU-T on MPLS-TP

From: "Jishnu A" <[email-masked]>
Date: Sun, 22 Feb 2009 17:57:38 +0530

I also agree with the Neil's comment that we should keep out MS-PW out of
MPLS-TP. Also, I have a doubt on the client/server architecture of MPLS-TP
client layer. Does the server layer in case of MPLS-TP assume that the
server layer is co-ps layer (though this is not mentioned explicitly in the
requirements document)? As MPLS-TP intends to run on ETH for layer 2, is it
assumed that this layer will be EoSDH or EoDWDM based on GFP etc which
provides a co-ps architecture? Or If ETH server layer is assumed to be cl-ps
layer then is there a requirement for having a co-ps construct within this
layer else this layer can become the lacuna in defining an end-to-end
transport construct based on MPLS-TP?

Regards,

Jishnu A

Date: Sat, 21 Feb 2009 18:09:02 -0000

From: <[email-masked]>

Subject: Re: [mpls-tp] [T15Q12] FW: Liaisonon

      thecooperationbetweenIETFandITU-Ton MPLS-TP

To: <[email-masked]>,     <[email-masked]>,

      <[email-masked]>

Cc: [email-masked], [email-masked]

Message-ID:

<[email-masked]
t>

Content-Type: text/plain;     charset="UTF-8"

Of course I agree with Malcolm and John here....indeed, looking at the issue
as a disapassionate engineer I have absolutely no choice in the matter, this
is simply how networks work.  Sure we can screw things up, but why would you
want to when there is no need to?  How many transport networks does anyone
know that create another layer network above them?  The answer is none.

So the simple question before us is 'do we want MPLS-TP to have a chance of
suceeding as a transport network?'  If yes, then the direction is
black/white, ie there can be no MS-PWs in MPLS-TP....it's a simple as that.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 22 Feb 2009 13:49:13 +0000

Server layer could be anything, we make no assumptions on that, however IMO
it is only sensible to use co server layers or cl server layers that are
constrained to look like co (e.g. Ethernet VLAN with reserved bandwidth).

HTH
Ben

On 22/02/2009 12:27, "Jishnu A" <[email-masked]> wrote:

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Sun, 22 Feb 2009 14:18:58 -0000

Jishnu,
 
Thanks for the comments and recognition of the fact that MPLS-TP must
not spawn further unnecessary layer networks above it if it is to be
taken seriously as a transport network technology.  But you raise
another important topic of 'performance inheritance' in a client/server
relationship.  So let me see if I can help you understand what is going
on here and why it's important......
 
The first thing to be clear about is that a link connection (ie hop) in
(client) layer N is formed by a (server) network connection (ie end-end
path) in layer N-1.  Similarly a (client) link connection at layer N-1
is formed by a (server) network connection in layer N-2.  And this
client/server (topology creation) relationship clearly recurses to the
duct. 
 
So when we consider the performance experienced by an end-end
communication at layer N, not only do we have to take into account the
sources of performance impairment at layer N, but also the sources of
impairment inherited by layer N from layer N-1, etc down to the duct.
And one of the sources of impairment is traffic load, as this can give
rise to variable delay and loss.
 
Now, if you look at any of the many ITU performance standards for a
given network mode technology (any) they show an HRX (usually 27500km in
length) and they break-back the end-end long-term (usually a month)
performance objectives (on metrics like errors, loss, delay) to smaller
access/national/international partitions.  What most (I suspect all) of
the performance standards fail to say however is that they assume that
below *this* layer network it is co-cs all the way to the duct. 
 
And this is very important.
 
Why?  Well, if you look at the co-cs mode it can use space (ie different
fibre), freq (ie different lambda) or (regular time-slices of the) time
dimension to allocate resource.  The space and freq dimensions are self
explanatory in providing a given amount of resource to the client using
them.
 
So let's look in a little more detail at the time dimension.  For the
co-cs mode this involves 2 key things:
-    the label (ie identifies a specific client instance from other
client instances on a link connection) is an *implicit* value which is a
known (start epoch) position in time
-    and crucially, the duration is a fixed length of time.....which
translates to a fixed number of bits for the bit rate of the specific
co-cs layer network being considered....in other words the *resource*
provided to the client instance is also fixed and thus fully
deterministic.
 
This has some important architectural consequences...for example:
-    you cannot violate the single source rule of a connection, eg you
cannot merge 2 VC4s say into 1 VC4, as there is an obvious resource
conflict;
-    there are no QoS classes in the co-cs mode......every client bit is
treated equally, sequence ordering of client symbols is preserved and
the server makes no attempt to understand or change any of the client
symbols  (this is what is meant by requiring 'transparency' in a
client/server relationship);
-    the CP/MP must reside in a (logically at least) OOB adjunct
network;
-    you cannot overbook the server layer resources.
 
Now what this means practically is that if client X is sharing a co-cs
mode server layer network with client Y then it does not matter what the
traffic behaviour is of client X as it cannot impact the performance
experienced by client Y.  Or putting this another way, the performance
delivered to the clients of a co-cs mode server layer network is *not* a
function of the co-cs mode server layer network's traffic load.  
 
And this is why when ITU HRXs specify the performance bounds for their
layer network they don't worry about what layer networks lie below
them...because they assume these are always co-cs all the way to the
duct (which indeed used to always be the case.....not true now with MPLS
and PWs of course).  However, if this is not true then those HRXs may
not be very useful because the performance experienced by a client
network is now no longer under the sole control of the designer/operator
of the client network but is also a function of the design/operator of
all the server layer networks down to the duct...and these may be owned
by different operating parties
 
Now the cl-ps mode can clearly not offer this level of resource
assurance to its clients.  The co-ps can get close to the co-cs mode if
it does 2 things:
-    always respects the rules of a connection (this is a necessary
requirement)....so, for example, LDP or PHP merging is not allowed here;
-    does not overbook its resource (this is full sufficiency
requirement).
 
Aside 1 => The reason one can screw up the co-ps mode is because it is
based on irregular time-slices of resource and the 2 actions of client
labelling and resource assignment are decoupled (unlike the co-cs mode
where they are coupled and known/fixed in time/duration).  So on a
link-connection in the co-ps mode the label has to explicitly exist in
the DP traffic unit to identify the client (for *forwarding purposes* -
but see Note) and its duration is not fixed/known a priori.  In other
words *both the start epoch and the duration* (ie actual resource
demanded by the client at this epoch) have uncertainty.
 
Note - This is why you may have noticed me say in the past that MS-PW
labelling has a real problem.  The PW label MUST assume a SA semantic if
there is any lower layer merging (due to LDP or PHP in MPLS because this
source information has been lost due to lower level merging).  However,
when PWs become multi-hop the label they need now has to have a
forwarding semantic (ie essentially a DA proxy on a given link
connection).  So as you can see there is fundamental conflict here on
what the label has to represent...and we can't have it both ways.
 
Aside 2 => You should also be able to figure out from what I have gone
through above that we cannot have a single instance of routing across
all these layer networks.  This is because for the routing process at
layer N to be able to work a *different routing* process at layer N-1
must have first created the link connections in layer N and thus
provided layer N with a stable topology.  And you can recurse this
argument down to the duct.
 
BTW - The above is all explained, in a slightly different way, in G.800
(unified modelling of networks) that a colleague of mine (Andy Reid) is
largely driving....and this goes right back to the fundamentals of
Shannon Information Theory and System Theory to explain all this.
 
regards, Neil

________________________________

	From: Jishnu A [mailto:[email-masked]] 
	Sent: 22 February 2009 12:28
	To: [email-masked]
	Cc: Harrison,N,Neil,CXM R
	Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation
betweenIETF and ITU-T on MPLS-TP

	I also agree with the Neil's comment that we should keep out
MS-PW out of MPLS-TP. Also, I have a doubt on the client/server
architecture of MPLS-TP client layer. Does the server layer in case of
MPLS-TP assume that the server layer is co-ps layer (though this is not
mentioned explicitly in the requirements document)? As MPLS-TP intends
to run on ETH for layer 2, is it assumed that this layer will be EoSDH
or EoDWDM based on GFP etc which provides a co-ps architecture? Or If
ETH server layer is assumed to be cl-ps layer then is there a
requirement for having a co-ps construct within this layer else this
layer can become the lacuna in defining an end-to-end transport
construct based on MPLS-TP?

	Regards,

	Jishnu A

	      <[email-masked]>

	Message-ID:

<[email-masked]
t.net>

	Of course I agree with Malcolm and John here....indeed, looking
at the issue as a disapassionate engineer I have absolutely no choice in
the matter, this is simply how networks work.  Sure we can screw things
up, but why would you want to when there is no need to?  How many
transport networks does anyone know that create another layer network
above them?  The answer is none.

	So the simple question before us is 'do we want MPLS-TP to have
a chance of suceeding as a transport network?'  If yes, then the
direction is black/white, ie there can be no MS-PWs in MPLS-TP....it's a
simple as that.  

	regards, Neil