Subject: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations"

From: Greg Jones(ITU-T SG 15) <[email-masked]>
Date: Sun, 02 Apr 2006 15:59:28 -0400

Title: T-MPLS Consented Recommendations
Submission Date: 2006-04-02
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207 
Please reply by 2006-04-17

From: Greg Jones(ITU-T SG 15) <[email-masked]>
To: IETF MPLS WG, CC: MFA Forum(George Swallow <[email-masked]>, Loa Andersson <[email-masked]>)
Cc: [email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
[email-masked]
Reponse Contact: [email-masked]
Technical Contact: [email-masked]
[email-masked]
[email-masked]
Purpose: For action 
Body: We apologize for not having sent a liaison regarding three consented Recommendations related to 
T-MPLS. The intent of these Recommendations is not to change MPLS but rather to identify a 
subset of existing MPLS necessary and sufficient to provide connection-oriented packet transport.
The approach to the work was to make a profile of the MPLS data plane functionalities defined in 
IETF RFCs using the description of MPLS provided in G.8110 (which was approved last year).  
The intended application of this profile is to provide a connection-oriented packet transport 
network.
The focus of the three new recommendations is on the data plane aspects of T-MPLS. Control plane 
aspects are currently for further study and the work on this subject is starting.
According to our work methodology the T-MPLS definitions are split into the three main 
Recommendations that have been consented in February 2006:
*	G.8110.1 dealing with the T-MPLS Architecture
*	G.8112 dealing with T-MPLS interface specification
*	G.8121 dealing with T-MPLS equipment functional specification
A brief high-level introduction of the essential features and selected options for Transport MPLS 
can be found in section 6/G.8110.1.
The objective of the work done by ITU-T SG15 was to define a way to use MPLS as a connection-
oriented packet-based transport solution for packet aware transport networks that can support both 
packet and circuit (e.g. SDH, OTH or WDM) switching technologies under a common operation, 
control and management paradigm. For this purpose T-MPLS deploys the MPLS frame format, 
Client to MPLS mapping and MPLS to MPLS multiplexing and complements this with transport 
network OAM (Y.1711), nested connection monitoring requiring the labels to be present up to the 
final node in the network, protection switching (Y.1720/G.8131), transport network based control 
and management planes, maintaining frame ordering and a restricted number of classes of 
service/queues.
*	MPLS has many applications and it is desirable to identify a subset of MPLS technology that 
provides the necessary and sufficient functionality for transport applications.
We have indicated below some of the options we have selected :-
*	In IETF RFCs the usage of PHP is optional. We decided not to use it in order to simplify OAM 
procedures
*	In IETF RFCs the usage of merging is optional. We decided not to use it in order to simplify 
OAM procedures and also because the relative lower number of LSPs to be supported is not 
considered a major scaling issue
*	The usage of ECMP is optional. We decided not to use it in order to simplify OAM procedures
*	Leaving labels 16-31 for further study was seen as a no change because the label allocation on a 
link is defined in IETF RFCs as a local matter for any MPLS device.
We are not expecting that the current version of the specification is going to create any 
interoperability issue. We envisage two possible cases of interoperability:
1.	Interoperability between a T-MPLS box and an existing full-featured and fully configurable 
MPLS box can be solved by configuring the MPLS box to use the same options selected by T-
MPLS (T-MPLS being a profile of MPLS this should be possible). In this case the link between 
the two boxes is a T-MPLS link and in the scope of our Recommendations.
2.	Interoperability between a transport platform supporting T-MPLS and an existing MPLS box 
that uses a different option selection than T-MPLS, should be solved by the transport platform. 
In this case the link between the transport platform and the MPLS box is not a T-MPLS link and 
therefore it is outside the scope of T-MPLS recommendations. We are looking for cooperation 
with IETF to develop the detailed specification of this case.
Please find attached the text of the consented Recommendations.  Please note that some minor 
modifications may be made to these draft Recommendations as a result of comments made during 
the approval process
We will appreciate your comments and suggestions in relation to the initial scope of T-MPLS as a 
packet transport network technology.
We are planning to review your comments during the next meeting that is planned in Kobe (Japan) 
on 22-27 April 2006. Results of the comments will be included into our future work (e.g. corrigenda 
or amendments) on T-MPLS Recommendations. Amendments of T-MPLS Recommendations are 
already in our plan for the next SG15 plenary meeting in November 2006.We are looking forward 
for future cooperation with you in T-MPLS data plane and control plane evolution.

Attachments: Consented Text of G.8110.1, G.8112, G.8121
Attachment(s):
     Consented Text of G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip)
     Consented Text of G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip)
     Consented Text of G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip)

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 10 Apr 2006 11:15:25 -0400

Hi,

	A few things in the ITU T-MPLS document concern me:

	1) The document itself constitutes what is essentially
		two things: an protocol specification
		and an implementation guideline.

		For this reason, I first suggest that this document
		needs to be split into two: one that specifies
		the label range allocation (as well as requests
		it from the IETF), and a second that specifies
		the implementation guideline. I also suggest
		removal of "MPLS" from the name. This is very
		confusing, and implies that this document is
		some new standard for MPLS, whereas what it
		really specifies (sans the label range allocation
		and the OAM) is a subset of MPLS functionality.

	2)	With regard to the label range reservation, I am
		troubled by this because MPLS has been widely deployed
		without the said reserved label range. Deployment
		of LSRs that suddenly use this special label
		range will most likely lead to interoperability
		issues.  I am also troubled by the lack of
		definition of what the reserved labels should
		be used for.  If in the future, these labels are
		defined in a manner that is incompatible with
		existing LSRs, this will pose a significant
		hurdle to deployments. Again, a separate document that
		requests the label range, as well as specifies
		what they are to be used for is appropriate.

	3) 	The OAM as specified does not meet the IETF's
		requirements for OAM specified in RFC4377.
		Y.1711 is not suitable for environments where PHP is
		enabled, and it also has other deficiencies such as a
		lack of tracing functionality, and cannot handle Equal
		Cost Multi-Path (ECMP) LSPs.  In particular, section
		4.3 of RFC4377 stipulates that path characterization
		functions must be able to work in these cases:

4.3.  Path Characterization

    The path characterization function is the ability to reveal details
    of LSR forwarding operations.  These details can then be compared
    during subsequent testing relevant to OAM functionality.  This
    includes but is not limited to:

       -  consistent use of pipe or uniform time to live (TTL) models by
          an LSR [RFC3443].

       -  sufficient details that allow the test origin to exercise all
          path permutations related to load spreading (e.g., ECMP).

       -  stack operations performed by the LSR, such as pushes, pops,
          and TTL propagation at penultimate hop LSRs.

	I suggest replacing the reference to Y.1711 with a reference
	to rfc4377, rfc4378, and rfc4379.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 11 Apr 2006 09:24:55 -0400

[Resending to mpls list as I got a warning from the mailer
that there was a suspicious number of recipients, so I am not
sure it was delivered.]

	Hi,

	--Tom

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 11 Apr 2006 10:31:35 -0500

> The OAM as specified does not meet the IETF's
> enabled,

It isn't clear why ITU-T did not also specify Y.1713 (MPLS OAM
Connection Verify Mechanism compatible with LDP, shepherded through
ITU-T by David Allan)

Jerry