Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <1E13F9FB-D07A-4117-ABCC-3B12FC97BF87@employees.org>
Date: Tue, 29 Nov 2011 19:11:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5B5A825-B122-4457-AD48-5C66C9A7A390@laposte.net>
References: <765C1C26-0224-474D-AE80-E15D93EB894B@laposte.net>
 <1E13F9FB-D07A-4117-ABCC-3B12FC97BF87@employees.org>
To: Ole Troan <otroan@employees.org>
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Unified proposal for stateless IPv4 Residual
 Deployments (4rd-U) - Contributors?
Precedence: list

Le 29 nov. 2011 =E0 17:15, Ole Troan a =E9crit :

> Remi,
>=20
>> 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.=20
>=20
> 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.=20
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.=20
Encapsulation and reversible header mapping don't care about this, which =
is one of their virtues.

Cheers,
RD