Jian, See in-line. > -----Original Message----- > From: mpls-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of > yang.jian90@xxxxxxxxxx > Sent: Wednesday, October 05, 2011 10:54 AM > To: ietf@xxxxxxxx; mpls@xxxxxxxx; mpls-bounces@ietf.orgLarry > Subject: [mpls] 答复: 回复： R: FW: Last Call: <draft-sprecher-mpls-tp- > oam-considerations-01.txt> (The Reasons for Selecting a Single Solution > for MPLS-TP OAM) to Informational RFC > > Dear All, > > I do not support either. > > In section 3.5: > If two MPLS OAM protocols were to be deployed we would have to consider > three possible scenarios: > 1) Isolation of the network into two incompatible and unconnected > islands. > > Two OAM solutions have been discussed for a long time in both ITU-T and > IETF. Repeating more times does not make the argument becoming correct. It wasted a lot of people a lot of time. > Each solution has their own supporters inculding carriers and vendors. > So I don't think there is any interworking issue between two OAM > solutions. > Carrier will select one OAM solution, A or B, in their network. > No need to select A and B at one network at the same time. > Don't think anyone said they intended to keep each of their networks/islands stay forever isolated. Two solutions bring in additional inter-op complications is a fact. > Respect their own selection and listen to their requirements, please. > Fully respect individual provider's choice of technology, that is a separate matter from standards. We are talking about IETF requirements here. Which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF? > > Best regards, > > Jian > > Thanks, Luyuan > > > > > > > Larry > <larryli888@ya > hoo.com.cn> > 收件人 > 发件人: "adrian@xxxxxxxxxxxx" > mpls-bounces@i <adrian@xxxxxxxxxxxx>, > "mpls@xxxxxxxx" > etf.org <mpls@xxxxxxxx>, "ietf@xxxxxxxx" > <ietf@xxxxxxxx>, D'Alessandro > Alessandro Gerardo > 2011-10-05 > <alessandro.dalessandro@telecomitalia. > 19:51 it> > > 抄送 > > > 主题 > [mpls] 回复： R: FW: Last Call: > <draft-sprecher-mpls-tp-oam- > considerat > ions-01.txt> (The Reasons for > Selecting a Single Solution for > MPLS-TP OAM) to Informational RFC > > > > > > > > > > > Dear all, > > So many multiple solution cases just show the way that the world > and > technology works. Killing a solution roughly brings more damage to the > industry. > > Section 3.6 discusses the elements of the choice of solutions. > Current > application and deployment should be considered. In China Mobile, more > than > 330,000 PTN box are/will based on G.8113.1. > > TDM PW gives a good example. G.8113.1 based OAM is relative simple > and > mature and widely deployed and should be the standard. > > > Best regards, > > Han Li > > --- 11年10月5日，周三, D'Alessandro Alessandro Gerardo > <alessandro.dalessandro@xxxxxxxxxxxxxxxx> 写道： > > > 发件人: D'Alessandro Alessandro Gerardo > <alessandro.dalessandro@xxxxxxxxxxxxxxxx> > > 主题: [mpls] R: FW: Last Call: > <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for > Selecting a Single Solution for MPLS-TP OAM) to Informational RFC > > 收件人: "adrian@xxxxxxxxxxxx" <adrian@xxxxxxxxxxxx>, "mpls@xxxxxxxx" > <mpls@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx> > > 日期: 2011年10月5日,周三,下午5:38 > > Dear all, > > I do not support. > > > > Basically I think it is superfluous dedicate an RFC to > > state it is better having one standard instead of two ones > > or many... for sure the lower are the variants the better is > > for the industry (one is the ideal). > > > > When two or more standards or de-facto standards exist it > > is because the problem they solve is not exactly the same, > > the way they solve the problem is optimized for different > > environments/boundary conditions (more efficient, more > > effective, etc). Therefore a single solution does not > > necessarily meet the different market requirements. > > > > It is fundamental to enter into the problem's details > > before making consideration about the best way to proceed > > (one solution, two solutions, multiple solutions) whilst the > > document clearly declares it does not want to make any > > technical evaluations. > > > > After more than three years of debates within the IETF and > > major unresolved technical concerns risen from some > > transport operators, the existence of this draft is by > > itself the sure sign that MPLS-TP OAM is a case where a > > single solution has not be found to meet all the different > > market requirements. Otherwise, why are we still discussing > > about it....? > > > > Therefore we must be realistic and the lessons learned from > > the past should guide our decisions: if a solution cannot be > > found for satisfying all the requirements it is better to > > have two standards and let the market decide how to exploit > > them. Are we really sure the cost(many) / benefit > > (none) analysis done in section 7.5 is realistic? > > > > Best regards, > > Alessandro > > > > ------------------------------------------------------------------ > > Telecom Italia > > Alessandro D'Alessandro > > Transport Innovation > > Via Reiss Romoli, 274 - 10148 Torino > > phone: +39 011 228 5887 > > mobile: +39 335 766 9607 > > fax: +39 06 418 639 07 > > > > -----Messaggio originale----- > > Da: mpls-bounces@xxxxxxxx > > [mailto:mpls-bounces@xxxxxxxx] > > Per conto di Adrian Farrel > > Inviato: lunedì 26 settembre 2011 23:58 > > A: mpls@xxxxxxxx > > Oggetto: [mpls] FW: Last Call: > > <draft-sprecher-mpls-tp-oam-considerations-01.txt> > > (The Reasons for Selecting a Single Solution for MPLS-TP > > OAM) to Informational RFC > > > > MPLS Working Group, > > > > Please be aware of the IETF last call as shown below. The > > document was presented for publication as an individual RFC > > with IETF consensus and AD sponsorship. > > > > This draft is clearly close and relevant to the work you > > do, but after discussing with the chairs I came to the > > conclusion that it does not comment on the technical or > > process decisions of the MPLS working groups, and it does > > not attempt to make any technical evaluations or definitions > > within the scope of the MPLS working group. It is more of a > > philosophical analysis of the way the IETF approaches the > > "two solutions" problem with special reference to MPLS-TP > > OAM. > > > > Thus, I am accepting the document as AD Sponsored rather > > than running it through the MPLS working group. My reasoning > > is that the working group has got plenty to do working on > > technical issues without being diverted into wider IETF > > philosophy. > > > > As an AD Sponsored I-D it is subject to a four week IETF > > last call. That is plenty of opportunity for everyone to > > comment and express their views. Please send your comments > > to the IETF mailing list as described below, or (in > > exceptional circumstances) direct to the IESG. > > > > Thanks, > > Adrian > > > > > -----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- > considerati > > > ons/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam- > considerati > > > ons/ > > > > > > > > > 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 > > > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls > > > > Questo messaggio e i suoi allegati sono indirizzati > > esclusivamente alle persone indicate. La diffusione, copia o > > qualsiasi altra azione derivante dalla conoscenza di queste > > informazioni sono rigorosamente vietate. Qualora abbiate > > ricevuto questo documento per errore siete cortesemente > > pregati di darne immediata comunicazione al mittente e di > > provvedere alla sua distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may > > contain privileged information intended for the addressee(s) > > only. Dissemination, copying, printing or use by anybody > > else is unauthorised. If you are not the intended recipient, > > please delete this message and any attachments and advise > > the sender by return e-mail, Thanks. > > > > _______________________________________________ > > mpls mailing list > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail > is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of this > communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the originator of the message. Any views expressed in this message are > those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf