MPLS Working Group                                          Fang Li (Ed)
Internet Draft                                                CATR,China
Intended status: Informational                               Han Li (Ed)
                                                            China Mobile
                                              Alessando D'Alessandro(Ed)
                                                          Telecom Italia
                                                       Ruiquan Jing (Ed)
                                                           China Telecom
                                                      Guangquan Wang(Ed)
                                                            China Unicom
                                    Juan Pedro Fernandez-Palacios Gi(Ed)
                                                          Telefonica I+D

Expires: January 2012                                      July 11, 2011


             Operator Considerations on MPLS-TP OAM Mechanisms
                 draft-fang-mpls-tp-oam-considerations-02


                            Status of this Memo


   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).



Fang et al.           Expires January 11, 2012                [Page 1]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abstract

   Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is
   based on a profile of the MPLS and pseudo wire (PW) procedures as
   specified in the MPLS Traffic Engineering (MPLS-TE), pseudo wire (PW)
   and multi-segment PW (MS-PW) architectures complemented with
   additional Operations, Administration and Maintenance (OAM)
   procedures for fault, performance and protection-switching management
   for packet transport applications that do not rely on the presence of
   a control plane.

   This document is intended to explain the criticality of progressing
   the essential suite of MPLS-TP OAM solution elements in order to meet
   the urgent and increasing requirements for metro packet transport
   networks. It describes examples of key packet transport network
   applications for several operators, reviews associated MPLS-TP
   service provider requirements, and analyzes MPLS-TP OAM solution
   approaches that have been submitted to the IETF.  Based upon this, it
   is recommended that the solution elements described in draft-bhh-
   mpls-tp-oam-y1731 [6] be included within the MPLS-TP toolkit for
   supporting MPLS-TP OAM Functions, and that the draft be progressed as
   a Standards Track RFC.

Table of Contents

   1. Introduction.................................................3
      1.1. Contributing Authors....................................4
   2. Conventions used in this document............................4
      2.1. Terminology.............................................4
   3. PTN network Applications.....................................4
      3.1. Summary of MPLS-TP based PTN Applications...............4
      3.2. China Mobile............................................5
      3.3. China Telecom...........................................6
      3.4. China Unicom............................................6
      3.5. Telecom Italia..........................................7


Fang et al.           Expires January 11, 2012                [Page 2]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
      3.6. Telefonica I+D..........................................7
   4. Requirement of MPLS-TP OAM function toolset..................7
   5. OAM solutions................................................8
      5.1. draft-bhh solution approach.............................8
      5.2. Extension of IP/MPLS OAM tools approach.................9
      5.3. Development of new OAM tools approach..................10
   6. Interoperability of draft-bhh implementations...............10
   7. Considerations..............................................12
   8. Proposal....................................................13
   9. Security Considerations.....................................13
   10. IANA Considerations........................................13
   11. Acknowledgments............................................13
   12. References.................................................14
      12.1. Normative References..................................14
      12.2. Informative References................................14

1. Introduction

   This document is intended to explain the criticality of progressing
   the essential suite of MPLS-TP OAM solution elements in order to meet
   the urgent and increasing requirements for metro packet transport
   networks (e.g. mobile backhauling). It describes examples of key
   packet transport network applications for several operators, reviews
   associated MPLS-TP network operators' requirements (which is defined
   in RFC5654 [1]), and analyzes MPLS-TP OAM solution approaches that
   have been submitted to the IETF.  Based upon this, it is recommended
   that the solution elements described in draft-bhh-mpls-tp-oam-y1731
   [6] be included within the MPLS-TP toolkit for supporting MPLS-TP OAM
   Functions, and that the draft be progressed as a Standards Track RFC.

   This solution satisfies essential MPLS-TP OAM requirements as defined
   in RFC5860 [3], and has been tested, validated and deployed by
   several operators. While draft-bhh-mpls-tp-oam-y1731 [6] documents
   these solution elements within a single document, the solution
   approach allows operators to select the particular OAM functions they
   wish to use. Thus, it can complement other solution elements, as it
   does not deprecate existing MPLS and PW OAM mechanisms or preclude
   definition/utilization of other MPLS-TP OAM tools.

   The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates
   Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC
   5586 [2] and the draft-ietf-mpls-tp-oam-framework [5]. This approach
   leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and
   IETF RFC 5586 mechanisms to provide a set of MPLS-TP OAM mechanisms
   that satisfy RFC5860 requirements and fit within the MPLS-TP OAM
   framework as described in draft-ietf-mpls-tp-oam-framework [5].  This
   offers an excellent example of what could be considered a cooperative
   product of IETF and ITU-T, which builds upon the experience of both


Fang et al.           Expires January 11, 2012                [Page 3]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   standards development organizations, to provide a robust and timely
   solution.

      1.1. Contributing Authors

   Haiyi Zhang, Lei Wang, Yusen Yang, Pei Zhang, Andrea Di Giglio

2. Conventions used in this document

   2.1. Terminology

   AIS      Alarm Indication Signal

   CC       Continuity Check

   CFI      Client Failure Indication

   CV       Connectivity Verification

   DM       Packet Delay Measurement

   LB       Loopback

   LM       Packet Loss Measurement

   MPLS-TP   MPLS Transport Profile

   OAM      Operation, Administration and Management

   PTN      Packet Transport Network

   RDI      Remote Defect Indication

   TCM      Tandem Connection Monitoring

3. PTN network Applications

      3.1. Summary of MPLS-TP based PTN Applications

   Current requirements of operators for supporting MPLS-TP based PTN
   applications are mainly driven by mobile backhauling and L2 VPN
   services for business customers.

   In typical network deployments, IP-based and transport-based
   environments are separated. IP backbone and metro core networks are
   based on IP/MPLS routers, while metro aggregation and access networks
   are based on PTN equipments.  Of these, for several operators, the


Fang et al.           Expires January 11, 2012                [Page 4]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   most urgent MPLS-TP application scenarios are for the PTN-based metro
   networks, which are separated in the existing networks from the core
   IP/MPLS networks. However, in the future, deployments of MPLS-TP
   within backbone/core networks are not precluded.

   The following section provides some examples of PTN applications in
   many operators' metro networks, to illustrate the urgent market
   requirement for MPLS-TP to be standardized in a reasonable way as
   soon as possible.

   Although the functionality of MPLS-TP OAM is more important than the
   message format of OAM, when operators began to widely deploy MPLS-TP
   technology, the network interworking between each vendor becomes a
   key concern. Usually, there are at least two vendor's equipments in
   one metro network. In order to provide end-to-end reliable services
   (such as L2 VPN) supporting OAM and protection, the requirement for
   standardized OAM PDU formats and procedures is urgent.

   Hundreds of thousands of MPLS-TP based PTN boxes are being deployed
   in countries such as Korea, China, Japan, India, Italy, etc. More and
   more operators have started/are planning to test all the available
   draft about MPLS-TP OAM to explore how far the proposed solutions
   (from standard bodies and fora) and already available vendor
   solutions can satisfy operators' requirements for superior protection,
   fault and performance management in the MPLS-TP space. Many operators
   are actively monitoring and contributing to the MPLS-TP
   standardization process with the aim to get shortly a comprehensive
   implementation of latest drafts as required from the market trend.
   While it would be desirable to converge to a single solution in the
   end, the viability of all protocol proposals on the table should be
   explored at this point.

      3.2. China Mobile

   China Mobile had deployed 38315 PTN nodes in 138 metro networks in
   2009 and has deployed more than 110,000 PTN nodes in 28 of 31
   provinces's metro network till September 2010. And more than 130,000
   PTN boxes will be deployed in 2011. PTN deployment speeds up in 2011
   with the roll out of 3G base stations.

   According to the PTN OAM specifications in CCSA PTN standards and
   China Mobile PTN equipment requirements, the main PTN vendors have
   already finished the new OAM software version development based on
   draft-bhh-mpls-tp-oam-y1731 and passed the experimental upgrade test
   from ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 in lab from May to
   July 2010.




Fang et al.           Expires January 11, 2012                [Page 5]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   In Aug. 2010, China Mobile has successfully carried out a large scale
   field trial whose objective was to upgrade the PTN OAM protocols
   based on ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 [6]. The main
   PTN vendors have participated in this upgrading field trial. The
   trial results show that PTN OAM smoothly upgrading from ITU-T G.8114
   to draft-bhh-mpls-tp-oam-y1731 is already a mature approach. Such
   field trial has involved 422 PTN nodes in 3 cities. Since then, such
   network has been running with OAM functionalities based on draft-bhh-
   mpls-tp-oam-y1731 without any problem.

   In July 2011, CMCC has successfully migrated 10,000 nodes from G.8114
   PTN OAM to draft-bhh-mpls-tp-oam-y1731 PTN OAM and has deployed
   additional 160,000 new nodes running just draft-bhh-mpls-tp-oam-y1731
   PTN OAM. PTN box deployed in 2011 will support draft-bhh only, by the
   end of this year, all 330,000 PTN equipments in CMCC will run draft-
   bhh only.


   In a typical China Mobile metro network, there are several thousands
   PTN nodes to provide wireless backhauling, broadband (PON-OLT)
   backhauling, 10M/100M/GE private line services.

      3.3. China Telecom

   China Telecom has evaluated the application of PTN technologies for
   more than two years and concluded that Mobile backhaul and Ethernet
   Line service will be the main service drivers to deploy PTN. China
   Telecom regarded PTN technology to be mainly based on MPLS-TP.
   Further more it is necessary to build a PTN network that satisfies
   the rapidly growing mobile service (currently growing on the order of
   millions of customers per month) in wireless network.

   China Telecom has selected PTN as one of the mobile backhaul
   solutions for its CDMA 2000 EV-DO networks. For example, a PTN
   network with 2200 nodes has been built in Chongqing, Sichuan. Two
   commercial trial PTN networks have been built in Jiangsu and Hubei
   province.

      3.4. China Unicom

   China Unicom regards PTN technology as key for multi-service
   transport platforms. Currently, MSTP is still the preferred transport
   technology for China Unicom. However, from the long-term point of
   view, PTN technology will be important for transport platforms. So
   since 2009, China Unicom has been organizing a large scale PTN
   testing activities to evaluate the maturity and feasibility of PTN
   networks.



Fang et al.           Expires January 11, 2012                [Page 6]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   In 2010, China Unicom has deployed PTN technology in some field trail
   networks. In 2011, China Unicom has started to build PTN commercial
   trail networks in more than 10 cities.

   3.5. Telecom Italia

   Telecom Italia investigated PTN technologies and has been testing
   several vendors' PTN equipment.  Telecom Italia has recently
   finalized a tender for acquiring PTN equipment and is going to deploy
   them in the second half of 2011 in its metro aggregation networks. TI
   is therefore interested in a fast definition of MPLS-TP
   specifications in order to guarantee the interworking between
   different implementations, particularly in respect to OAM and
   protection mechanisms.

   3.6. Telefonica I+D

   Telefonica I+D, as R&D branch of Telefonica Group, is investigating
   end to end PTN based network architectures based on the deployment of
   PTN technologies in both metro aggregation and core networks. Main
   drivers for end to end PTN networks are:

   1. Automated end to end service provisioning (e.g L2 VPNS between
      different metro networks)

   2. Automated network failure detection and restoration by end to end
      OAM mechanisms

   MPLS-TP is one of the PTN technologies under analysis. According to
   it, Telefonica I+D is interested in the definition of MPLS-TP
   specifications enabling OAM multi-vendor compatibility in end to end
   MPLS-TP networks.

4. Requirement of MPLS-TP OAM function toolset

   From operator's view, the following OAM toolset and functionality are
   essential for MPLS-TP deployment for PTN applications:

   1. Pro-active Continuity Check and Connectivity Verification: to
      support protection switching and misconnection detection;

   2. Alarm and Lock reporting: to suppress pro-active CC/CV alarm
      storms;

   3. Remote Defect Indication: to support bi-direction performance
      monitoring and single-ended fault management of bi-directional
      connections;



Fang et al.           Expires January 11, 2012                [Page 7]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   4. Pro-active and on-demand packet Loss/Delay Measurement: to be able
      to compare the PM on the same path provide by ETH OAM and MPLS-TP
      OAM. E.g. LM/DM should have the same behavior and results in both
      Ethernet and MPLS-TP;

   5. Client Failure Indication(CFI): to support services where alarm
      propagation capabilities are not available/supported by the client
      traffic (e.g., EPL services connecting two CEs not supporting
      Ethernet OAM);

   6. On-demand CV and diagnostic test: to allow service providers to
      localize fault (at least the Loop-back tool) and check the out-of-
      service test before service commissioning;

   7. Tandem Connection Monitoring(TCM): for any transport path (e.g.,
      LSPs and PWs) to support inter-domain monitoring;

   Note: the OAM tools of Route Tracing to support on-demand CV in
   connection-oriented PTN network is not needed, for the transport path
   can be get in the PTN NMS trail management function.

5. OAM solutions

   The operator's preference for a particular OAM solution depends on
   the application domain and their network evolution strategy.

   o For the PTN application domain described in this draft, the
      priority is maximal synergy with transport-oriented operations and
      managerial practices. The solution based upon draft-bhh-mpls-tp-
      oam-y1731 [6] is consistent with this desired optimization.

   o For some other operators who are evolving from an IP/MPLS
      environment, leveraging on IP-oriented mechanisms such as BFD and
      LSP-Ping is preferable (where possible to do so).

   Both operator viewpoints are valid and standards should be capable of
   providing interoperable solutions to meet the entire operator
   community needs.

   Different approaches have been submitted to the IETF standardization
   process and are summarized in the next sections.

   5.1. draft-bhh solution approach

   The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates
   Y.1731 [4] OAM PDUs within MPLS-TP OAM packets in compliance with RFC
   5586 [2] and draft-ietf-mpls-tp-oam-framework [5]. This approach
   leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and


Fang et al.           Expires January 11, 2012                [Page 8]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   IETF RFC 5586 [2] mechanisms to provide the essential set of OAM
   mechanisms that meet the MPLS-TP OAM requirements as defined in RFC
   5860 [3].

   ITU-T Recommendation Y.1731 [4] specifies:

   o OAM PDUs and procedures that meet the transport networks
      requirements for OAM

   o Encapsulation mechanisms to carry these OAM PDUs within Ethernet
      frames to provide Ethernet OAM capabilities in Ethernet networks

   The first release of ITU-T Rec. Y.1731 [4] was approved in May 2006.
   This Recommendation meets the operator's OAM requirements for
   supporting end-to-end Ethernet services, which represents the most
   popular and increasing market for operators and services providers.

   Although Y.1731 [4] is focused on Ethernet service OAM, the
   definition of OAM PDUs and procedures are technology independent and
   can also be used for other packet technologies (e.g., MPLS-TP)
   provided that the technology specific encapsulation is defined.

   The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates
   Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC
   5586 [2] and draft-ietf-mpls-tp-oam-framework [5] (i.e., the OAM PDUs
   are carried over the G-ACH [2]).

   While draft-bhh-mpls-tp-oam-y1731 [6] documents these solution
   elements within a single document, the solution approach allows
   operators to select the particular OAM functions they wish to use.
   Thus, it can complement other solution elements, as it does not
   deprecate existing MPLS and PW OAM mechanisms or preclude
   definition/utilization of other MPLS-TP OAM tools.

   5.2. Extension of IP/MPLS OAM tools approach

   Another solution approach is to extend IP/MPLS OAM tools to meet the
   MPLS-TP OAM requirements as defined in RFC 5860 [3].

   Some work in this direction is ongoing in draft-ietf-mpls-tp-cc-cv-
   rdi [7] and draft-ietf-mpls-tp-on-demand-cv [9]. This approach is
   currently limited to support only the pro-active CC, CV, RDI and
   on-demand CV and tracerouting functions as defined in RFC 5860 [3].

   So far a lot of technical difficulties have been encountered in
   meeting some important transport requirements and behaviours, while
   maintaining backward compatibility with existing BFD and LSP Ping
   implementations. Those technical difficulties have not been resolved


Fang et al.           Expires January 11, 2012                [Page 9]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   even during MPLS WG Last Call and the solution drafts that have been
   moved toward IESG Processing still do not meet the transport
   networks' needs for several service providers.



   5.3. Development of new OAM tools approach

   For other OAM functions described in RFC 5860 [3] and not covered by
   the extensions of existing IP/MPLS OAM tools (mentioned in section
   5.2), new tools would need to be developed.

   A series of separated drafts have been submitted with different
   maturity levels and there are some overlaps and inconsistencies that
   need to be resolved. These drafts appear to re-use some Y.1731 [4]
   information elements (e.g., draft-ietf-mpls-tp-loss-delay-profile
   [8]).



6. Interoperability of draft-bhh implementations

   As discussed earlier, interoperability testing of multi-vendor
   implementations continues to be conducted by various operators.

   Public interoperability events have also been conducted, as described
   below.

   In Sep. 2009 CEWC, EANTC conducted an MPLS-TP interoperability test
   and reported:

   "Different solutions have been proposed in individual author drafts
   such as draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi [10] and
   draft-bhh-mpls-tp-oam-y1731 [6], however the working group has not
   yet accepted these documents as IETF working group drafts.  The
   purpose of EANTC's effort is to evaluate the current status of the
   industry and to examine progress made since their last test in
   February.  The two OAM proposals tested have received substantial
   vendor and service provider backing, so EANTC were able to stage
   multi-vendor interoperability tests. The Alcatel-Lucent 1850 TSS-160,
   Alcatel-Lucent 1850 TSS-320, and Huawei PTN 3900 successfully tested
   an interoperable OAM solution based on the draft-bhh-mpls-tp-oam-
   y1731 [6] which proposes modifications to Ethernet OAM tools as
   defined in ITU-T Y.1731 [4] for use with MPLS-TP OAM.  The enhanced
   BFD protocol was used to check the continuity (liveliness) of the
   MPLS-TP LSP established between the Ericsson devices.  Both OAM
   solutions were verified for the use of GAL and G-ACh."



Fang et al.           Expires January 11, 2012               [Page 10]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   The EANTC whitepaper can be getting at:

   http://www.eantc.com/fileadmin/eantc/downloads/events/2007-
   2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf (P.16~17).

   In Feb. 2010 MPLS &Ethernet WC, EANTC conducted another MPLS-TP
   interoperability test and reported:

   "EANTC tested the MPLS-TP OAM approach supported by Alcatel-Lucent,
   Huawei, and ZTE based on Y.1731 [4].  The Alcatel-Lucent 1850 TSS-
   320, Huawei PTN 3900, and ZTE ZXCTN 6100 all successfully tested
   interoperability for their MPLS-TP OAM implementations, based on ITU-
   T Y.1731 which defines a protocol for Ethernet OAM.  EANTC tested
   this by first verifying that the protocol was used by all vendors to
   establish connectivity on the respective MPLS-TP transport path, and
   their ability to switch over to a backup transport path upon loss of
   such connectivity. Between those devices was a LAN segment, to make
   sure that the trigger was the loss of CCM frames (not the LOS)."

   The EANTC whitepaper can be getting at:

   http://www.eantc.com/fileadmin/eantc/downloads/events/2007-
   2010/MPLSEWC2010/EANTC-MPLSEWC2010-WhitePaper.pdf (P.13~14).

   In Sep. 2010 CEWC, EANTC conducted an MPLS-TP 1:1 LSP protection
   interoperability test and reported:

   "Most recently, one of the author drafts for a Bidirectional
   Forwarding Detection (BFD) based OAM titled 'Proactive Connection
   Verification, Continuity Check and Remote Defect Indication for MPLS
   Transport Profile' has been accepted by the IETF MPLS working group.
   In parallel, a series of vendors registered to the interop event
   ready to test their OAM solutions based on ITU-T Recommendation
   Y.1731[6]".

   "In order to perform this test several multi-vendors pairs were
   built... The observed failover times ranged between 13 to 28 ms for
   link failure. The OAM tools from these vendors was based on draft-
   bhh-mpls-tp-oam-y1731 and the linear protection was tested according
   to draft-zulr-mpls-tp-linear-protection-switching-01."

   The EANTC whitepaper can be downloaded at:

   http://www.eantc.de/fileadmin/eantc/downloads/events/2007-
   2010/CEWC2010/EANTC-CEWC2010-WhitePaper-v1_1.pdf (P.17~18)





Fang et al.           Expires January 11, 2012               [Page 11]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
7. Considerations

   For PTN-based metro aggregation and access networks, the OAM
   mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] fully satisfy
   all the essential MPLS-TP OAM requirements.

   The operators who have contributed to this draft fully support global
   standards, and have relied upon the work of ITU-T and IETF.  For this
   reason, full support was given to the JWT agreement reached between
   ITU-T and IETF, whose goal was to define the required MPLS-TP
   standard solutions by October 2009.  However, after waiting for over
   two years, the essential solutions are still not available, and based
   on the ongoing technical discussions there is great concern that a
   solution will not be available in time for the planned deployments.
   MPLS-TP based PTN significant deployment has started in this year.
   There is urgency for standard MPLS-TP solutions this year to support
   PTN applications, which are based on mature, multi-vendor
   interoperable and tested mechanisms and procedures.

   The maturity of OAM mechanisms is a key concern for operators. The
   OAM toolset defined in Y.1731 [4] has emerged as a high benchmark for
   OAM capabilities for support of managed end-to-end Ethernet services.
   Using the approach in draft-bhh-mpls-tp-oam-y1731 [6], which is based
   on proven ITU-T Y.1731 [4] OAM mechanisms and procedures, can help
   the industry in providing MPLS-TP technology in time to meet market
   needs. Also, for those operators who will have their PTN network
   managed and maintained by their transport staff, this approach offers
   the most expedient way to deploy MPLS-TP technology, as the
   mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] are very
   similar to those of transport OAM.

   Operator's OAM preference depends on the application domains, network
   evolution strategy, etc. The roadmap for OAM toolset standardization
   based on re-use of IP tools and development of new tools does not
   meet the market needs of some operators like China Mobile, Telecom
   Italia, China Telecom and China Unicom, and therefore, for the sake
   of satisfying market needs, the solution described in draft-bhh-mpls-
   tp-oam-y1731 [6], which leverages existing ITU-T and IETF standards,
   should be taken into account.

   In June 2010, during the ITU-T SG15 meeting, some members asked ITU-T
   to liaise IETF the request to provide roadmap for MPLS-TP OAM toolset
   and related internet drafts by sending a liaison to IETF. However,
   roadmap was not clarified by IETF during the IETF 78 and in the
   response liaison.

   Moreover no action was taken about the proposal to get draft-bhh-
   mpls-tp-oam-y1731 [6] included within the MPLS-TP toolkit although


Fang et al.           Expires January 11, 2012               [Page 12]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   the discussion during the MPLS-TP sessions had been heavily focused
   on MPLS-TP OAM and many operators and vendors expressed a clear
   support for draft-bhh-mpls-tp-oam-y1731[6].

   Currently, the schedule for completion of MPLS-TP OAM toolsets and
   related drafts/RFCs in IETF is not clear so negatively affecting the
   MPLS-TP standardization process in both IETF and ITU-T and the
   telecommunication industry as a whole.

   As discussed earlier, this proposal allows operators to select the
   particular OAM functions they wish to use, and can complement other
   MPLS-TP OAM solution elements currently under definition in the IETF.

8. Proposal

   This Informational Internet-Draft is aimed at moving forward the
   progress of an essential MPLS-TP OAM solution set to meet the urgent
   and increasing requirements of PTN applications for the metro packet
   transport network. Therefore, it is recommended that the solution
   elements described in draft-bhh-mpls-tp-oam-y1731 [6] be included
   within the MPLS-TP toolkit for supporting MPLS-TP OAM Functions, and
   that the draft be progressed as a Standards Track RFC.

9. Security Considerations

   There are not any security considerations in this draft.

10. IANA Considerations

   No new IANA considerations.

11. Acknowledgments

   The authors would like to thank the good cooperation between IETF and
   ITU-T and thanks all IETF experts and ITU-T experts work on MPLS-TP
   technology to push MPLS-TP standard rapidly.













Fang et al.           Expires January 11, 2012               [Page 13]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
12. References

  12.1. Normative References

   [1]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Ueno,
         S., "MPLS-TP Requirements", RFC 5654, September 2009

   [2]  Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
         "MPLS Generic Associated Channel", RFC 5586, June 2009

   [3]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
         MPLS Transport Networks", RFC 5860, May, 2010

   [4]  ITU-T Recommendation Y.1731 (02/2008), " OAM functions and
         mechanisms for Ethernet based networks ", Feb,2008

   [5]  I. Busi, B. Niven-Jenkins, D. Allan," MPLS-TP OAM
         Framework",draft-ietf-mpls-tp-oam-framework-11 (work in
         progress)

   [6]  I. Busi, H. van Helvoort, J.He "MPLS-TP OAM based on Y.1731",
         draft-bhh-mpls-tp-oam-y1731-06 (work in progress)

  12.2. Informative References

   [7]  Dave Allan, George Swallow, John Drake, "Proactive Connection
         Verification, Continuity Check and Remote Defect indication for
         MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-05 (work
         in progress)

   [8]  Dan Frost, Stewart Bryant, "Packet Loss and Delay Measurement
         for the MPLS Transport Profile" draft-ietf-mpls-tp-loss-delay-
         profile-03 (work in progress)

   [9]  N. Bahadur, R. Aggarwal, S. Boutros, E. Gray, "LSP-Ping
         extensions for MPLS-TP" draft-ietf-mpls-tp-on-demand-cv-05
         (work in progress)

   [10] A. Fulignoli , S. Boutros , M.Vigoureux ," MPLS-TP BFD for
         Proactive CC-CV and RDI ",draft-fulignoli-mpls-tp-bfd-cv-
         proactive-and-rdi-01 (expired and merged into draft-ietf-mpls-
         tp-cc-cv-rdi; work in progress)








Fang et al.           Expires January 11, 2012               [Page 14]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
Authors' Addresses

   Fang Li (Editor)
   China Academy of Telecommunication Research, P.R.China

   Email: lifang@catr.cn


   Han Li (Editor)
   China Moblie

   Email: lihan@chinamobile.com


   Alessando D'Alessandro (Editor)
   Telecom Italia

   Email: alessandro.dalessandro@telecomitalia.it


   Guangquan WANG (Editor)
   China Unicom

   Email: wanggq@dimpt.com


   Ruiquan Jing (Editor)
   China telecom

   Email: jingrq@ctbri.com.cn


   Juan Pedro Fernandez-Palacios Gi
   Telefonica I+D

   Email: jpfpg@tid.es


Contributing Authors' Addresses

   Haiyi Zhang
   China Academy of Telecommunication Research, P.R.China

   Email: zhanghaiyi@catr.cn






Fang et al.           Expires January 11, 2012               [Page 15]


Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms   July
2011
   Lei Wang
   China Mobile

   Email: wangleiyj@chinamobile.com


   Pei zhang
   China Unicom

   Email: hq-zhangp@chinaunicom.cn


   Yusen Yang
   China Telecom

   Email: yangys@chinatelecom.com.cn


   Andrea Di Giglio
   Telecom Italia

   Email: andrea.digiglio@telecomitalia.it



























Fang et al.           Expires January 11, 2012               [Page 16]