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

<andy.bd.reid@bt.com> Wed, 15 December 2010 12:00 UTC

Return-Path: <andy.bd.reid@bt.com>
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 4F62428C10F; Wed, 15 Dec 2010 04:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.927
X-Spam-Level:
X-Spam-Status: No, score=0.927 tagged_above=-999 required=5 tests=[AWL=-2.073, BAYES_00=-2.599, CN_BODY_711=0.243, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
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 AvkBjNfNp4qM; Wed, 15 Dec 2010 04:00:54 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 9E9B528C0D8; Wed, 15 Dec 2010 04:00:53 -0800 (PST)
Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 15 Dec 2010 12:02:35 +0000
Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 15 Dec 2010 12:02:34 +0000
Received: from EMV02-UKBR.domain1.systemhost.net ([169.254.1.179]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Wed, 15 Dec 2010 12:02:34 +0000
From: <andy.bd.reid@bt.com>
To: <ben@niven-jenkins.co.uk>, <huubatwork@gmail.com>
Date: Wed, 15 Dec 2010 12:02:33 +0000
Thread-Topic: [mpls] [mpls-tp] MPLS WG slides from CMCC
Thread-Index: AcubstE5mTb9K67OT56jP7Q/YeGXhQAnFggg
Message-ID: <19F0B4CE377654418760FE8A13EA7255055C9543FF@EMV02-UKBR.domain1.systemhost.net>
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> <AC13FBBA-B612-480F-BFE6-1D587FD308F0@niven-jenkins.co.uk>
In-Reply-To: <AC13FBBA-B612-480F-BFE6-1D587FD308F0@niven-jenkins.co.uk>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: mpls@ietf.org, ahmpls-tp@lists.itu.int, mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] 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: Wed, 15 Dec 2010 12:00:56 -0000

I seem to remember that pseudo wires were widely implemented as a "de facto" standard while still an internet draft. And this was the case for a considerable length of time.

Andy

Andy Reid
Chief Network Services Strategist
BT Innovate
                                                                                          
Office:	+44 (0)20 8726 3075
Mobile:	+44 (0)7917 025451
Fax :       +44 (0)1277 324015
Email:	andy.bd.reid@bt.com
WWW:	http://www.bt.com/

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On 
> Behalf Of Ben Niven-Jenkins
> Sent: 14 December 2010 17:17
> To: Huub van Helvoort
> Cc: mpls@ietf.org; Ad hoc MPLS-TP; mpls-tp@ietf.org
> Subject: Re: [mpls] [mpls-tp] MPLS WG slides from CMCC
> 
> Laying the history and various grievances related to 
> draft-bhh aside as they are orthogonal to Chris' point.
> 
> Chris is right. The boiler plate of all Internet-Drafts states:
> 
>    Internet-Drafts are draft documents valid for a maximum of 
> six months
>    and may be updated, replaced, or obsoleted by other 
> documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
> If someone (or some organisation) wishes to ignore that 
> advice then it is a case of caveat emptor.
> 
> Some other SDO normatively referencing an Internet-Draft is 
> not (IMO) justification to make the referenced draft Standards Track.
> 
> Having significant deployment(s) may make it worthwhile to 
> document the technology in an RFC of some kind (but not by 
> itself sufficient to justify a Standards Track RFC IMO)
> 
> WG consensus should be used to judge what documents the WG 
> adopts & how they are then progressed.
> 
> 
> Ben
> 
> 
> 
> On 14 Dec 2010, at 10:40, Huub van Helvoort wrote:
> 
> > Hej Christopher,
> > 
> > Please see in-line [hvh]
> > 
> >> I don't believe I do. The requirements document just that, 
> >> requirements, not solutions. After RFC5860 was published, a few 
> >> potential solutions to the requirements set out in RFC5860 
> were proposed, one of those is bhh.
> >> Just because bhh supposedly responds to RFC5860 does not 
> mean that it 
> >> automatically becomes a standard. The road to standardization has 
> >> many corpses along it (look at the road to IPng, for example, or 
> >> idr). Just because it responds to RFC5860 does not change the fact 
> >> that a draft is just that, a draft. That draft isn't even 
> accepted as 
> >> a working-group document yet.
> > 
> > [hvh] one of the reasons for *not* accepting it as WG draft 
> was that 
> > there were too many co-authors.
> > 
> >> Therefore, basing your technology around it is a dice 
> roll. I assume 
> >> that CMCC has evaluated the risk of draft-bhh not becoming 
> a standard 
> >> and has decided that that risk is outweighed by whatever benefits 
> >> CMCC will derive from deploying a solution based around draft-bhh, 
> >> even if it does not become a standard. If they have, then good on 
> >> them, do what you need to do to keep your network running (I've 
> >> ventured off the trodden path once or twice myself).
> > 
> > [hvh] another reason for the selection was the availability of a 
> > solution.
> > 
> >> However, if CMCC (or any other carrier) have decided to deploy 
> >> draft-bhh based on an understanding that draft-bhh WOULD become a 
> >> standard, that would be an unfortunate misunderstanding.
> > 
> > [hvh] the fact that they are really interested in this solution is 
> > proven by the standardisation of this solution in CCSA.
> > 
> > [hvh] because service providers outside of China also want 
> to use this 
> > solution they would like to make it an international standard.
> > 
> >> It is my understanding that
> >> the working group has never guaranteed that draft-bhh 
> would become a 
> >> STANDARD, and if that had been signaled, then I would expect 
> >> draft-bhh to be a working-group draft, at least. I am not 
> saying that 
> >> it won't become a standard, I'm just saying that one (or a few) 
> >> operators
> > 
> > [hvh] it is not a few anymore.
> > 
> >> deciding to deploy something does not automatically grant 
> it a quick 
> >> path to standardization in the IETF, especially if other operators 
> >> have a differing opinion of that draft proposal.
> > 
> > [hvh] also one, or a few.
> > 
> > M.v.h. Huub.
> > 
> > ============
> >> On 14Dec2010, at 18.51, Huub van Helvoort wrote:
> >> 
> >>> Hello Chris,
> >>> 
> >>> You wrote:
> >>> 
> >>>> My concern here is that the requirements are based on a DRAFT.
> >>> 
> >>> I think you have the order wrong.
> >>> The MPLS-TP OAM requirements are in RFC5860:
> >>> http://tools.ietf.org/html/rfc5860
> >>> 
> >>> draft-bhh-MPLS-TP-OAM-Y1731 is a solution based on RFC5860.
> >>> 
> >>>> Not that
> >>>> that doesn't happen from time to time, but that does not 
> mean that 
> >>>> the IETF must then standardize that DRAFT. Someone 
> writing a spec 
> >>>> based on DRAFTs are taking an (educated) gamble that that DRAFT 
> >>>> will be standardized and supported by other vendors.
> >>> 
> >>> draft-bhh-MPLS-TP-OAM-Y1731 provides a set of tools that 
> fits in a 
> >>> larger toolbox with multiple tools.
> >>> 
> >>>> In short, the decision, is, of course, the prerogative of the 
> >>>> purchaser,
> >>> 
> >>> The service provider can pick a selection of the tools for use in 
> >>> his network by enabling the ones he needs.
> >>> CMCC and many other service providers have a preference for the 
> >>> tools provided by draft-bhh-MPLS-TP-OAM-Y1731.
> >>> 
> >>> Best regards, Huub.
> >>> 
> >>> ===================
> >>>> On 11Nov2010, at 18.52, Larry wrote:
> >>>> 
> >>>>> Dear Huub:
> >>>>> 
> >>>>> Yes!
> >>>>> Actually, China Mobile has introduced 38,000 PTN 
> equipments based 
> >>>>> on pre-standard G.8114 in 2009. China Mobile will 
> introduce more 
> >>>>> than 110,000 PTN equipments based on 
> draft-bhh-MPLS-TP-OAM-Y1731 in 2010.
> >>>>> We will upgrade G.8114 to Y.1731 based OAM by the end 
> of this year.
> >>>>> Because Draft-bhh and relevant CCSA standard are based 
> on Y.1731, 
> >>>>> so I use Y.1731 to present all of them.
> >>>>> Thank you!
> >>>>> 
> >>>>> Best regards,
> >>>>> 
> >>>>> Han Li
> >>>>> 
> >>>>> 
> ******************************************************************
> >>>>> *******
> >>>>> Han Li, Ph.D
> >>>>> China Mobile Research Institute
> >>>>> Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 
> 100053, China
> >>>>> Fax: +86 10 63601087
> >>>>> MOBILE: 13501093385
> >>>>> 
> ******************************************************************
> >>>>> *******
> >>>>> 
> >>>>> 
> >>>>> --- 10年11月11日,周四, Huub van Helvoort <hhelvoort@chello.nl 
> >>>>> <mailto:hhelvoort@chello.nl> <mailto:hhelvoort@chello.nl>> 写道:
> >>>>> 
> >>>>>> 发件人: Huub van Helvoort <hhelvoort@chello.nl 
> >>>>>> <mailto:hhelvoort@chello.nl> <mailto:hhelvoort@chello.nl>>
> >>>>>> 主题: Re: [mpls-tp] [mpls] MPLS WG slides from CMCC
> >>>>>> 收件人: mpls@ietf.org <mailto:mpls@ietf.org> 
> <mailto:mpls@ietf.org>
> >>>>>> 抄送: "'lihan'" <lihan@chinamobile.com 
> >>>>>> <mailto:lihan@chinamobile.com> 
> <mailto:lihan@chinamobile.com>>, "Ad hoc MPLS-TP"
> >>>>>> <ahmpls-tp@lists.itu.int <mailto:ahmpls-tp@lists.itu.int> 
> >>>>>> <mailto:ahmpls-tp@lists.itu.int>>,
> >>>>>> "mpls-tp@ietf.org <mailto:mpls-tp@ietf.org> 
> >>>>>> <mailto:mpls-tp@ietf.org>" <mpls-tp@ietf.org 
> >>>>>> <mailto:mpls-tp@ietf.org> <mailto:mpls-tp@ietf.org>>
> >>>>>> 日期: 2010年11月11日,周四,下午3:21
> >>>>>> Li Han, 你好!
> >>>>>> 
> >>>>>> Thank you very much for this informative information.
> >>>>>> 
> >>>>>>> 
> http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-
> >>>>>>> 
> notes/CMCC%20implementation%20and%20consideration%20for%20MPLS-T
> >>>>>>> P-01.pdf
> >>>>>>> 
> >>>>>>> There are links from the meetings materials page
> >>>>>>> (http://wiki.tools.ietf.org/misc/mpls-tp/wiki/meeting-notes)
> >>>>>> and from the wiki
> >>>>>>> home page (http://wiki.tools.ietf.org/misc/mpls-tp/)
> >>>>>> 
> >>>>>> I have a question about slide 3:
> >>>>>> the last bullet states: OAM: "based on Y.1731 and pre- 
> standard 
> >>>>>> G.8114"
> >>>>>> 
> >>>>>> By "based on Y.1731" do you refer to
> >>>>>> draft-bhh-mpls-tp-oam-y1731
> >>>>>> and the CCSA standard that will soon be published?
> >>>>>> 
> >>>>>> Thank you, Huub.
> > 
> > 
> > 
> > --
> > *****************************************************************
> >                         我爱外点一七三一
> > _______________________________________________
> > mpls-tp mailing list
> > mpls-tp@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>