ietf
[Top] [All Lists]

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

2011-10-19 16:55:03
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(_at_)ietf(_dot_)org 
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of
erminio(_dot_)ottone_69(_at_)libero(_dot_)it
Sent: Wednesday, October 19, 2011 1:49 PM
To: brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com; 
yang(_dot_)jian90(_at_)zte(_dot_)com(_dot_)cn
Cc: mpls(_at_)ietf(_dot_)org; mpls-bounces@ietf.orgLarry; 
ietf(_at_)ietf(_dot_)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(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com
Data: 5-ott-2011 22.16
A: <yang(_dot_)jian90(_at_)zte(_dot_)com(_dot_)cn>
Cc: "mpls(_at_)ietf(_dot_)org"<mpls(_at_)ietf(_dot_)org>, 
"ietf(_at_)ietf(_dot_)org"<ietf(_at_)ietf(_dot_)org>,
<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(_dot_)jian90(_at_)zte(_dot_)com(_dot_)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
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls



_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>