[ppml] Proposed Policy: Recommended v6 aggregation practices

[Owen DeLong]

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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060501/2c2578ef/attachment.sig>