IETF Logo Mail Archive

Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 20 August 2010 23:18 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2066F3A6832 for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 20 Aug 2010 16:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.358
X-Spam-Level:
X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 QOco88hwTwaE for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 20 Aug 2010 16:18:26 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2BD443A6898 for <v6ops-archive@lists.ietf.org>; Fri, 20 Aug 2010 16:18:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1OmaqB-000N1I-KR for v6ops-data0@psg.com; Fri, 20 Aug 2010 23:17:39 +0000
Received: from [209.85.216.173] (helo=mail-qy0-f173.google.com) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <brian.e.carpenter@gmail.com>) id 1Omaq9-000N11-Kb for v6ops@ops.ietf.org; Fri, 20 Aug 2010 23:17:37 +0000
Received: by qyk5 with SMTP id 5so1095644qyk.11 for <v6ops@ops.ietf.org>; Fri, 20 Aug 2010 16:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JY5/X/vYOcY5e13dLl2pfYKiwffqW7sjkPZd+FITdZg=; b=v2eyvJlKlh4LrqbhTZsG8sb5lkvZEIAqAmaC46/VxnsGJLrO8UlFaincUYNvkif+kN b/2HOUg4dInvjubKs9S48Y5V/8gLK6GLpwA2FCZuzjCcnHVBv7xIqAQ2Fna5HTAqvD3k 6AHTvi5yXuiSHbEJDoNxvIBJUWI1uMm0CX5ts=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=iH1BiycYhOR/Ey7F/fw7f6ybYQ5qY2EkSnTNmAj4a7eVj8lnacIXLqLnvaZbS0Vohz anieEQKAx8Pu7e4mX8gnYmVI/HK1m3XPsXNAEtN1T1ROaB29b9x2gcSj1Wp652hMcCLN tC+YbGHTRaMHK1q5l5t6a+5VFJgjUZqW4khWw=
Received: by 10.229.141.75 with SMTP id l11mr355529qcu.154.1282346256683; Fri, 20 Aug 2010 16:17:36 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id e6sm3828683qcr.5.2010.08.20.16.17.33 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 16:17:36 -0700 (PDT)
Message-ID: <4C6F0D09.9060107@gmail.com>
Date: Sat, 21 Aug 2010 11:17:29 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Tony Li <tony.li@tony.li>
CC: Eric Gray <eric.gray@ericsson.com>, IPv6 Operations <v6ops@ops.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E62F@EUSAACMS0701.eamcs.ericsson.se> <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.com> <4C6EE713.9080805@gmail.com> <4C6EE9D9.2090003@joelhalpern.com> <4C6EEC30.5010409@gmail.com> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E70A@EUSAACMS0701.eamcs.ericsson.se> <D2EC6C44-B0B7-4E20-A7E1-8021E724126F@tony.li>
In-Reply-To: <D2EC6C44-B0B7-4E20-A7E1-8021E724126F@tony.li>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 2010-08-21 10:45, Tony Li wrote:
> Hi Eric,
> 
> 
>> 	The second is that they can differentiate themselves by offering
>> address allocation sizes that do not align well with other providers, in
>> an attempt to lock-in customers who will find that they can anticipate
>> administrative head-aches and extra costs if they ever decide they want 
>> to go with a different service provider.  This is probably a bad thing.
> 
> 
> Alternate service providers can then respond by matching the odd address space allocation, or providing their next quantum up.  This hurts addressing efficiency slightly, but is unlikely to be a real deterrent.

Exactly. The market will provide. Of course, I agree with Fred that
we should stick to nibble boundaries.

     Brian

v2.23.0 | Report a Bug | By Email