[ppml] 2005-1 and/or Multi6

[Owen DeLong]

The mechanism for reclamation would be as follows:

	1.	Either:
			ARIN Board makes emergency decision to stop issuing
			space under this policy, and, no space under this
			policy is eligible for renewal.

		or
			ARIN policy process determines an end of life procedure
			for this policy.

	2.	After 1, the inability to perform annual renewal eliminates
		the existing resource assignments through attrition.

Owen


--On Thursday, April 14, 2005 10:11 +1000 Geoff Huston <gih at apnic.net> 
wrote:

>
>> Interestingly I had an exchange at the microphone during the IAB Plenary
>> open session about this topic.  I pointed that this policy existing and
>> is  being considered in the ARIN region and if this policy was
>> implemented the  ideas about a very small v6 routing table may go away.
>> Someone responded  with a comment like, that is just fine for the first
>> 65k routes.
>
> There is no need for a 'very small' routing table - there is a need for a
> routing table that is viable within the parameters of the infrastructure
> base that makes up the network. So the objective is to support address
> deployment practices that match deployment models to the extent that the
> resultant network is one that fits efficiently into the deployed
> infrastructure platform. These days its reasonable to suggest that the
> comfort zone is greater than 10**5 entries, and probably around 10**6
> entries. This is of course a little higher than the current IPv6 value of
> some 750 entries. The concern I hear is that in creating this collection
> of unaggregated /48 entries in to the routing table we have no clear idea
> of what mechanism we may use in the future to reclaim these entries when
> routing slots may be under some scarcity pressure. There is the concern
> that this may be an enduring legacy that would be difficult to undo. On
> the other hand we may be placing too much emphasis on strict provider
> aggregation and pressure for very small routing tables in their wake
> creating a different, but equally tough set of issues, such as scoped
> addresses, id/locator split architecture, extended protocol handshakes
> and shared context for session support that may in the long run prove
> more of an intractable  scaleability problem than routing!
>
> As far as I can see part of the problem here is that routing is en
> evironment that has very limited feedback mechanisms for control
> functions.
>
>    Geoff
>
>
>
>



-- 
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/20050414/379d5170/attachment.sig>