Re: [mpls-tp] [mpls] R: MPLS WG slides from CMCC

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Thu, 16 December 2010 11:55 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FAC3A70E9; Thu, 16 Dec 2010 03:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.445
X-Spam-Level:
X-Spam-Status: No, score=-103.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2Iq1LqMfEky; Thu, 16 Dec 2010 03:55:56 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id E7F503A7047; Thu, 16 Dec 2010 03:55:55 -0800 (PST)
Received: from host1.cachelogic.com ([212.44.43.80] helo=[172.16.18.188]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1PTCSp-0001kz-0A; Thu, 16 Dec 2010 11:57:39 +0000
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=windows-1252
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <FF8F3C1FD6EDF74CB6DD38B90FDEBADB07014245@CNSHGSMBS01.ad4.ad.alcatel.com>
Date: Thu, 16 Dec 2010 11:57:33 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <9FF46488-D663-4B5C-8F74-057A687F92CC@niven-jenkins.co.uk>
References: <575335.64858.qm@web15602.mail.cnb.yahoo.com><CF9E38FB-E55F-468C-9082-1F62E80A896F@asgaard.org><4D0721EA.1030103@gmail.com><0029E41E-2032-421C-B6AC-FCC5CF3D736E@cdl.asgaard.org><4D0749B0.7070103@gmail.com><2A29F731-19CB-4831-B661-CECE714D2BD2@cdl.asgaard.org><15740615FC9674499FBCE797B011623F16D3773E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <077E41CFFD002C4CAB7DFA4386A532640313D2BC@DEMUEXC014.nsn-intra.net> <FF8F3C1FD6EDF74CB6DD38B90FDEBADB070140A9@CNSHGSMBS01.ad4.ad.alcatel.com> <077E41CFFD002C4CAB7DFA4386A532640313D63F@DEMUEXC014.nsn-intra.net> <FF8F3C1FD6EDF74CB6DD38B90FDEBADB07014245@CNSHGSMBS01.ad4.ad.alcatel.com>
To: HUANG Feng F <Feng.f.Huang@alcatel-sbell.com.cn>
X-Mailer: Apple Mail (2.1082)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: mpls@ietf.org, Ad hoc MPLS-TP <ahmpls-tp@lists.itu.int>, BUSI ITALO <Italo.Busi@alcatel-lucent.com>, Huub van Helvoort <huubatwork@gmail.com>, mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] R: MPLS WG slides from CMCC
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Dec 2010 11:55:57 -0000

On 16 Dec 2010, at 01:33, HUANG Feng F wrote:

> >The WG is currently developing solutions for the tools…some of them are already in a very good shape…
>  
> This solution can't satisfy transport requirement, the mpls-tp demo in mpls2010 shows protection switch trigged by draft-cc-cv-rdi is less than 50ms? can Nurit prove it?
> by the way, you can track the poll email in ietf mpls wg, when draft-xxx-bfd is polled as workgroup doc, there is no censuses in mpls group!

The decision has been made and the chairs have judged consensus as per the IETF's operating procedure, if folks think some injustice was done there is a general appeals process although my opinion is that it doesn't need to invoked in this case.

Personally, I don't think operators are so naive that they will deploy a solution purely because it is standardised and so if draft-bhh is a superior solution and the WG solution does not meet the needs of those operators then they will deploy and use it regardless of its standardisation status. In other words, regardless of what IETF (or any other SDO) says is the "standard" it is still up to the market to decide.

However, in the meantime I don't see repeatedly trying to re-discuss a decision that has already been made without bringing significant new technical arguments to the table as a productive use of our time. It is unlikely to reverse the previous decision and it expends a lot of cycles we could use to improve the WG selected solutions.

So can we draw a line under this discussion and concentrate on progressing the existing MPLS-TP solutions that are WG documents?

Regards
Ben