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

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

 



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: &lt;draft-sprecher-
> mpls-tp-oam-
> considerations-01.txt&gt; (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



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