[ppml] Policy Proposal -- Recommended v6 aggregation practices

[Owen DeLong]

I expect ARIN to implement it strictly by sticking the words in the
NRPM.  I do not expect it to be in any way enforceable, as ARIN does
not enforce routing policy.  However, most of the content of that
section of NRPM is unenforceable guidelines, so, I don't see any
reason to treat these differently.

Owen


--On April 28, 2006 12:43:15 PM -0700 "william(at)elan.net"
<william at elan.net> wrote:

> 
> Question:  How do you expect ->ARIN<- to implement this?
> 
> On Fri, 28 Apr 2006, Owen DeLong wrote:
> 
>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
>> 
>> Policy Proposal Name: Recommended v6 aggregation practices
>> Author
>> name: Owen DeLong
>> email: owen at delong.com
>> telephone: 408-921-6984
>> organization: DeLong Consulting
>> Proposal Version: 1.0
>> Submission Date: 28 April, 2006
>> Proposal type: new
>> Policy term: permanent
>> Policy statement:
>> 
>> Add section 6.3.9 to NRPM as follows:
>> 
>> 6.3.9 Recommended Practices to Maximize Aggregation
>> 	6.3.9.1
>> 		Whenever feasible, an organization should make best possible
>> 		use of provider assigned space.
>> 
>> 	6.3.9.2
>> 		Except in the most extraordinary of circumstances, no ASN should
>> 		originate more than a single v6 aggregate prefix. Sparse allocation
>> 		practices should prevent the need for growth-induced additional
>> 		prefixes in most cases. Non-ISP organizations expanding beyond their
>> 		reservation should renumber into the larger block if at all possible.
>> 
>> 	6.3.9.3
>> 		In the case of merger or acquisition resulting in a combination
>> 		of multiple autonomous systems into a single topology and/or
>> 		routing policy, the organization should strive to either combine
>> 		the networks into one of the existing prefixes, or, obtain a
>> 		new larger prefix and renumber.  A grace period of up to 3 years
>> 		should be allowed for this purpose.
>> 
>> Rationale:
>> 
>> 	A number of the concerns raised over proposal 2005-1 seem to center
>> 	around the possibility of routing table growth due to further
>> 	deaggregation and other forms of v4-like table bloat resulting from PI
>> 	space.
>> 
>> 	This proposal is an attempt to reduce and/or mitigate those issues
>> 	to some extent.  I have no illusion that this is a panacea, and, I
>> 	remain convinced that the only truly viable solution is to develop
>> 	a routing process for IDR which does not use the End System Identifier
>> 	as the Routing Locator.
>> 
>> 	I also remain uncomfortable with the idea of ARIN getting involved
>> 	in routing policy.  I think this is the purview of the ISPs exchanging
>> 	the routes in question.  However, I think these recommendations are
>> 	a reasonable compromise towards a pragmatic attempt to address the
>> 	existing situation until something better can be achieved.
>> 
>> Timetable for implementation: Immediately upon BoT Approval
>> Meeting presenter: Owen DeLong
>> 
>> END OF TEMPLATE



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- 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/20060428/2502880d/attachment.sig>