[arin-ppml] IPv4 Fragment Managemnt policy proposal

[Hannigan, Martin]

No need to assert a position on this, but I will say that the distribution
method is severely lacking. Under this regime some will undoubtedly fulfill
their requests entirely and others will not.

The language that would be more suitable is something akin to pct of space
available related to request fulfillment pct IMHO. Specifying hard limits
may be anti-competitive, especially with the apparently hostile reason that
you state for the creation of this policy ³I believe there is a need for
policy to prevent this kind of gathering of the last breadcrumbs by a small
number of large entities.²

Best,

-M<


-- 
Martin Hannigan                        http://www.akamai.com
Akamai Technologies, Inc.              marty at akamai.com
Cambridge, MA USA                      cell: +16178216079
                                       ofc: +16174442535



From: Owen DeLong <owen at delong.com>
Date: Wed, 28 Apr 2010 14:38:13 -0700
To: <policy at arin.net>, arin ppml <ppml at arin.net>
Subject: [arin-ppml] IPv4 Fragment Managemnt policy proposal

At ARIN XXV, one of the discussions pointed out that under current
ARIN policy, after IANA runout, a justified request for a /10 could
(and would) be satisfied, if necessary, by issuing 1024 disjoint /20s.

I believe there is a need for policy to prevent this kind of
gathering of the last breadcrumbs by a small number of large
entities. As such, I offer the following proposal for the discussion
of the community.

Owen

TEMPLATE: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1.      Policy Proposal Name: IPv4 Fragment Management
2.      Proposal Originator
        a.      name: Owen DeLong
        b.      email: owen at delong.com
        c.      telephone: 408-890-7992
        d.      organization: Hurricane Electric
3.      Proposal Version: 0.8
4.      Date: 2010-04-28
5.      Proposal type: New
        new, modify, or delete.
6.      Policy term: Permanent
        temporary, permanent, or renewable.
7.      Policy statement:

Add the following to the NRPM as new sections 4.2.1.7 et. seq.

Each time ARIN approves an IPv4 request which it cannot
satisfy from 4 or fewer bit-aligned blocks of free address
space, ARIN shall notify the requestor that there is
insufficient free address space to meet their request and
shall offer the requestor their choice of the following
alternatives:

a. They can have the largest 4 available bit-aligned
blocks of free addresses.

b. This section reserved -- (in case we implement the
waiting list for unmet requests policy)

c. They can seek resources through the directed
transfer policy in section 8.3 of the NRPM.

8.      Rationale:

When the ARIN free pool begins to diminish, the free space
will become fragmented into smaller and smaller remaining
contiguous spaces. This policy attempts to ensure that a
large number of remaining disjoint small blocks are not
consumed by a single large request.

While this policy could be regarded as unfair to larger
entities, it is consistent with the safeguards adopted in
section 8.3 which require an exact match or full fill
style of resource transfer.  As such, I believe the policy
is fair and in line with the consensus will of the community.

9.      Timetable for implementation: Immediate, although it has no
actual effect until some time after IANA runout.

END OF TEMPLATE



_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100428/7e2ef630/attachment.htm>