[ppml] Proposed Policy: Recommended v6 aggregation practices

This was intended just to be an augmentation to the stuff that already
exists in that section of the IPv6 Policy Manual. It is an attempt
at making a community recommendation, not necessarily a BCP.

Owen


--On May 1, 2006 4:24:01 PM -0400 "Divins, David" <dsd at servervault.com> 
wrote:

> While I do not necessarily disagree with the content of the policy, I do
> not believe ARIN is the correct place for a BCP on route aggregation.  I
> do not claim to know where the best place is
> (IETF/IANA/Juniper/Linksys?) however; I do know I'm not crazy about it
> being ARIN.
>
> Just my thoughts...
>
> dsd
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Member Services
> Sent: Monday, May 01, 2006 12:25 PM
> To: ppml at arin.net
> Subject: [ppml] Proposed Policy: Recommended v6 aggregation practices
>
> ARIN received the following policy proposal. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
> ARIN's website.
>
> The ARIN Advisory Council (AC) will review this proposal and may decide
> to:
>       1. Accept the proposal as a formal policy proposal as it is
> presented;
>       2. Work with the author to:
>           a) clarify the language or intent of the proposal;
>           b) divide the proposal into two (2) or more proposals; or
>           c) combine the proposal with other proposals; or,
>       3. Not accept the proposal as a formal policy proposal.
>
> The AC review will be conducted at their next regularly scheduled
> meeting.
>
> If the AC accepts the proposal or reaches an agreement with the author,
> then the proposal will be posted as a formal policy proposal to PPML and
> it will be presented at a Public Policy Meeting. If the AC does not
> accept the proposal or can not reach an agreement with the author, then
> the AC will notify the community of their decision with an explanation;
> at that time the author may elect to use the petition process to advance
> their proposal. If the author elects not to petition or the petition
> fails, then the proposal will be considered closed.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>## * ##
>
>
> Policy Proposal Name: Recommended v6 aggregation practices
>
> Author: Owen DeLong
>
> Proposal Version: 1.0
>
> 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
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
> _______________________________________________
> 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 : http://lists.arin.net/pipermail/arin-ppml/attachments/20060501/2c2578ef/attachment.bin