Re: [Softwires] Port mapping - Don't change it at the last minute !

Rémi Després <despres.remi@laposte.net> Thu, 03 November 2011 08:22 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 2AE5311E80A6 for <softwires@ietfa.amsl.com>; Thu, 3 Nov 2011 01:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 E6CezwHRY8OY for <softwires@ietfa.amsl.com>; Thu, 3 Nov 2011 01:22:26 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9F11E80A3 for <softwires@ietf.org>; Thu, 3 Nov 2011 01:22:24 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id F24E39402F1; Thu, 3 Nov 2011 09:22:16 +0100 (CET)
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: <4EB214D3.7050900@jacni.com>
Date: Thu, 03 Nov 2011 09:22:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <71723B71-64FD-4EE4-9E21-DE5D57E2FA60@laposte.net>
References: <7017F405-CBEC-4D7D-94ED-56FF2B774C0C@laposte.net> <37EE7524-2AF1-4286-A80D-004E7958C5A0@gmail.com> <FCFFF724-847B-45D3-B6A5-1F937356F6B6@laposte.net> <94C682931C08B048B7A8645303FDC9F35A37B98DA7@PUEXCB1B.nanterre.francetelecom.fr> <BA1F9EBE-CDFE-47DB-BE40-08033E62AF17@cisco.com> <94C682931C08B048B7A8645303FDC9F35A37B98E17@PUEXCB1B.nanterre.francetelecom.fr> <88E22674-98FF-4F21-ADA4-4F3E77A6401D@laposte.net> <94C682931C08B048B7A8645303FDC9F35A37B98E3B@PUEXCB1B.nanterre.francetelecom.fr> <E296AD82-0AC6-460E-AB95-6AC6B8127008@cisco.com> <5225339E-1B72-456D-A0E7-2C96F2051EA3@juniper.net> <4EB214D3.7050900@jacni.com>
To: Jacni Qin <jacni@jacni.com>
X-Mailer: Apple Mail (2.1084)
Cc: Ole Troan <ot@cisco.com>, Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] Port mapping - Don't change it at the last minute !
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: Thu, 03 Nov 2011 08:22:27 -0000

Hi Jacni,


Le 3 nov. 2011 à 05:13, Jacni Qin a écrit :
...
>> Saying if you are not happy with port sharing, we give you a full address is relatively straightforward and can be translated into marketing terms. Anything in between is more questionable. This is a question that should be taken back to the working group: how far do we want to go on that route.
> Indeed.

+1


> In addition,
> Although according to the current algorithm, both the "prefix" case and the "exclusive address" case can be inherently supported, I still think, at least to cover the prefix case is debatable, given the so called "residual deployment of IPv4", which is the context of the solution design.
> 
> Furthermore, there is already an approach adopted by the WG for public IPv4 address case,

> if the MAP just covers "shared address with one single sharing ratio for one domain",
> the design will be greatly simplified?

Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward.

Besides, I have serious doubts about "greatly simplified".
In my understanding, the recent unifying design of 4rd-U is, among per-customer-stateless v4/v6 solutions, one that permits a UNIQUE AND SIMPLE standard (possible direct CE-CE routes, transparency to v4 fragmentation, compatibility with v6 O&M-tools). 
All clarification questions are of course welcome. 

Cheers,
RD