[Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U
Alain Durand <adurand@juniper.net> Wed, 01 February 2012 16:32 UTC
Return-Path: <adurand@juniper.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AA921F8C5D for <softwires@ietfa.amsl.com>; Wed, 1 Feb 2012 08:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.979
X-Spam-Level:
X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTLJKfhQBHzu for <softwires@ietfa.amsl.com>; Wed, 1 Feb 2012 08:32:53 -0800 (PST)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 57B4121F8A9C for <softwires@ietf.org>; Wed, 1 Feb 2012 08:32:48 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTylpL+2PAqh+ki4UDk/3+HgM/vmAehgm@postini.com; Wed, 01 Feb 2012 08:32:53 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 1 Feb 2012 08:28:43 -0800
From: Alain Durand <adurand@juniper.net>
To: Softwires WG <softwires@ietf.org>
Date: Wed, 01 Feb 2012 08:28:40 -0800
Thread-Topic: Moving forward with 4rd-T, 4rd-E & 4rd-U
Thread-Index: Aczg/o/r7v3+nerQQUWkiU5+ojD5Aw==
Message-ID: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subject: [Softwires] Moving forward with 4rd-T, 4rd-E & 4rd-U
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2012 16:32:54 -0000
Dear wg, We now have a number of documents and solutions on the table in the 4rd category: all the MAP effort, including 4rd-T & 4rd-E, and, somehow separately, the 4rd-U effort. I will claim that there is a very large overlap between all those solution and somehow small differences. For the sake of this discussion, I'll say the overlap is about 90%, the exact number is irrelevant, what matters is that this number is much more than 50% I have expressed many times that, in my view, the main role of a standard process is to pick one solution when multiple are available. Not that the others are bad, but that the fact of not choosing and pushing through the process a number of solutions that are 90% or more identical is not doing the community any good. Back at Beijin interim meeting, we agreed on 'publishing' a number of documents, but did not agree on status and/or recommendation attached to 4rd-E and 4rd-T. later, 4rd-U came as an attempt at unifying then. At stake here is not so much the organization of the document set, nor which document(s) are accepted as wg item(s) right now on the basis that they are somehow technologically 'ready'. At stake now is how many solutions that are 90% overlapping we are going to send to the IESG. In other words, at stake is the capability of this wg to make clear recommendations as to what to implement and what to deploy. At this point in time, I think the wg as the choice between a number of paths forward: 1) Declare failure to reach consensus and stop working on this 4rd space. 2) Declare a Pyrrhic(*) victory, publish everything on the standard track without any recommendation as to which one to use 3) Declare partial victory, publish everything as Experimental, let the market decide and come back in two years to put the winner on the standard track. 4) Converge to a consensus toward one 'recommended' solution, publish that one as Standard track and publish the other ones as experimental/informational, THEN declare victory. Note that using standard track vs experimental is just one way to make recommendations on status, there are others, such as publishing a recommendation document or adding recommendation text in a boiler plate inside each document. I'd think that we would all agree that 1) is the least preferred option. 2) might be appealing as a short term solution to (not solve) the recommendation problem we are faced with, but if we do that, I would claim that the wg would have not done its job and would have simply added to the confusion around which transition mechanism to choose. Hence my qualification of this solution as 'Pyrrhic' victory. As wg co-chair, my perspective is that we should do either 3) or 4) I would like to encourage the wg to start a discussion toward 4) on the mailing list so that we could have a productive conversation in Paris, where I intend to ask for wg feedback on this question. More over, 4rd-U claims to solves a number of issues that the MAP suite of documents does not address. It would be beneficial to have a discussion on the mailing list to see if a) those issues are important or not and b), if they are, are they properties of 4rd-U or could they be solved as well in MAP, they just have not been addressed there yet. In the mean time, I believe we should hold off accepting any document as wg item. I'd like to use the upcoming Paris meeting next month as a forcing function to make progress and I encourage discussion on the mailing list on thee above topics until then. Alain, Softwire wg co-chair. (*)See http:// en.wikipedia.org/wiki/Pyrrhic_victory
- [Softwires] Moving forward with 4rd-T, 4rd-E & 4r… Alain Durand
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Mouli Chandramouli (moulchan)
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Ole Trøan
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Rémi Després
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Alain Durand
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Ole Trøan
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Rémi Després
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Ole Trøan
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Ole Trøan
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Rémi Després
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Rémi Després
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Tina TSOU
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Rémi Després
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Ole Trøan
- Re: [Softwires] Moving forward with 4rd-T, 4rd-E … Ole Trøan
- [Softwires] MAP & 4rd-U - Preserving freedom of s… Rémi Després
- Re: [Softwires] MAP & 4rd-U - Preserving freedom … Ole Trøan
- [Softwires] Checksum neutrality and L4-protocol i… Rémi Després
- [Softwires] MAP & 4rd-U - Robust Renumbering avoi… Rémi Després
- Re: [Softwires] MAP & 4rd-U - Robust Renumbering … Ole Trøan
- [Softwires] MAP and 4rd-U - how to try to converge Rémi Després
- [Softwires] MAP and 4rd-U Alain Durand
- Re: [Softwires] MAP and 4rd-U Ralph Droms
- Re: [Softwires] MAP and 4rd-U Ole Trøan
- Re: [Softwires] MAP and 4rd-U Reinaldo Penno
- Re: [Softwires] MAP and 4rd-U Jacni Qin
- [Softwires] MAP and 4rd - Feature comparison table Rémi Després
- Re: [Softwires] MAP and 4rd - Feature comparison … Rémi Després
- Re: [Softwires] MAP and 4rd - Feature comparison … Ole Trøan
- Re: [Softwires] MAP and 4rd - Feature comparison … Xing Li
- Re: [Softwires] MAP and 4rd - Feature comparison … Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Feature comparison … Ole Trøan
- Re: [Softwires] MAP and 4rd - Feature comparison … Rémi Després
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- Re: [Softwires] Checksum neutrality and L4-protoc… Rémi Després
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- Re: [Softwires] Checksum neutrality and L4-protoc… Rémi Després
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- Re: [Softwires] Checksum neutrality and L4-protoc… Washam Fan
- Re: [Softwires] Checksum neutrality and L4-protoc… Rémi Després
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- Re: [Softwires] Checksum neutrality and L4-protoc… Rémi Després
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- Re: [Softwires] Checksum neutrality and L4-protoc… Rémi Després
- Re: [Softwires] Checksum neutrality and L4-protoc… Maoke
- [Softwires] 答复: MAP and 4rd-U Huangjing
- Re: [Softwires] MAP and 4rd - Relationship with S… Xing Li
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Xing Li
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Rajiv Asati (rajiva)
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Xing Li
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Wojciech Dec
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Wojciech Dec
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després
- Re: [Softwires] MAP and 4rd - Relationship with S… Wojciech Dec
- Re: [Softwires] MAP and 4rd - Relationship with S… Rémi Després