Alessandro, Apparently, the advice given regarding the risks and costs associated with deploying proprietary or pre-standard solutions didn't resonate with you. Do you really expect the rest of us to clean up after you?
Thanks, John > -----Original Message----- > From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of > erminio.ottone...@libero.it > Sent: Wednesday, October 19, 2011 1:49 PM > To: brian.e.carpen...@gmail.com; yang.jia...@zte.com.cn > Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org > Subject: [mpls] R: Re: 答复: 回复： 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 > > If the MPLS WG had selected the OAM solution that was already existing > (as > indicated multiple times by the operators which have already massively > deployed > it), we would have had a single OAM solution both in the market and in > the IETF > RFCs. > > We now have "two" OAM solutions: one (which is not actually really > singular) > documented by IETF RFCs and one widely implemented and deployed. This > draft is > not resolving this issue at all. > > >----Messaggio originale---- > >Da: brian.e.carpen...@gmail.com > >Data: 5-ott-2011 22.16 > >A: <yang.jia...@zte.com.cn> > >Cc: "m...@ietf.org"<m...@ietf.org>, "ietf@ietf.org"<ietf@ietf.org>, > <mpls- > bounces@ietf.orgLarry> > >Ogg: 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 > > > >Hi Jian, > > > >On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote: > >> 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. > >> 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. > > > >There are two large costs that you are ignoring: > > > >a) all vendors wishing to bid for business from A and B will have to > > implement and support both solutions. > > > >b) when A buys B or B buys A, the incompatible networks will have to > > be merged. > > > >These are costs that run to hundreds of millions of USD, EUR or CNY. > >They are costs caused directly by SDOs creating rival solutions. > > > >I think it would be irresponsible of the IETF not to document this > >situation. As engineers, we have an ethical responsibility here. > > > > Brian > >_______________________________________________ > >mpls mailing list > >m...@ietf.org > >https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > m...@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
