Re: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02]

"Luyuan Fang (lufang)" <lufang@cisco.com> Thu, 13 January 2011 14:59 UTC

Return-Path: <lufang@cisco.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 0B61A28C0DB; Thu, 13 Jan 2011 06:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_HI=-8]
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 hfqKKYZgJdhD; Thu, 13 Jan 2011 06:59:19 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CDF803A6B9A; Thu, 13 Jan 2011 06:59:18 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPSiLk2tJXHB/2dsb2JhbACECKA/c6QuilABjhGBHoM3dwSEaIlQ
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2011 15:01:40 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p0DF1eG9001736; Thu, 13 Jan 2011 15:01:40 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Jan 2011 09:01:40 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Date: Thu, 13 Jan 2011 09:01:38 -0600
Message-ID: <238542D917511A45B6B8AA806E875E25041C4A04@XMB-RCD-201.cisco.com>
In-Reply-To: <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02]
Thread-Index: AcuzKTZq2jnBERhwR6aVB5jHpXiUDgAAP+ng
References: <4D2AE5E0.90703@cisco.com><077E41CFFD002C4CAB7DFA4386A53264033050A2@DEMUEXC014.nsn-intra.net><FF8F3C1FD6EDF74CB6DD38B90FDEBADB072B9AB3@CNSHGSMBS01.ad4.ad.alcatel.com><077E41CFFD002C4CAB7DFA4386A53264033051E3@DEMUEXC014.nsn-intra.net><FF8F3C1FD6EDF74CB6DD38B90FDEBADB072B9AF8@CNSHGSMBS01.ad4.ad.alcatel.com> <2FECBFEC-25A5-4EAC-974F-9FD432D1068B@niven-jenkins.co.uk>
From: "Luyuan Fang (lufang)" <lufang@cisco.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, HUANG Feng F <Feng.f.Huang@alcatel-sbell.com.cn>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>, "Stewart Bryant (stbryant)" <stbryant@cisco.com>
X-OriginalArrivalTime: 13 Jan 2011 15:01:40.0334 (UTC) FILETIME=[C87998E0:01CBB332]
Cc: mpls@ietf.org, mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02]
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, 13 Jan 2011 14:59:21 -0000

Well said, Ben and Nurit.

I support the proposal Stewart sent.

Let's reiterate the IETF process here.

IETF has published a number of RFCs that specify the procedures for external bodies to request the modification of IETF protocols.

[RFC 4775] “Procedures for Protocol Extensions and Variations” lays down the guideline and procedures for protocols extensions. It recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with IETF. This document is directed principally at other SDOs and vendors considering extensions to IETF protocols.

[RFC 4929] specifies the change process for MPLS, GMPLS protocols and procedures. It indicates the definition and publishing of non-standard extension by other fora without IETF review, and outside of IETF publication process, regardless if rationalized as limited to use among fora vendors, or limited to a particular application, or rationalized as allowing timely demos, has the unfortunate potential to hinder interoperability and increase complexity, sows confusion in the industry, and circumvents the Internet standards process that exists to ensure protocol implementability.

As described in [RFC4775] and [RFC 4929], any non-standard extensions to IETF protocols, including experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards body. Standard extensions to IETF protocols must be reviewed and published by IETF. Extensions to MPLS(-TP) protocols made outside of IETF creates a great risk of interoperability.

How could any other SDOs standardize something that extend IETF MPLS protocols without IETF's agreement, nor IANA issued code point?

The process issue was the reason for IETF/ITU-T agreements for joint development for MPLS-TP two years ago. 

In Beijing IETF 79, November 2011, IETF Chair Russ Housley said clearly in the MPLS WG meeting that IETF decided to support one MPLS-TP OAM solution only. 

We all heard that, let's move on.

You can do things elsewhere if not extending/modifying IETF protocols.

Luyuan
 

-----Original Message-----
From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: 13 January 2011 08:53
To: HUANG Feng F
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] [mpls] Draft: Response to Updated draftRecommendation G.tpoam[Ref043.02]

Feng, colleagues,

On 13 Jan 2011, at 10:31, HUANG Feng F wrote:
> -----Original Message-----
> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
> [mailto:nurit.sprecher@nsn.com]
> Sent: 2011年1月13日 17:45
> To: HUANG Feng F; stbryant@cisco.com; mpls@ietf.org
> Cc: mpls-tp@ietf.org
> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation 
> G.tpoam[Ref043.02]
> 
> Hi Feng,
> I did not refer to specific solution, validity and acceptance of a solution, so I cannot see to what you disagree and how your response fit to mine. 
> If you think that you have a good solution which is proven and supported please discuss it in the IETF and try to get support for it! 
> 
> HF> The solution has been submitted to ietf for 2 year!
> 

We seem to be going round the same loop we've being going round for a while.

An OAM solution (draft-bhh) was submitted for consideration and the MPLS WG decided to select a different proposal for MPLS-TP OAM. That's life, that's how standards development works because standards development is "design by committee" and that means that the decisions of the "committee" are unlikely to please everyone all of the time.

> I would like the ITU-T to continue with its collaborative agreement with the IETF and ensure that the development of the protocol is done as agreed and supported by SG15 using the IETF processes.
> 
> HF> I can't image the meaning of cooperation is that ITU-T do nothing and just obey IETF's process!
> 

It isn't, but that collaborative agreement recognised IETF as being the protocol design authority for MPLS & MPLS-TP, which means IETF have the final decision on what the MPLS-TP protocols are and how they work.

What you seem to be arguing for is that IETF just obey the demands of other organisations, i.e. to paraphrase your argument: "CCSA have used draft-bhh in one of their standards so IETF must rubber stamp it as being part of MPLS-TP".

It was similar behaviour (ITU-T defining MPLS extensions without consultation with IETF) that causes the original bun fight that lead to the JWT etc being formed and much time being expended on politics rather than technical work to get us to where we are.

I suggest we stop trying to re-ignite a debate as to whether the MPLS-TP OAM solution should include draft-bhh or not as the decision has been made. Let's accept that decision.

In future if another standards body wants to use an Internet-Draft as the basis for one of their standards they would be well advised to enquire of the IETF as to the status and likely future of the Internet-Draft before making any decisions and we could avoid these sorts of situations occurring in the first place.

Ben

P.S. I think the original liaison text is fine as-is.


> I will support a single global solution interoperable solution (whatever the solution is). 
> Best regards,
> Nurit
> 
> -----Original Message-----
> From: ext HUANG Feng F [mailto:Feng.f.Huang@alcatel-sbell.com.cn]
> Sent: Thursday, January 13, 2011 11:35 AM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbryant@cisco.com; 
> mpls@ietf.org
> Cc: mpls-tp@ietf.org
> Subject: RE: [mpls] Draft: Response to Updated draft Recommendation 
> G.tpoam[Ref043.02]
> 
> Hi,Nurit,
>   I can't agree with you.
>   Solution of GACH+Y.1731 in G.tpoam is proven work well in Packet Transport Network by many applications and public demo and it has many supporters. I am wondering why  this solutions is not  standardized in ietf? 
>    Further more,  I really don't agree with your last sentence, this solution is asked by customers in Industry, you can see at least 7 providers in global support this solution.
> 
> B.R.
> Feng
> 
> 
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf 
> Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: 2011年1月13日 16:18
> To: stbryant@cisco.com; mpls@ietf.org
> Subject: Re: [mpls] Draft: Response to Updated draft Recommendation 
> G.tpoam[Ref043.02]
> 
> Hi,
> I support the proposal.
> We have a cooperative agreement with the ITU-T concerning the work on MPLS-TP. 
> The agreement recognizes the design authority of the IETF for MPLS and it is agreed that the development of the protocol should be done in the IETF using the IETF processes. The ITU-T should not take any uncoordinated action in the development of the MPLS_TP protocol. 
> We would appreciate if the ITU-T continues (as it committed to) with the collaborative work with the IETF on MPLS_TP and contributes from its expertise to the development of the protocol using the IETF processes. 
> We would also not like to see two competing solutions which may confuse the Industry, bloat operational and capital expenses and badly affect the end customer. 
> Best regards,
> Nurit
> 
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf 
> Of ext Stewart Bryant
> Sent: Monday, January 10, 2011 12:57 PM
> To: mpls@ietf.org
> Subject: [mpls] Draft: Response to Updated draft Recommendation 
> G.tpoam [Ref043.02]
> 
> I propose to send the following Liaison Response to the ITU-T on Friday 14th January and am posting it to the MPLS WG list for review.
> 
> =======
> 
> Response to Updated draft Recommendation G.tpoam [Ref 043.02]
> 
> From: IETF Liaison to ITU-T on MPLS stbryant@cisco.com
> To: tsbsg15@itu.int, greg.jones@itu.int, hiroshi.ota@itu.int, 
> IAB@ietf.org
> CC: Greg Jones, swallow@cisco.com, loa@pi.nu, paf@cisco.com 
> stbryant@cisco.com, adrian.farrel@huawei.com, mpls@ietf.org 
> yoichi.maeda@ttc.or.jp, steve.trowbridge@alcatel-lucent.com
> ghani.abbas@ericsson.com, hhelvoort@huawei.com 
> malcolm.betts@zte.com.cn, kam.lam@alcatel-lucent.com
> 
> For Action
> 
> The MPLS Working Group notes that this document contains text 
> describing
> 
> MPLS-TP OAM protocols not designed and standardized using the IETF Standards process. Specifically it uses material from draft-bhh-mpls-tp-oam-y1731-06.
> 
> We wish to draw your attention to the status section of
> draft-bhh-mpls-tp-oam-y1731-06 which 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".
> 
> Please also note that since the draft filename starts with the prefix 
> string "draft-bhh" this clearly identifies it to the reader as a 
> document expressing the personal technical views of the authors and 
> hence hence as a document that that does not have any acknowledged 
> level
> 
> of IETF consensus.
> 
> Since the text of draft Recommendation for G.tpoam is based on an 
> MPLS-TP OAM protocol not designed within the IETF Standards Process 
> this
> 
> is a breach of the SG15 agreement with the IETF as published in Report 
> of the first meeting of Working Party 3/15 Transport network 
> structures
> (2009-2012) (Geneva, 1 - 12 December 2008) which can be found at 
> http://www.itu.int/md/T09-SG15-R-0004/en
> 
> Please confirm that the ITU-T intends to continue with the joint work 
> on
> 
> MPLS-TP and that the ITU-T will align this recommendation with the IETF MPLS-TP OAM design before advancing this document through the ITU-T publication process.
> 
> The MPLS Working Group would also like to draw the attention of ITU-T
> SG15 to the IETF copyright rules. Please see
> http://trustee.ietf.org/license-info/archive/IETF-Trust-License-Policy
> -2
> 0091228.htm
> for further details.
> 
> Since this draft Recommendation contains text in which the ITU-T SG15 has proposed making changes to IETF protocols without the approval of the IETF, the MPLS Working Group have referred this liaison to the IAB for their consideration.
> 
> 
> =========
> _______________________________________________
> 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

_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp