[Softwires] MAP and 4rd-U - how to try to converge

Rémi Després <despres.remi@laposte.net> Mon, 06 February 2012 17:17 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8880321F8483 for <softwires@ietfa.amsl.com>; Mon, 6 Feb 2012 09:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6NCOdlgqy4H8 for <softwires@ietfa.amsl.com>; Mon, 6 Feb 2012 09:17:33 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD3021F8484 for <softwires@ietf.org>; Mon, 6 Feb 2012 09:17:30 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id DDCB59404E4; Mon, 6 Feb 2012 18:16:56 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org>
Date: Mon, 6 Feb 2012 18:16:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F901DB4-3356-42BA-B3C9-E958FC8C8B67@laposte.net>
References: <B140D6B2-1B19-43D7-9B63-6BEA83CEB164@juniper.net> <3AAD65F3-5169-49B7-9698-E820EF419B35@employees.org> <53ACB4FC-988F-443C-A936-1CA5B13180EB@free.fr> <C694D7DC-2F98-434F-8123-751E2C1A98D0@employees.org> <081C7074-F5E2-46B7-B2C8-E033F3E5BC15@laposte.net> <B94D39A0-CA66-4AE6-BDC5-E4DFA2D47BEC@employees.org> <A8A6FDA2-0FFC-44D2-BEDF-29FB012D3113@laposte.net> <4749FAFA-A522-4795-9B8A-9AA4B030E075@employees.org> <72CC172E-5018-4EB3-ABB0-8591AB0CE3A0@laposte.net> <4E35B2EA-8347-4FA5-9EBC-B0E2A05C2A4A@employees.org> <F4A250AB-99E5-4F78-BE49-D93475687FE8@laposte.net> <99E6AED6-EC3F-43B5-B22D-901085A4B264@employees.org>
To: Alain Durand <adurand@juniper.net>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: [Softwires] MAP and 4rd-U - how to try to converge
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: Mon, 06 Feb 2012 17:17:33 -0000

Alain, Yong, Ralph,

 First, a little bit of history is IMHO useful to understand where we are:
 1.  At the Beijing meeting, end of September, I started, with Professor Xing Li, Wojciech Dec, and Congxiao Bao, a convergence effort based on requirements expressed by double-translation and encapsulation proponents respectively (ref www.ietf.org/mail-archive/web/softwires/current/msg02994). 
 2. In early October, Alain then entrusted Ole with the task to lead a team  having "to formulate a unified format to be used either in an encapsulation or double translation mode, for both hub & spokes and mesh models" (www.ietf.org/mail-archive/web/softwires/current/msg03024)
 3. Working on my own, looking for a stateless solution that would be more completely unified than just the address mapping, I found an approach for that, called 4rd-U. (Its reversible "header mapping" uses systematic IPv6 fragment headers, and TCP-checksum neutrality of mapped addresses. Ref draft-despres-softwire-4rd-u-00)
 4. During the Softwire meeting in Taipei, in his report as MAP-team leader, Ole had a slide stating that checksum neutrality would result into "destination spray" (i.e. would break TCP!). Time lacking for a technical challenge of such a claim, this prevented the WG from finding interest in pursuing the 4rd-U approach.  
 5. In the MAP-team meeting that immediately followed that of the WG, Ole obtained a rough consensus that features of the 4rd-U proposal (checksum neutrality and the V octet) would no longer be considered by the MAP team. 
 6. After that, Ole and I having discussed privately, Ole acknowledged on the WG list that his statement against checksum neutrality was technically invalid. 
 7. Some interest for looking more at the 4rd-U solution was then reported to the chairs, and Alain encouraged me to work on a revised 4rd-U draft for the next meeting (ref www.ietf.org/mail-archive/web/softwires/current/msg03296).
 8. On December 29, I then posted tools.ietf.org/html/draft-despres-softwire-4rd-u-02. Following comments I had received, and accepting that some needs weren't satisfied in draft-02, I posted on January 28 draft-03 which has two tunnel variants close to one another (4rd-E for encapsulation, 4rd-H for header mapping).
 9. On January 30, Ole announced to the WG that the 4 related MAP documents were available (ref www.ietf.org/mail-archive/web/softwires/current/msg03328).

 Thus, people involved in the two approaches have clearly done what they were asked to.

 Trying to converge between the two approaches is worth attempting because, as Ole recently wrote: "let us make it clear that these two solutions are solving exactly the same problem, and they solve it in the same fundamental way (A+P). the differences we're talking about here are what whistles, bells (and dongs) we want to add on to the base specification. consider it a buffet, any feature from one of them can be applied to the other."
 Now, the 4rd-U draft is IMHO the best starting point for a specification that suits implementors that didn't participate in the work, because it is self-consistent and avoids redundancy. It is also AFAIK much clearer than the current set of posted MAP document.

 An example of already achieved convergence is a proposal made by Ole.
 (It concerns the "BR rewrite fragmentation" item of his table of www.ietf.org/mail-archive/web/softwires/current/msg03364, i.e. disambiguation of datagram identifications in packets that go from shared-address CEs to the Internet.)   
 - The need to do something has been identified for the first time in the 4rd-U-03 draft.
 - Ole's proposed solution is simpler than that of the draft. (The need is satisfied directly in CEs, rather than left for BRs to satisfy it.)
 Unless a problem would be identified in the mean time, I will adopt Ole's solution in the next 4rd-U version. 

 Naturally, if Ole would agree to it, he would be most welcome as co-author of the upgraded unified specification. 

Best regards,