Re: [Softwires] Path to move forward with 4rdŠ

Rémi Després <despres.remi@laposte.net> Sun, 25 March 2012 07:44 UTC

Return-Path: <despres.remi@laposte.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 D1EC921F8598 for <softwires@ietfa.amsl.com>; Sun, 25 Mar 2012 00:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 CNmzQA6gKTRr for <softwires@ietfa.amsl.com>; Sun, 25 Mar 2012 00:44:30 -0700 (PDT)
Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9968F21F8593 for <softwires@ietf.org>; Sun, 25 Mar 2012 00:44:29 -0700 (PDT)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id pjkR1i00737Y3f403jkReY; Sun, 25 Mar 2012 09:44:27 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <923D5842-2C9E-4CF6-86FC-5DB8773ADA53@employees.org>
Date: Sun, 25 Mar 2012 09:43:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E78D9C16-DB81-4F14-8094-BED8704BFBF2@laposte.net>
References: <CB917493.1E60B%yiu_lee@cable.comcast.com> <0861E4FC-926E-4651-8FD0-16368AB56C62@employees.org> <3F8D43A5-9D98-4BD3-9503-AF548D53403C@laposte.net> <923D5842-2C9E-4CF6-86FC-5DB8773ADA53@employees.org>
To: Ole Trøan <otroan@employees.org>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Path to move forward with 4rdŠ
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: Sun, 25 Mar 2012 07:44:30 -0000

Le 2012-03-25 à 07:31, Ole Trøan a écrit :

> Remi,
> 
>>> the authors did already do that. the dIVI and 4rd authors met 16th of November at the last IETF.
>>> we collectively went through the complete feature list. the result is what you find in the MAP document series.
>> 
>> This MAP meeting was immediately after the Taipei Softwire meeting. At this meeting, with an invalid technical argument, you had convinced most participants that -U couldn't work, so that a majority didn't believe the -U approach could be useful. 
> 
> that's not quite how I remember it. there were a number of issues discussed with 4rd-U.
> - destination spread, caused by Max PSID, CNP (I was wrong about CNP causing destination spread).
> - V-octet; implications
> - how -U achieves transparency by overloading information in the fragmentation header

No contradiction.
- Destination spread was claimed to be caused by CNP. 
- Max PSID was unanimously abandoned during you meeting.
- Your (invalid) objection to CNP was maintained, with no time to argue about it, so that you got a majority vote for not considering CNP anymore in the MAP team. 


>> During this MAP meeting, a majority consequently expressed no interest in considering further, for MAP, new features that were part of the -U proposal (Reversible header mapping; Checksum neutrality, AKA CNP; Distinguishable address format, AKA V octet).
> 
> the MAP effort has focused on the mandatory functionality and features only.
> 
> all the "features" between 4rd-U and MAP are interchangeable. in this instance I do believe "less is more" though.

> the distinguishing part of 4rd-U is that is uses a different form of translation than what MAP does.

Whatever you call it, its virtue is that:
- it never modifies payloads
- it completely restores IPv4 headers (except for IPv4 options, but these are not needed for IPv4 applications).
Double RFC6145 translation, as you brilliantly explained yourself in Beijing, sometimes breaks e2e transparency. 

Cheers,
RD
 
> 
> cheers,
> Ole
>