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

Ole Troan <otroan@employees.org> Tue, 29 November 2011 18:47 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 9E27211E8102 for <softwires@ietfa.amsl.com>; Tue, 29 Nov 2011 10:47:43 -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 wehwo1gqXT3i for <softwires@ietfa.amsl.com>; Tue, 29 Nov 2011 10:47:41 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA211E810C for <softwires@ietf.org>; Tue, 29 Nov 2011 10:47:38 -0800 (PST)
Received: by eear51 with SMTP id r51so1421353eea.31 for <softwires@ietf.org>; Tue, 29 Nov 2011 10:47:37 -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=uNVCq2edqqaC15I5HZV47/WmNU8Vbr9j+e9soOBtsAc=; b=HjCq+UdOZVVM2HlQKrfUVfKwEeXpDSkE+0NFaRaaKAkdFY0NHYg9xU9adS+VKJQf8R LYsA7knXnS/2dhncTL/KFQdzPl9IE49Y7vd0acRkpzrszbWomR40ktcBEzjhUpnsUF72 ICn6kK7NlIU3EFNXkRSsDCBeSC1eb9gsk/YBI=
Received: by 10.14.2.11 with SMTP id 11mr3150890eee.124.1322592457352; Tue, 29 Nov 2011 10:47:37 -0800 (PST)
Received: from gomlefisk.lan (141.84-48-218.nextgentel.com. [84.48.218.141]) by mx.google.com with ESMTPS id o4sm108059574eeb.0.2011.11.29.10.47.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 10:47:36 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <C5B5A825-B122-4457-AD48-5C66C9A7A390@laposte.net>
Date: Tue, 29 Nov 2011 19:47:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <DAA7FDF9-ED2B-48D8-B58B-C167CFE987AB@employees.org>
References: <765C1C26-0224-474D-AE80-E15D93EB894B@laposte.net> <1E13F9FB-D07A-4117-ABCC-3B12FC97BF87@employees.org> <C5B5A825-B122-4457-AD48-5C66C9A7A390@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 18:47:43 -0000

Remi,

to summarize my view:
 - the 4rd-u proposal (including the changes you plan) are well understood
 - the main ideas from 4rd-* are already incorporated into MAP
 - 4rd-u is a slightly different way of doing translation (calling mapping doesn't change that fact)
   go to behave to argue if yours is better than what was specified there.
 - I think it is the wrong thing for this working group to encourage development of yet another solution, when we already
   have many.
 - I would also like to see one solution, my choice is encapsulation. given that all the building blocks already exist, I
   would expect we'll see translation in the wild too, whatever we choose to do in the IETF. ref: NAT464.

I really hope this is the last I'll ever write on this topic.

cheers,
Ole

 
On Nov 29, 2011, at 19:11 , Rémi Després wrote:

> Le 29 nov. 2011 à 17:15, Ole Troan a écrit :
> 
>> 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.
> 
> It was intended to be one, and is still believed to be so (see below)
> 
>> the main objection to 4rd-u is that it is 'just another translation' solution.
> 
> a)
> That's not what I heard during the meeting.
> Both Mark Townsley and Dave Thaler, taking for granted your statement that checksum-neutral addresses of 4rd-U would cause "address spray", said firmly that 4rd-U should be rejected because it wouldn't work.
> 
> In my understanding, not working is a show stopper, which I call a "main objection".
> 
> b) If your main objection is that 4rd-U would be 'just another translation', it is ALSO invalid. 
> If you have read my answer to your list of objections, you should know that 4rd-U is a reversible-header-mapping solution, and as such is based on neither translation nor encapsulation. (actually a tunnel closer to encapsulation in my understanding).
> 
> 
>> how many do we need?
> 
> Many consider that, if there is the choice, ONE standard is better than several.
> 
> The point is that 4rd-U combines advantages of double translation and encapsulation with only a slightly different tradeoff between optimizations of header-length and processing time.
> 
> Doubts are legitimate as long as the specification is incomplete, but that's why more work is needed.
> 
> 
>> it doesn't appear to offer any benefits compared to the already specified solution.
> 
> Which solution? (So far, there are two in the pipe - translation and encapsulation.)
> Meeting requirements of both solutions is AFAIK a benefit.
> 
> 
>> as it stands it will just result in 3 ways of doing the same thing, instead of 2.
> 
> Different view on this.
> Three standards would make no sense.
> 
> 
>> 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.
> 
> Again, commenting my previous answer to your list of objections would be be more constructive than repeating that 4rd-U doesn't do anything without arguing on substance.
> 
> Since there is no obligation to comment, please refrain from criticizing a solution without commenting previous answers made for you.
> 
> 
>> every node doing this will have to look into the L4 header anyway.
> 
> Sure. IPv4 address sharing implies _looking_ at port fields (true also for encapsulation).
> 
> But this doesn't imply that L4 data need to be  modified, especially if these modifications need to depend on whether the protocol is TCP UDP, DCCP, etc. 
> Encapsulation and reversible header mapping don't care about this, which is one of their virtues.
> 
> Cheers,
> RD
>