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

Alain Durand <adurand@juniper.net> Thu, 12 August 2010 01:51 UTC

Return-Path: <adurand@juniper.net>
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 55E473A67D3 for <softwires@core3.amsl.com>; Wed, 11 Aug 2010 18:51:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.377
X-Spam-Level:
X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 35IZN0d-IWZS for <softwires@core3.amsl.com>; Wed, 11 Aug 2010 18:51:47 -0700 (PDT)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 6988D3A67A4 for <softwires@ietf.org>; Wed, 11 Aug 2010 18:51:47 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTGNT1t0vI8LDskc0wZ5cpcugHv9xeL67@postini.com; Wed, 11 Aug 2010 18:52:24 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 11 Aug 2010 18:50:09 -0700
From: Alain Durand <adurand@juniper.net>
To: Ralph Droms <rdroms@cisco.com>, Rémi Després <remi.despres@free.fr>
Date: Wed, 11 Aug 2010 18:50:07 -0700
Thread-Topic: [Softwires] dual-stack-lite-06 - Too biased against static port sharing
Thread-Index: Acs5wLGcEyRJu7NjSQW5mW3HZ9Akfg==
Message-ID: <BA887853-17B9-4FD9-B6BC-08E0E0CAA40D@juniper.net>
References: <20100810223005.AA3E73A6AE3@core3.amsl.com> <F6FAFA3B-EFE3-4108-90B7-370A872CD5C7@free.fr> <6D86FFCC-62BB-4658-B0E0-E7CB63269530@cisco.com>
In-Reply-To: <6D86FFCC-62BB-4658-B0E0-E7CB63269530@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires <softwires@ietf.org>
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 01:51:48 -0000

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.