Subject: [mpls-tp] Response to ITU-T Liaison on draft-mpls-tp-requirements-00 (TD54-PLEN)

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 22 Dec 2008 15:35:27 +0000

Colleagues,

I have addressed the comments in the ITU-T SG15 liaison (TD54) and have
posted a revised version of draft-mpls-tp-requirements (-02) which I have
also attached. I had to manually post the draft as I can't find a xml2rfc
version with the new boilerplate so it may take a while for the draft to
appear for download.

ITU-T folks should note that I have already updated the draft in version -01
to reflect comments made by an ad hoc review group during the Geneva meeting
(lead by Adrian Farrel) which included amongst other changes a complete
rewrite of the Recovery & Survivability section. It is therefore difficult
to reconcile your comments on that section with the new section.  I have
therefore only made limited edits to that section and would appreciate if
you could review the new section to ensure it accurately encompasses your
requirements.

Below are my personal responses to specific issues or questions raised in
the liaison.

Ben

1) Liasion: "Note: we consider MPLS-TP as being composed by both MPLS LSP
and PW layer networks (i.e. is the relationship between PW and MPLS-TP the
same as between PW and MPLS, is there a potential need for PW extensions
and/or profiling to support transport requirements). Is our understanding
correct?

ITU-T Q12/15 will provide some deployment scenario by <TBD> in order to
assist the resolution of this comment.

Note for Q12/15: Define the TBD above."

BN: Noted. I believe the relationship between PW & MPLS-TP to be the same as
for PW & MPLS. As a result of comparing the requirements to existing
solutions there may be a need to enhance or modify the PW specs. That is the
job of the PWE3 WG and out of scope of the requirements document.

2) Liaison: " Note: Definition of Section should be aligned with the
description below:"

BN: I have changed the definition to the following which I believe better
aligns.

" Section: A section is a server layer (which may be MPLS-TP or a different
technology) which provides for encapsulation and OAM of a MPLS-TP transport
path client layer. A section layer may provide for aggregation of multiple
MPLS-TP clients."

3) Liaison: " Note: Align the definition of Segment above with the
definition of LSP Segment in RFC 4397:"

BN: I believe they were already aligned although the wording was somewhat
different.  I have changed the definition of segment to the following which
hopefully make it clearer.

" Segment: A segment is a single resource or a set of cross-connected
resources that constitutes part of a path. A segment may be a single link
(hop) within a path, a series of adjacent links (hops) within a path, or the
entire end-to-end-path."

4) Liaison: " It is also our understanding that a PW segment is equivalent
to a link connection within the PW layer network."

BN: Correct.

5) Liaison: " Note: the text ³The combination of a PW (Single Segment or
Multi-Segment) and LSP corresponds to an MPLS-TP transport path² requires
some clarification."

BN: Following other feedback I have already changed the text to " A
Transport path corresponds to an MPLS-TP LSP or to an MPLS-TP LSP and its
associated PW or PWs (Single Segment or Multi-Segment)."

6) Liaison: " Note 1: We are not sure that the description above matches
with our original description reported hereafter. If necessary we can supply
some text together with some deployment scenarios on this extent. ..."

BN: Please look 3 paragraphs down in that section and you will find a
slightly modified version of your original description already there.

7) Liaison: " Note 2: we understood that within the IETF context aggregation
and merging are different concepts:
-    merging when different LSPs are forwarded with the same outgoing label.
When this label is popped, the client signal (e.g. IP) carried by the merged
LSPs gets exposed
-    aggregation when different LSPs are multiplexed together into another
LSP. When the label is popped, each individual original LSP gets exposed and
can be identified.
Is our understanding correct?"

BN: Yes.

8) Liaison: " Note 3: we need to clarify that the services offered to the
clients can be point-to-point, point-to-multipoint or
multipoint-to-multipoint services but the actual transport paths can be
point-to-point or point-to-multipoint."

BN: This is already covered to some extent by the definition of transport
path layer and transport service layer but I added the following sentence to
section 1.2 to make it clear.

" Although the connectivity of the client of the transport path layer may be
point-to-point, point-to-multipoint or multipoint-to-multipoint, the
transport path layer itself only provides point-to-point or
point-to-multipoint transport paths which are used to carry the client. "

9) Liaison: Suggested insertion of "only" in "MPLS-TP MUST support only a
connection-oriented packet switching paradigm with traffic engineering
capabilities that allow deterministic control of the use of network
resources."

BN: Following other feedback I have already changed the wording of this
requirement to the following which I believe also addresses what you were
trying to achieve:

" MPLS-TP MUST be a connection-oriented packet switching model with traffic
engineering capabilities that allow deterministic control of the use of
network resources."

10) The liaison suggested changing " A solution MUST be provided to support
dynamic provisioning of MPLS-TP transport paths via a control plane." to
"The MPLS-TP specification MUST include a solution to support a control
plane for dynamic provisioning of MPLS-TP transport paths. This control
plane is OPTIONAL to be implemented or enabled."

BN: Following other feedback the following paragraph was added to the
Introduction " Although both static and dynamic configuration of MPLS-TP
transport paths (including Operations, Administration and Maintenance (OAM)
and protection capabilities) is required by this document, it MUST be
possible for operators to be able to completely operate (including OAM and
protection capabilities) an MPLS-TP network in the absence of any control
plane protocols for dynamic configuration." I believe this addresses the
same concern as your proposed change.

11) Liaison: " Question: why was the term ³section² instead of ³Link² used
in requirement 23? In our understanding the requirement 23 is applicable to
Link."

BN: I have used link instead.

12) Liaison: " Note: it would be worth adding a note to the paragraph above
stating that a label push/pop can be used also for other purposes other than
aggregation/de-aggregation."

BN: Following other feedback the paragraph you refer to has been removed.

13) Liaison suggests changing SHOULD to MUST in "MPLS-TP SHOULD support
mechanisms which ensure the integrity of the transported customer's service
traffic."

BN: Done, however there is some debate as to what is meant by integrity in
this context. Clarification from ITU-T experts would be appreciated.

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

---

From: <[email-masked]>
Date: Tue, 23 Dec 2008 09:00:08 -0000

Ben,

I've spotted a few things in here which are not accurate and/or require a bit further explanation ...so I have made a few comments for folks to consider.

I've snipped the text to the appropriate points.

Ben Niven-Jenkins wrote 22 December 2008 15:35
> 
> 
> 1) Liasion: "Note: we consider MPLS-TP as being composed by 
> both MPLS LSP and PW layer networks (i.e. is the relationship 
> between PW and MPLS-TP the same as between PW and MPLS, is 
> there a potential need for PW extensions and/or profiling to 
> support transport requirements). Is our understanding correct?
> 
> ITU-T Q12/15 will provide some deployment scenario by <TBD> 
> in order to assist the resolution of this comment.
> 
> BN: Noted. I believe the relationship between PW & MPLS-TP to 
> be the same as for PW & MPLS. As a result of comparing the 
> requirements to existing solutions there may be a need to 
> enhance or modify the PW specs. That is the job of the PWE3 
> WG and out of scope of the requirements document.

NH=> This is indeed what I think most folks would regard as 'the current case'.  However, I strongly believe that we should take the opportunity afforded by MPLS-TP to properly evaluate what the real impact is of the changes that must be made to MPLS.  I won't provide all the technical detail/arguments here (I have already done so on the IETF MPLS-TP list), but the removal of merging and a recognition that we need to address (i) providing an OOB CP/MP and (ii) providing a true client/server solution for MPLS-TPoverMPLS-TP (which in turn requires a better understanding of the S bit sublayering issues) means that the original reasons that created PWs in MPLS no longer hold in MPLS-TP.

And a very important consideration here is the fact that multi-hop PWs will create a co-ps layer network *above* MPLS-TP....we should not do this, as it is both unnecessary and a mistake.  Note also that there is a currently unresolved problem here anyway even for MPLS, ie a PW label MUST retain a SA semantic since it has to provide demerging information that has been lost due to LDP (or PHP), however in multi-hop PWs a PW label MUST have a DA semantic since it has to provide a normal forwarding function.  There is thus a conflict in Characteristic Information in MPLS right now....and this problem should not be carried over into MPLS-TP.  

The obvious(?) solution is not to do multi-hop PWs period (ie don't create a further unnecssary co-ps layer network above MPLS-TP).  However, we should also remind ourselves of the reasons WHY PWs were created in the 1st place, because these reasons have had to be removed in MPLS-TP.  No other 'transport network' has PWs....indeed PWs are only a consequence of the way MPLS was originally specified, but this original specification MUST be changed in MPLS-TP in order to get the required 'transport' behaviour, and thus all the original drivers that created PWs are gone in MPLS-TP.

Now I do recognise this may come as a bit of shock to folks who are reading this for the 1st time.  However, I do believe we should consider these points very carefully and not simply carry old/flawed ideas forward into MPLS-TP without such careful consideration.

I have provided quite a bit of technical arguments on the IETF MPLS-TP list over the last week or so that further elborates on the above.  So those who are tracking this list should have seen these.

And to be very clear here wrt to what I am saying:
-	we must not, under any circumstances, create an unnecessary co-ps mode multi-hop PW layer network above MPLS-TP;
-	we should very carefully evaluate *both* the CW (Control Word) and AC (Associated Channel) functions created in MPLS before carrying them over (as '1-hop adapations') into MPLS-TP.  I believe the AC may have value but I see little value (in fact none) in carrying over the CW.
> 
> 
> 2) Liaison: " Note: Definition of Section should be aligned 
> with the description below:"
> 
> BN: I have changed the definition to the following which I 
> believe better aligns.
> 
> technology) which provides for encapsulation and OAM of a 
> MPLS-TP transport path client layer. A section layer may 
> provide for aggregation of multiple MPLS-TP clients."

NH=> I am not sure this captures the sentiment of what most folks would understand as a 'section layer'.  A link connection at layer N is a network connection at layer N-1...and so on 'to the duct'.  A link connection at layer N does not have span congruency with a network connection at layer N-1.  A bottom-of-stack transport network has its link connections provided by a section layer, and there is a 1:1 congruency of span here.  Moreover, a section layer converts the binary (information) symbols of the bottom-of-stack transport network into the q'ary (information) symbols that are required for the specific metallic/optical/radio media of the section layer...and in turn this must (crucially) modulate an EM wave.

What all this means is that a transport network must be able to 'put information on the wire'....and this is what I underdstand when I see the words 'section layer'.  MPLS (and MPLS-TP) will *not* have a section layer specification.  MPLS (and MPLS-TP) always require a client/server relationship with a different (server layer) transport network that does have a section layer specification.

<snipped> 
> 
> 4) Liaison: " It is also our understanding that a PW segment 
> is equivalent to a link connection within the PW layer network."
> 
> BN: Correct.

NH=> This is indeed true....but we should not be creating a PW layer network at all in MPLS-TP.  If we do this then I think we have completely missed the point of what MPLS-TP should be doing (see my previous remarks against 1).

> Multi-Segment) and LSP corresponds to an MPLS-TP transport 
> path² requires some clarification."
> 
> BN: Following other feedback I have already changed the text 
> to " A Transport path corresponds to an MPLS-TP LSP or to an 
> MPLS-TP LSP and its associated PW or PWs (Single Segment or 
> Multi-Segment)."

NH=> As we can clearly see here, we are having to try and juggle words in order to cater for the PW layer network case.  The right solution is not to create such an unnecessary beast in MPLS-TP.  If PWs CW/AC functions are retained they should revert to their original 1-hop adaptation role.

<snipped>
> 
> 7) Liaison: " Note 2: we understood that within the IETF 
> context aggregation and merging are different concepts:
> When this label is popped, the client signal (e.g. IP) 
> carried by the merged LSPs gets exposed
> LSP. When the label is popped, each individual original LSP 
> gets exposed and can be identified.

NH=> Actually No.  There are errors in the above.  Where it says:

A	"merging when *different LSPs* are forwarded with the same outgoing label."...this is not correct.  A mp2p LSP is *single LSP* it is not the merging of *different* LSPs

B	"aggregation when different LSPs are multiplexed together into another LSP. When the label is popped, each individual original LSP gets exposed and can be identified"....this is only partially correct.  There is an assumption here that all LSPs are properly specified connections, ie ONLY single source entities.  If there is any mp2p merging LSP in any of the LSPs involved here then there is not aggregation.

<snipped>
> 
> 
> 
> 13) Liaison suggests changing SHOULD to MUST in "MPLS-TP 
> SHOULD support mechanisms which ensure the integrity of the 
> transported customer's service traffic."
> 
> BN: Done, however there is some debate as to what is meant by 
> integrity in this context. Clarification from ITU-T experts 
> would be appreciated.

NH=> This point was already raised by Sasha Vainstein on the MPLS-TP IETF list (15 Dec 2008), and I have already had a stab at answering this....I attach below the relevant extract from what I responded to Sasha with:

I suspect it's simply a matter that the person who wrote 'integrity' was using it in some very general catch-all sense.  But you are right that we should try and be a little more precise as to what exactly is required.....so here is my view based on the work we have been doing on G.800 (unified modelling).

Client/server transparency means that each/every bit of the client signal is treated equally by the server...and in particular the server MUST NOT try and infer meaning from the client symbols, and for sure MUST NOT attempt to change any of the client symbols.

A connection is key topological construct that has some important properties (BTW - these properties are not simply of academic interest but have a direct bearing on the design/operational complexity costs of running networks):
-	A connection MUST only have a single source...so only p2p and p2mp constructs can be called connections.
-	A connection MUST preserve the sequence ordering of client symbols....a subtle corollary of this observation is that a connection can only have a single QoS classification.
-	There MUST be no internal routing choice within a connection, ie all symbols that enter a connection should appear on all the connection egress points (with sequence ordering preserved).

Aside=> Of course the above can be compromised by network impairments.  But we can remove traffic load as a source of impairments...which is a key consequence/requirement of a transport network using connections....and to be very clear here:
-	it is NOT sufficient to simply provide reachability isolation between different clients in a transport network client/server relationship, we also need to provide performance isolation, ie the traffic behaviour of client X cannot impact the performance experienced by client Y.
-	A (server layer) connection is a *necessary* requirement to meet this.  For *full-sufficiency* however the server layer resources should also not be overbooked 

I would also like to observe that the OAM required to detect/handle defects is quite independent of the above properties of a connection....it is the above properties (and not OAM) that confers the required 'integrity' of the information transfer.  Further, the OAM required for co mode network connections is NOT the same as the OAM required for cl-ps mode networks.  Example to prove why:  A connection under defect-free operation is a constraining construct (to both traffic and OAM PDUs).  However, if there is a misconnectivity defect present the connection may no longer be operating as a constraining construct and traffic and OAM can leak *unidirectionally* out of a connection *with no return path*.  What this means is that OAM of a request/response nature cannot be relied on in such cases, ie one cannot trace-out the leaking traffic as the OAM request PDUs can leave the connection (at the point of leaking) but will never return.  However, in a cl-ps mode network request/response OAM is the correct type of OAM to use.

regards, Neil