R: 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]

 



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
>


_______________________________________________
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]