Transcript PPT Version

ITU Liaison on T-MPLS
Stewart Bryant [email protected]
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.
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.
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.
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.
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 TMPLS.
• 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.
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 TMPLS, 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.
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.