Hi, I would like to appreciate the editors' efforts to try to examine the consequences of the existence of two MPLS-TP OAM solutions, however I don't understanding the meaning to publish this draft at this stage. I agree that one solution is desirable described. However, considering the extraordinary efforts made by IETF and ITU-T, this case corresponds to an unavoidable case which is described in RFC1958. That is, both OAM solutions(G.8113.1 and G.8113.2) are worth being standardized. Positive sides of having the second solution should be valued more in terms of further development of MPLS-TP technology rather than the negative sides such as complexity. The followings are the reasons that I stated above. 1) In general, both OAM solutions(G.8113.1 and G.8113.2) seem to be supported by two different large communities of interest internationally. Therefore, standardization of both OAM solutions will be best choice for the future development of MPLS-TP technology, which I believe is a common goal/wish for both communities. 2) A lot of operators/users have been waiting for the MPLS-TP standards for a long time, since MPLS-TP work started. Generally, no one doubt that one solution for one functional requirement is best as mentioned in this draft. As a result, in my understanding, a lot of efforts have been made to achieve the goal for about 3-4 years by IETF and ITU-T, but the consequence is what we are facing now. It should be seriously considered that the current status is the result of extraordinary efforts. Accordingly, limiting the solution only one (publishing the this draft) at this stage doesn't seem to be reasonable, because all the efforts made by experts in both parties (IETF and ITU-T) are enough to be respected. 3) It is true that MPLS-TP is a MPLS technology. It is also true that MPLS-TP is a transport technology. What I learned so far is that both technologies possess their own histories, experiences and established reliabilities in OAM solutions (G.8113.2(BFD&LSP ping based) and G.8113.1(Ethernet-based OAM) and very hard to radically change their assets. If I quote the good expression from the draft, each side wishes a soft transition rather than a cliff. 4) MPLS-TP is a joint work which has a great potential to create future innovative MPLS-based transport networks for operators/users. But, I think they will never be achieved without collaboration. 5) I understand the difficulties and complexities which were described in this draft, but I believe it's worth challenging for both implementers and operators. 6) There are a number of positive sides by containing the G.8113.1(Ethernet-based OAM) solution. -It seems that the integrity of control plane protocol on the OAM solution (G.8113.1) can be maintained as seen in ASON & GMPLS relationship. If necessary, it might be easy to apply the control plane to Ethernet OAM configuration. -Expanding Carrier Ethernet based on Ethernet OAM is considered to be one of the major traffics for future MPLS-TP transport networks. The OAM solution(G.8113.1) can alleviate the anxiety of some operators who would like to migrate their networks with soft transition from Ethernet/SDH networks, because those operators/users have doubt about the feasibility of having the similar operational experiences with transport network OAM(covered by Ethernet OAM) by applying G.8113.2(BFD based) OAM. This will increase the opportunity of the deployment of MPLS-TP. -Lately, both Ethernet OAM and MPLS-TP OAM tend to be implemented in one box (equipment) to flexibly respond to the uses needs. In this kind of product, the complexity of implementation will be mitigated. Best regards, Yoshinori -----Original Message----- From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce- bounces@xxxxxxxx] On Behalf Of The IESG Sent: 26 September 2011 20:43 To: IETF-Announce Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM' <draft-sprecher-mpls-tp-oam-considerations-01.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2011-10-24. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments. That is, MPLS-TP is a set of functions and features selected from the wider MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks. During the process of development of the profile, additions to the MPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment. One major set of additions provides enhanced support for Operations, Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address these OAM requirements, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. The file can be obtained via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf-announce -- Yoshinori Koike koike.yoshinori@xxxxxxxxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf