[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls]
From:       John E Drake <jdrake () juniper ! net>
Date:       2011-10-19 21:54:35
Message-ID: 5E893DB832F57341992548CDBB333163A4448A390C () EMBX01-HQ ! jnpr ! net
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]