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

<mohamed.boucadair@orange-ftgroup.com> Thu, 12 August 2010 08:21 UTC

Return-Path: <mohamed.boucadair@orange-ftgroup.com>
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 F0B6828C10D for <softwires@core3.amsl.com>; Thu, 12 Aug 2010 01:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001]
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 PZYLc3GOKwcs for <softwires@core3.amsl.com>; Thu, 12 Aug 2010 01:21:55 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id 95C313A69C3 for <softwires@ietf.org>; Thu, 12 Aug 2010 01:21:55 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 399522AC92F; Thu, 12 Aug 2010 10:22:31 +0200 (CEST)
Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 20EBA384069; Thu, 12 Aug 2010 10:22:31 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 12 Aug 2010 10:22:31 +0200
From: mohamed.boucadair@orange-ftgroup.com
To: Rémi Després <remi.despres@free.fr>, Softwires <softwires@ietf.org>
Date: Thu, 12 Aug 2010 10:22:30 +0200
Thread-Topic: [Softwires] dual-stack-lite-06 - Too biased against static port sharing
Thread-Index: Acs5azpJb+NZLvM1QAOb2i2hF2eZ1gAgA07g
Message-ID: <24280_1281601351_4C63AF47_24280_1087_1_94C682931C08B048B7A8645303FDC9F312F6F9EB2D@PUEXCB1B.nanterre.francetelecom.fr>
References: <20100810223005.AA3E73A6AE3@core3.amsl.com> <F6FAFA3B-EFE3-4108-90B7-370A872CD5C7@free.fr>
In-Reply-To: <F6FAFA3B-EFE3-4108-90B7-370A872CD5C7@free.fr>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.6.28.85115
Cc: 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 08:21:57 -0000

Dear all,

We have raised this point during the last call which has been issued on version 03 of the draft and suggested to remove this section from the draft since it is not normative and also because this depends on the taste of each SP and their deployment context. A reference to http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01#page-22 would be sufficient IMHO. "Dynamic vs. Static" and "Port set vs. Individual ports" discussion can be elaborated further in draft-intarea-shared-addressing-issues if required. 

Promoting assigning individual ports and not bulk of ports has aside effects including to increase the log files and it may reduce the number sessions that can be processed simultaneously by the AFTR (i.e., the performance of the AFTR are increased if a port set is allocated instead of individual ports). At least this should be mentioned.

I re-iterate my suggestion to remove this section from the core text of the draft. 

Cheers,
Med 


-----Message d'origine-----
De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la part de Rémi Després
Envoyé : mercredi 11 août 2010 17:38
À : Softwires
Cc : Ralph Droms
Objet : [Softwires] dual-stack-lite-06 - Too biased against static port sharing

Helo all,

Sec 8.4.1 says (asterisks added):
"... thousands or tens of thousands of ports could be use in a peak by any single customer browsing a number of AJAX/Web 2.0 sites.  
As such, service providers allocating a fixed number of ports per user should dimension the system with a minimum of N = several thousands of ports for every user.  This would bring the address space reduction ratio to a single digit.  Service providers using a smaller number of ports per user (N in the hundreds) should expect customers applications to break in a more or less random way over time.
In order to achieve higher address space reduction ratios, *it is recommended that service provider do not use this cookie-cutter approach, and, on the contrary, allocate ports as dynamically as possible, just like on a regular NAT*."

This is more biased against fixed number of ports per customer than technically appropriate, at least for the three reasons below. (Besides, such a bias isn't needed to justify the DS-lite specification): 

1. The text should take into account that "over time" more and more servers will have IPv6, and that the full 64K ports are available in IPv6. (The mentioned AJAX/Web 2.0 sites would typically enable IPv6 asap, if not done yet. This will prevent problems over time.)

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). 

3. Where applicable static sharing is much simpler to operate.

If the principle is agreed, I can propose detailed words myself to improve the draft.

Regards,
RD
 

Le 11 août 2010 à 00:30, Internet-Drafts@ietf.org a écrit :

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Softwires Working Group of the IETF.
> 
> 
> 	Title           : Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
> 	Author(s)       : A. Durand, et al.
> 	Filename        : draft-ietf-softwire-dual-stack-lite-06.txt
> 	Pages           : 34
> 	Date            : 2010-08-10
> 
> This document revisits the dual-stack model and introduces the dual-
> stack lite technology aimed at better aligning the costs and benefits
> of deploying IPv6 in service provider networks.  Dual-stack lite
> enables a broadband service provider to share IPv4 addresses among
> customers by combining two well-known technologies: IP in IP (IPv4-
> in-IPv6) and Network Address Translation (NAT).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-06.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Pièce jointe Mail>_______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************