Re: [Softwires] Unified proposal for stateless IPv4 Residual Deployments (4rd-U) - Contributors?

Ole Troan <otroan@employees.org> Tue, 29 November 2011 16:15 UTC

Return-Path: <ichiroumakino@gmail.com>
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 3097B21F8C31 for <softwires@ietfa.amsl.com>; Tue, 29 Nov 2011 08:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 O0IeiN5wOUBa for <softwires@ietfa.amsl.com>; Tue, 29 Nov 2011 08:15:05 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7075621F8B70 for <softwires@ietf.org>; Tue, 29 Nov 2011 08:15:05 -0800 (PST)
Received: by eabm6 with SMTP id m6so3748076eab.31 for <softwires@ietf.org>; Tue, 29 Nov 2011 08:15:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jWKBrPcTHEHrT61IgE1OxaJF4ns8YSU6EBt0SM8CBBk=; b=L79Z6lAHWnZdt2T0+vq/xWOWa58S87m18uymJBblxsPCCgLCiEb+zigjQDkid6iKcY WTNtQIGykXWoUWrskVRjvwL1rwAwP3Y4V7Lld5vb69lTtCRGO8WUtHy6P7gTAmaaU7Xj lsIAnfyYdLL4O2KAlNXhz0q2z2GSH69ymkxEU=
Received: by 10.14.9.155 with SMTP id 27mr412347eet.176.1322583304467; Tue, 29 Nov 2011 08:15:04 -0800 (PST)
Received: from [10.147.12.109] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z58sm106705440eea.3.2011.11.29.08.15.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 08:15:03 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <765C1C26-0224-474D-AE80-E15D93EB894B@laposte.net>
Date: Tue, 29 Nov 2011 17:15:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E13F9FB-D07A-4117-ABCC-3B12FC97BF87@employees.org>
References: <765C1C26-0224-474D-AE80-E15D93EB894B@laposte.net>
To: Rémi Després <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Unified proposal for stateless IPv4 Residual Deployments (4rd-U) - Contributors?
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: Tue, 29 Nov 2011 16:15:06 -0000

Remi,

> For those who attended the Softwire session in Taipei, please note that the serious objection against 4rd-U expressed by several participants during the meeting has been, soon after, acknowledged to be invalid (www.ietf.org/mail-archive/web/softwires/current/msg03281.html).
> Also, other (less important) objections have been answered in www.ietf.org/mail-archive/web/softwires/current/msg03284.html, without reaction so far. 

I do not think that's a fair representation.
the main objection to 4rd-u is that it is 'just another translation' solution. how many do we need? it doesn't appear to offer any benefits compared to the already specified solution. as it stands it will just result in 3 ways of doing the same thing, instead of 2.

the topic discussed in softwires, wasn't the main objection. as far as I can see, "checksum neutrality" does not offer any advantages over incrementally updating the L4 checksum. every node doing this will have to look into the L4 header anyway.

cheers,
Ole