1. ITU Liaison on T-MPLS Stewart Bryant stbryant@cisco.comstbryant@cisco.com

2. Background ITU SG15/12 sent a liaison to PWE3 WG, MPLS WG and MFA regarding their recently consented specification G.8110.1 (Architecture of Transport MPLS (T-MPLS) Layer Network) All three groups responded Representatives of the IETF attended the SG15/12 meeting in Ottawa 19-23 June 2006.

3. Response to PWE3 Item 10, Interworking between IP/MPLS PW and T-MPLS: The interworking between IP/MPLS PW and T-MPLS PW is at a very preliminary stage. We would like to develop this in cooperation with the IETF. The remaining items (1, 2, 3, 4, 5, 6, 7, 8, 9, 11, 12 and 13) have been accepted and addressed by modifying the text in appendix I. Specifically we have also added a clarification that the T-MPLS trail (PW trail) uses Y.1711 OAM in version 1, while the PW as defined by IETF is using VCCV. We have also updated the figures 9, 10 and 11 replacing “MPLS_CI” with “TM_CI”. Other Recommendations that may be applicable in this context (e.g. Y.17fw) have not yet been approved. The reference to the “dry-Martini” internet-draft has been removed.

4. Response to MPLS WG 1. We have not seen any documentation of the problem that T-MPLS solves. The T-MPLS requirements are implicit based on the transport network application space. To facilitate our communication with you we will document these implicit assumptions and requirements and send them to you as soon as they are available. 2. The reserved labels As this is a compatibility issue, we are very concerned. We request that you document any requirements for reserved labels and bring those requirements to the MPLS Working Group in the IETF. There is a (G)MPLS change process that can be used for this "draft-andersson-rtg-gmpls-change-02.txt" In consideration of your concerns we have agreed not to reserve any labels. If we identify any requirements to use a reserved label in the future we will make a request to the IETF mpls Working Group as you have suggested. We intend to update the existing T-MPLS Recommendations (G.8112 and G.8121) to reflect this decision.

5. Response to MPLS WG - 2 MPLS functionality equipment T-MPLS networks. 1.We discussed the PHP issue and understand that there is trade off between making Y.1711 OAM work and the implementation issues on not using PHP and we have understood that not using PHP is not an issue for the application scenario in the scope version 1. The need for supporting PHP in T-MPLS networks might be revisited in future versions. 2.In the interest of making this issue clear, we have already modified in section 6.1/G.8110.1 the sentence “The use of PHP is not supported” into “Transport MPLS LSPs do not use PHP.” 3.T-MPLS is intended to be a separate layer network with respect to MPLS. However, T- MPLS will use the same data-link protocol ID (e.g. EtherType), frame format and forwarding semantics for as those defined for MPLS frames. T-MPLS and MPLS cannot coexist on the same “interface” (for example they could not coexist on a single Ethernet VLAN, however they could be multiplexed on to a common Ethernet PHY using separate VLANs). 4.The direct adaptation of IP/MPLS client over T-MPLS server is still at a very preliminary stage. We would like to develop this in cooperation with the IETF. 5.We have also initiated work on a control plane for T-MPLS this activity is at a very preliminary stage. If our work on T-MPLS control plane identifies requirements to modify the IETF signaling protocols or use new code points, we will submit these requirements for your consideration in accordance with the (G)MPLS change process. 6.In the absence of a complete description of the intended network applications we have developed the following preliminary network application examples that may be considered as we develop future versions.

6. Response to MFA Largely the same as the responses to MPLS WG T-MPLS specifies Y.1711 OAM in version 1. We intend to work with Q.5/13 to develop diagnostic tools that are required for T- MPLS. The main considerations in selecting Y.1711 OAM were to apply to T-MPLS layer networks the same OAM concepts and paradigm (e.g. connectivity check, alarm suppression, remote defect indication) already available in other transport layer networks (e.g. SDH, OTH) inside the T-MPLS layer itself without requiring IP data plane capabilities. Other Recommendations that may be applicable in this context (e.g. Y.17fw) have not yet been approved.

7. Reply to ITU SG15/12 During the Rapporteur’s meeting, extensive technical updates were proposed and agreed to for G.8110.1 (Architecture of Transport MPLS (T-MPLS) Layer Network ). These discussions identified issues, errors, and omissions in G.8110.1, and also came up with a significant amount of new text which allows very substantial improvements to this document. These discussions also identified areas for further consideration and where additional improvements, clarifications and/or discussions are warranted, such as the need for specification of the requirements for T- MPLS, as well as for specification of the scope of applicability. We would like to strongly recommend that G.8110.1 not be published in the form that was consented prior to the Ottawa meeting, and that the substantial improvements that were agreed in the Ottawa meeting be incorporated in the text prior to publication. Furthermore, due to the extensive nature of these important improvements, and due to the existence of some further issues that warrant additional consideration, we also strongly recommend that time be allowed for review of the updated document by SG15 and IETF experts, including an additional round of liaison of this document to the IETF, and particularly to the MPLS, CCAMP, and PWE3 working groups for further review and comment. We are aware that a further Rapporteur's meeting is planned for Sophia Antipolis in the week commencing 18th September 2006, and we hope that it will be possible to facilitate attendance by non-ITU IETF experts in order to continue the excellent cooperative progress made in Ottawa. We request that any updates made to, or proposed for, the text of G.8110.1 be liaised to the IETF after the September meeting to allow us to make comments in advance of the SG15 Plenary in October/November this year. We would like to thank you and SG15 participants for the very positive interaction at the Ottawa Rapporteur’s meeting, and we look forward to continued positive interaction between ITU and IETF experts.

8. Technical Review The IETF has been sent an updated copy of G.8110.1, and has been requested to respond with technical comments before August 1st. I urge you to read the revised recommendation and give me your feedback. I will respond on behalf of the IETF PWE3 WG, and I plan to be at the next SG15/12 interim in Sofia Antipolis.