Re: Consensus Call: draft-weil-shared-transition-space-request

Joel jaeggli <joelja@bogus.com> Fri, 02 December 2011 05:51 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE1621F8E4B; Thu, 1 Dec 2011 21:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 aUeDcZE5KzRg; Thu, 1 Dec 2011 21:51:59 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26121F8DF7; Thu, 1 Dec 2011 21:51:58 -0800 (PST)
Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pB25pmj6047405 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 2 Dec 2011 05:51:49 GMT (envelope-from joelja@bogus.com)
Message-ID: <4ED86774.4000001@bogus.com>
Date: Thu, 01 Dec 2011 21:51:48 -0800
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Pete Resnick <presnick@qualcomm.com>
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request
References: <13205C286662DE4387D9AF3AC30EF456D74D86836B@EMBX01-WF.jnpr.net> <CAC1-dt=kkZ0+f2i4J+K-huyuc9OBEy_auAn=RL6Qf8u+DpmrHw@mail.gmail.com> <4ED5720A.5020401@dougbarton.us> <CAC1-dtkXHjd9DLaZsCDW+owNknLiRa9DuBF4uYaVTH7jxDoV+g@mail.gmail.com> <4ED6978B.1040201@gmail.com> <CAOw3xnZf600sWpeODkaUq516nAeNPX8inMrE1kESQiyi4NXhOw@mail.gmail.com> <4ED6E322.3000801@qualcomm.com> <CA+9kkMAe5mdzjwHETYrBHxfOWBZQ8sd8xXadwGzD4n-hniq3mg@mail.gmail.com> <4ED84A51.6040200@qualcomm.com> <4ED85019.8030904@dougbarton.us> <4ED853D5.3000409@qualcomm.com>
In-Reply-To: <4ED853D5.3000409@qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 02 Dec 2011 05:51:50 +0000 (UTC)
Cc: Ted Hardie <ted.ietf@gmail.com>, IETF Discussion <ietf@ietf.org>, IESG IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2011 05:51:59 -0000

On 12/1/11 20:28 , Pete Resnick wrote:
> On 12/1/11 10:12 PM, Doug Barton wrote:
>> On 12/01/2011 19:47, Pete Resnick wrote:
>>   
>>> The current draft says that the reason 1918 space can't be used is that
>>> equipment that deals in 1918 address space is hosed if 1918 addresses
>>> are used on their external interface.
>>>      
>> Let's assume that's true for a second (I haven't seen any evidence of
>> that). We all know that if the /10 is allocated that people are going to
>> use it for 1918 space. So, back to square 1.
>>    
> 
> No, that's not true. Once this document claims that a particular block
> of addresses will be used on both internal and external interfaces,
> whether they're from a part of 1918 space that isn't used by the broken
> equipment *or* from a new /10 (which obviously isn't used by the broken
> equipment), any *new* use of this address space by *newly* broken
> equipment is acceptable to the CGN people. The only thing the current
> document worries about is deployed equipment that the CGN people can't
> push back on. So either a new /10 or 1918 space not used by current
> broken equipment addresses this problem.
> 
>>> Brian claimed that perhaps
>>> 172.16/12 space might not be used by that equipment. Robert claimed that
>>> perhaps only 192.168 and 10.0.0.x addresses are used by that equipment.
>>> So the question I posed was, "Does any of *that* equipment use 172.16/12
>>> (or 10.x/16) space?" Nobody has said "yes".
>>>
>>> And *I'm* still not claiming that the answer is "No." I simply don't
>>> know. But I'm inclined to hear from anybody to indicate that there is
>>> *any* evidence that the answer is "Yes". That would make me much more
>>> comfortable in concluding that new specialized address space is the
>>> better horn of this bull to throw ourselves on.
>>>      
>> The lack of research on this point has been pointed out in the past, and
>> TMK has never been addressed.
>>    
> 
> Ron's point (that part of the problem is that people simply don't know)
> is well-taken, but if there is not even anecdotal information that
> 172.16/12 or 10.x/16 is used by broken equipment, I'd like there to be
> some research before we say that allocating a /10 is necessary.

it's simpler than that.

assuming that there existing a pool of devices for which it can be
stipulated:

	* does not support a collision between internal and external
	  address ranges
	* has a collision between it's internal address ranges and
	  assigned external prefix in 10/8

It seems unlikely in the extreme that home cpe statifying both
conditions would also have a collision with an assignment out of 172.16/12.

I have never found the arguement that, that particular problem
intractable enough to benifit from and additional prefix to be
particularly compelling.



> pr
>