RE: [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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]