Re: [Softwires] Objection to 4rd-U made in Softwire meeting understood to be invalid

Ole Troan <ot@cisco.com> Wed, 16 November 2011 02:43 UTC

Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <ot@cisco.com>
In-Reply-To: <4C7C4080-E3B9-4855-BA0E-3E74495D9AEE@laposte.net>
Date: Wed, 16 Nov 2011 10:26:19 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDB93107-C7A9-4FF6-87BB-1E3FB64BD532@cisco.com>
References: <4C7C4080-E3B9-4855-BA0E-3E74495D9AEE@laposte.net>
To: Rémi Després <despres.remi@laposte.net>
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Objection to 4rd-U made in Softwire meeting understood to be invalid
Precedence: list

Remi, et al,

> In the Softwire meeting of Monday, the key argument against the 4rd unified approach (4rd-U) was that *Because checksum neutrality of addresses is part of 4rd-U, it would allegedly cause "address spreading" (addresses used between a pair of hosts would vary)*. 
> You had a slide asserting it, and the argument was taken as granted, and important, in verbal comments from Mark Townsley and Dave Thaler.
> I forcefully declared that this was technically false.
> Since no time has been granted to explain, I invited anyone in doubt to contact me for explanations. 
> Thanks for having taken the time to do it.
> 
> Following our discussion of yesterday, I think you now understand that, as I said:
> - *TCP/UDP checksum neutrality of addresses DOES NOT interfere in any way with stability of addresses between host pairs*.

acknowledged. as far as I can understand the checksum neutrality proposal will work, and it will result in stable addresses.
two flows between two hosts will have the same addresses. and there is no "destination spread" with this mechanism.

apologies for the uncertainty and confusion created by questioning this.

> - Consequently, the key argument of the meeting against 4rd-U is invalid.

that I disagree with. there were multiple arguments. let me try to summarize.

- if 4rd-U resulted in one specification as opposed to two then 4rd-U is a good thing.
  if 4rd-U results in three specifications as opposed to two, then that is a bad thing.
  I have discussed this with the authors of the other two proposals, and they don't appear to withdraw their proposals
  in favour of this one.
- 4rd-U has destination spread as written with the Max PSID has destination spread. this can obviously be fixed.
- 4rd-U has the V octet, which impacts native IPv6 forwarding, and I think in general is problematic
- 4rd-U is 'just' another translation proposal; it might provide a 'better' translation than what has been done so far
  in behave, but that doesn't alleviate the arguments made for encapsulation
- 4rd-U has checksum neutrality, there is already a solution for the checksum. that is widely implemented, why
  bring in another way of doing it, creating two specifications for the same problem instead of using an existing one?

cheers,
Ole

[Softwires] Objection to 4rd-U made in Softwire m… Rémi Després
Re: [Softwires] Objection to 4rd-U made in Softwi… Ole Troan
Re: [Softwires] Objection to 4rd-U made in Softwi… Rémi Després
[Softwires] Responses to Ole's listed objections … Rémi Després