[ppml] Comments on revised 2005-1 proposal of 2006-02-03

[Owen DeLong]

I thought the original argument against opening up PI was to avoid creating
an early adopter advantage.  Why is it better to give large organizations
first crack at an early adopter advantage and then later consider whether
or not to treat the rest as second class citizens?  I see that as being
even worse than the small risk of an early adopter advantage.

Frankly, I think that realistically, the following are true:

1.	We need a new IDR paradigm that allows for a separation between
	the routing locator and the end system identifier (ASN and IP
	address are most likely mappings for RL and ESI in the near
	term, but, today, we are using IP address for both).

2.	By continuing to treat organizations below some arbitrary
	threshold as second class citizens on the internet, we _MAY_
	be able to postpone the date when the new routing paradigm
	mentioned in 1 is required.

3.	Even if we gave v6 PI blocks to everyone who could justify
	them under the most liberal of these policies, I believe it
	would be at least 10 years before we had to truly worry
	about router meltdown due to table size.  That should be
	more than adequate time for IETF to develop a solution.
	(I believe I have good beginnings of a solution.  Let me
	know if you are interested in more detail).

4.	I believe a solution is possible which requires:

	1.	code changes on core routers.
	2.	code changes on DFZ Edge routers.
	3.	Additional CPU on DFZ Edge routers (potentially)
	4.	Suggests crypto acceleration on DFZ Edge routers
	5.	Does not require modifications to non-DFZ routers
	6.	Limits the size of the global routing table to the
		list of viable AS Paths.
	7.	Allows leaf sites to multihome with a single PI block
		and no AS, thus not increasing the routing table
		slots in the DFZ.

5.	Since the above solution does not require edge router updates,
	and most DFZ routers see software updates more than once per
	year and hardware replacement usually on approx. a 3 year
	cycle, and, this doesn't require hardware changes (although
	some are recommended), 10 years gives the IETF 7 years
	to argue, code, test, agree, and publish and we still have
	plenty of time for the vendors to add it to the featureset
	and roll it out to end users.  I agree that expecting IETF
	to agree on anything in 7 years may be a bit optimistic,
	but, I think it can be done.

Finally, we need PI space for end sites/users/organizations/whetever term
you prefer precisely because IPv6 did not solve multihoming.  The lack
of a multihoming solution in IPv6 makes it a non-starter for most
organizations.  Lack of PI space will have a similar effect for other
reasons besides multhoming.  Renumbering a /48 can be prohibitively
painful and costly, especially when it involves ACLs and pointers
that are maintained in foreign authority zones (customers VPN ACLs,
etc.).  Locking businesses into a particular provider just because
we're too lazy to fix the protocol is no longer an option.

Owen

Owen


--On February 9, 2006 9:33:44 AM -0500 Glenn Wiltse <iggy at merit.edu> wrote:

>    I wasn't nessasarly endorsing any 'host count' as being the
> defining factor. However I do think the main point of contention
> is how exactly to determin some size threshold nessasary, and what
> to use as a unit of meassure. That's why I personaly like
> the idea of using unique street addresss.
>
>    One thing I don't like, and I think many others don't like, is the
> idea  that ARIN would hand out many /48s simply because some orginzations
> felt  they had to have PI space and/or they are currently multi homed.
>
>    Maybe later, after some of the biggest end originzations have gotten
> PI  space, and we know where we stand in terms of demand and/or needs, we
> could possibly later relax the size limits and/or then start to give out
> smaller block, etc...
>
> Glenn Wiltse
>
> On Thu, 9 Feb 2006, Dan Golding wrote:
>
>> On 2/9/06 8:28 AM, "Glenn Wiltse" <iggy at merit.edu> wrote:
>>
>>>     In general, I like the direction Thomas is  heading in... (giving
>>> PI to the largest sites and trying not to give out small blocks simply
>>> because someone says they need multi homing, etc...)
>>>
>>> I would change refferances to 'end site', in favor of the term 'end
>>> orginization' (which would imply these cant' be re-assigned to other
>>> orginizations, but little else implyed in the meaning)
>>>
>>>    In my mind, the only real sticky point is in deciding what exactly
>>> defines a originization as being 'large' enough to get a PI assignment.
>>>
>>> I do think that a /40 is about the smallest sized block that I would
>>> like to see given out as IPv6 PI space at this time. Just how you
>>> define who is large enough to justify such a assignment I do not know.
>>>
>>>   I personaly would rather see unique street addresses be considered
>>> as justification for space, more so then number of employees... but
>>> perhaps either or... or some combination of both, etc...
>>>
>>>    Anyway, I do really think Thomas is on the right track with his
>>> most recent comments and/or proposal.
>>>
>>> Glenn Wiltse
>>
>> This is a dead end. The last 2005-1 was defeated at the last ARIN meeting
>> specifically because of the 100k host requirement.
>>
>> - Daniel Golding
>>
>>
>>
>>
>> !DSPAM:43eb4f0186132993215505!
>>
>>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml



-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060209/9da7016c/attachment.sig>