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-bounces@xxxxxxxx [mailto:mpls-bounces@xxxxxxxx] On Behalf Of > erminio.ottone_69@xxxxxxxxx > Sent: Wednesday, October 19, 2011 1:49 PM > To: brian.e.carpenter@xxxxxxxxx; yang.jian90@xxxxxxxxxx > Cc: mpls@xxxxxxxx; mpls-bounces@ietf.orgLarry; ietf@xxxxxxxx > 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.carpenter@xxxxxxxxx > >Data: 5-ott-2011 22.16 > >A: <yang.jian90@xxxxxxxxxx> > >Cc: "mpls@xxxxxxxx"<mpls@xxxxxxxx>, "ietf@xxxxxxxx"<ietf@xxxxxxxx>, > <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.jian90@xxxxxxxxxx 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 > >mpls@xxxxxxxx > >https://www.ietf.org/mailman/listinfo/mpls > > > > > _______________________________________________ > mpls mailing list > mpls@xxxxxxxx > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf