Re: [Softwires] dual-stack-lite-06 - Too biased against static port sharing

Rémi Després <remi.despres@free.fr> Thu, 12 August 2010 12:12 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45783A6A0D for <softwires@core3.amsl.com>; Thu, 12 Aug 2010 05:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.736
X-Spam-Level:
X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqBGWir3GsBO for <softwires@core3.amsl.com>; Thu, 12 Aug 2010 05:12:34 -0700 (PDT)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id 4F6873A6403 for <softwires@ietf.org>; Thu, 12 Aug 2010 05:12:34 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 835FD700008E; Thu, 12 Aug 2010 14:13:10 +0200 (CEST)
Received: from [192.168.1.29] (unknown [89.170.204.214]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 04770700008F; Thu, 12 Aug 2010 14:13:09 +0200 (CEST)
X-SFR-UUID: 20100812121310183.04770700008F@msfrf2207.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <BA887853-17B9-4FD9-B6BC-08E0E0CAA40D@juniper.net>
Date: Thu, 12 Aug 2010 14:13:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABFC9622-4EE2-4F45-B58D-200D25A7148F@free.fr>
References: <20100810223005.AA3E73A6AE3@core3.amsl.com> <F6FAFA3B-EFE3-4108-90B7-370A872CD5C7@free.fr> <6D86FFCC-62BB-4658-B0E0-E7CB63269530@cisco.com> <BA887853-17B9-4FD9-B6BC-08E0E0CAA40D@juniper.net>
To: Alain Durand <adurand@juniper.net>
X-Mailer: Apple Mail (2.1081)
Cc: Softwires <softwires@ietf.org>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Softwires] dual-stack-lite-06 - Too biased against static port sharing
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 12 Aug 2010 12:12:37 -0000

Le 12 août 2010 à 03:50, Alain Durand a écrit :

> 
> On Aug 11, 2010, at 6:00 PM, Ralph Droms wrote:
> 
>> 
>>> 2. If the number of assignable IPv4 addresses is for a start multiplied by 10, by statically sharing ports of each address among 10 customers, this still leaves several thousands of IPv4 ports per customer. (Exactly 6144 ports per customer if, as appropriate, the first 4K ports, that include well-known ports and have special value are excluded). 
>> 
>> Agreed; one could argue that even sharing an IPv4 address among 5 customers allows 5x as many customers in the existing IPv4 address assignment, which should be more than enough to bridge the gap until IPv6 is available.
> 
> The later part of this comment is IMHO a matter of opinion... It is very hard to know for sure how much IPv4 translation will be needed in the feature.
> The major issue with any scheme that allocates a fixed number of ports is what do you do when that number is exhausted?
> How do you even know this is happening? This may or may bot be an issue if we are talking about 10k ports per customers,
> but as pressure mounts on the IPv4 space and the address compression ratio need to be increased, you soon end-up with much less ports per customers. And then what?
> 
> 
>>> 3. Where applicable static sharing is much simpler to operate.
>> 
>> Agreed.
> 
> Logs can indeed be simpler to manage, sure. But this is a trade-off. Other parts of the systems are more complex, see above.
> 
> All this being said, the discussion of the advantages or inconvenients of A+B belong  to the A+P mailing list.


> 
>    - Alain.