Subject: [mpls-tp] ITU MPLS-TP ad hoc comments on the MPLS-TP framework

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 19 Jan 2009 15:28:48 -0500

Attached are the results of our review of the MPLS TP framework draft.
This review was initiated at the December meeting of SG 15, continued at
conference calls on December 16 & 17 with some final comments
consolidated via email.

 <<tp-framework-00-itu-v4.doc>> 
This document was generated by a members of the MPLS-TP ad hoc team and
represents the consensus of that team.  It is not a formal liaison
statement from the ITU-T SG 15.

One outstanding issue is that has not been fully resolved is the
description of the requirements for the congruency of bidirectional
paths (LSPs).  It is clear that MPLS-TP MUST offer a bidirectional
service to a client and this MUST be provided over congruent
bidirectional LSPs.  Clearly this implies that the bi-directional
MPLS-TP LSP is supported over congruent server layer trails down to the
level of the duct.  However, we could not reach agreement on how this
requirement should be expressed in the draft.

Malcolm Betts
co-chair MPLS-TP ad hoc
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 19 Jan 2009 21:36:17 +0000

Malcolm,

With respect to

> requirement should be expressed in the draft.

In my opinion what we are defining with MPLS-TP is a layer network
technology, ensuring congruent server layer trails down to the level of the
duct is a cross-technology issue and therefore I would place it in the
"network design" bucket and say it does not need to be captured as a
specific requirement. I am assuming here that there is no direct
relationship (control plane) between MPLS-TP and its server layer and
therefore no specific functionality needs to be built into MPS-TP to enable
an operator to ensure path congruency down to the duct.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 Jan 2009 21:38:47 -0000

Tend to agree.
Not sure why this would be a problem that MPLS-TP has to solve when it has 
not been solved in any other technology.
Perhaps ITU can work on a generic set of requirements for this, and the 
generic solution mechanisms. And then individual technologies can look at 
the implications.
A

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 19 Jan 2009 16:46:34 -0500

Adrian, with my co chair hat off, I agree, this is not a problem that
MPLS-TP - or any other layer network can solve in isolation, its
dependent on the path set-up policy of the server layer.  The most we
could say ids that when offering a bi-directional service to the client
MPLS-TP must use a congruent server layer.  As Ben says how that is
implemented is a network design decision (and therefore out of scope).  

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, January 19, 2009 4:39 PM
To: Ben Niven-Jenkins; Betts, Malcolm (CAR:X632); [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] ITU MPLS-TP ad hoc comments on the MPLS-TP
framework

Tend to agree.
Not sure why this would be a problem that MPLS-TP has to solve when it
has not been solved in any other technology.
Perhaps ITU can work on a generic set of requirements for this, and the
generic solution mechanisms. And then individual technologies can look
at the implications.
A
----- Original Message -----
From: "Ben Niven-Jenkins" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 19, 2009 9:36 PM
Subject: Re: [mpls-tp] ITU MPLS-TP ad hoc comments on the MPLS-TP
framework

>> MPLS-TP LSP is supported over congruent server layer trails down to 
>> the level of the duct.  However, we could not reach agreement on how 
>> this requirement should be expressed in the draft.
>
> technology, ensuring congruent server layer trails down to the level 
> of the duct is a cross-technology issue and therefore I would place it

> in the "network design" bucket and say it does not need to be captured

> as a specific requirement. I am assuming here that there is no direct 
> therefore no specific functionality needs to be built into MPS-TP to 
> enable an operator to ensure path congruency down to the duct.
>
> Ben
>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 20 Jan 2009 01:32:11 +0100

A very common example is a unidirectional switched 1+1 SNC protected server
layer connection supporting a bidirectional link in MPLS-TP. Most of the
time both directions of traffic will pass through the same nodes and
facilities, but during a period of a unidir fault the traffic of the two
directions passes through different facilities and nodes.

The server layer trail is congruent, but the transport of client layer
information may be temporarily non-congruent. It has never been an issue, so
why should it be an issue today.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: maandag 19 januari 2009 22:36
To: Malcolm Betts; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] ITU MPLS-TP ad hoc comments on the MPLS-TP framework

Malcolm,

With respect to

Ben

---

From: <[email-masked]>
Date: Tue, 20 Jan 2009 08:38:04 -0000

I tend to agree with Ben on this, though I have to come-clean and admit
that it was me who raised this issue in the first place.  The chief
reasons I agree with Ben are 2-fold:
-	it is a general networking issue and not just specific to
MPLS-TP, ie applies to all clients who want bidirectional routing
congruency....for example Ethernet assumes this;
-	one party may not own all the layer networks down to the duct
(indeed this is a very common situation when one CP leases resources
from another CP), so a client can only 'ask' for this to be met and
cannot physically check it.  Further, in this case we have a very clear
client/server case which primarily demands client transparency (of
binary symbol carriage, esp bit-order preservation) with, as Ben also
states, a functional decoupling of the client and server layer networks.

However, the reason I raised this point in the first place was not so
much wrt this bidirectional routing issue, but rather one of being aware
of performance inheritance considerations which should be considered
important if we are supposed to be defining 'transport networks', ie  if
we want to ensure that the performance of layer network N is only a
function of its own traffic load (ie only a layer N design issue) and
not the traffic load/design of any server layers (which may be owned by
different parties) then there are 2 requirements that the client should
request of the server layer network technologies:
-	the server layers must use connections (and the key issue here
is that connections can only have a single source)....a necessary
condition.
-	the server layer resource must not be overbooked.....for a full
sufficiency condition.

And clearly these are recursive requirements to the duct.

co-cs mode server layer technologies (which have been traditionally used
as transport networks) always meet both these requirements, co-ps mode
server layer technologies have to be engineered to meet these
requirements, and cl-ps mode technologies cannot meet these
requirements.

A key corollary of the above performance inheritance requirements is
that the performance experienced by client service instance X cannot be
impacted by the traffic behaviour of client service instance Y.....and
this too is obviously a recursive issue.  And it is this point that is
key as far paying (client layer network) customers are concerned.

In fact, I would say that it is the requirement for transparency,
together with some information on the nature of performance inheritance,
that really needs to be captured.

Aside => This is not to say one cannot break these rules....especially
the one on overbooking of resource, where some degree of overbooking may
indeed be acceptable under an appeal to the statistical laws of large
numbers and no temporal correlation of client resource demands (in some
client cases this cannot be assumed, eg opening/closing of financial
markets).  Breaking the rules of a connection however has a far more
serious impact.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: 19 January 2009 21:36
> In my opinion what we are defining with MPLS-TP is a layer 
> network technology, ensuring congruent server layer trails 
> down to the level of the duct is a cross-technology issue and 
> therefore I would place it in the "network design" bucket and 
> say it does not need to be captured as a specific 
> requirement. I am assuming here that there is no direct 
> relationship (control plane) between MPLS-TP and its server 
> layer and therefore no specific functionality needs to be 
> built into MPS-TP to enable an operator to ensure path 
> congruency down to the duct.
> 
> Ben
>

---

From: <[email-masked]>
Date: Tue, 20 Jan 2009 08:40:54 -0000

Adrian Farrel said 19 January 2009 21:39
>
> Tend to agree.
> Not sure why this would be a problem that MPLS-TP has to 
> solve when it has not been solved in any other technology.
> Perhaps ITU can work on a generic set of requirements for 
> this, and the generic solution mechanisms. And then 
> individual technologies can look at the implications.
Adrian,

NH=> I agree with you...in fact before I read your mail I posted a
remark to exactly this effect, ie it is a generic requirement for many
(if not all/most) clients and not specific to MPLS-TP.

regards, Neil
> layer and