[arin-ppml] Why should we do Proposal 121
jbates at brightok.net
Thu Dec 9 10:55:25 EST 2010
On 12/9/2010 8:15 AM, William Herrin wrote:
> On Wed, Dec 8, 2010 at 8:04 PM, Owen DeLong<owen at delong.com> wrote:
>> 1. Current IPv6 policy is being interpreted to the detriment of ISPs that
>> have subordinate ISPs. Subordinate ISPs should be able to get PA
>> space from their upstreams equivalent to what they would be able
>> to get directly from ARIN. Currently, ARIN is not allowing for the
>> possibility that an ISP would reallocate /32s (or larger) to their
>> subordinate ISPs.
> Hi Owen,
> Can you suggest a scenario in which a a subordinate /32 allocation is
> unambiguously appropriate on the technical merits versus the same ARIN
> allocation directly to the subordinate ISP? It seems to me like you
> might have to make some unwarranted assumptions to get there.
I can. I manage an ISP; except in my case, I have no end user customers.
What I have is a company that pools resources for 12 ILEC ISPs. I am
their LIR, I manage servers for them. I even manage their routers and
address assignments for most of them. Even the multihomed ones have
their ASN through me, not ARIN.
By current policy, each can go to ARIN and ask for a /32 minimum and pay
their fees. However, that has never been our practice. In practice, I go
to ARIN, pay a single fee (which is smaller than the total of individual
fees) and in many cases, when the ILEC isn't multihomed actively, I
announce them as part of my aggregate only.
ARIN stated the /32 minimum for an ISP was added on IETF recommendation.
I propose that the IETF was thinking of any ISP, including subordinate
ISPs. The /32 minimum keeps smaller/medium ISPs from growing in small
block increments which could lead to fragementation. For example,
current ARIN policy is to allocate on exact usage (HD-Ratio doesn't
apply to initial allocation, only subsequent due to a policy error). If
I accept an exact usage from ARIN for my 12 ILECs combined, then as any
of them grows, I have to assign a separate non-contiguous block to them.
This, in turn means an additional route in the routing table. As ARIN
assigned based on exact counts, I have no reserves for contiguous space.
I can't renumber networks as ARIN finally decides to give me HD-Ratio.
Compare this to getting a /27 (by pricing standards, I really don't want
to exceed that anyways), and I assigned 14 /32 to the 12 ILECs (a couple
of them also have downstream ISPs), of which there will be 4 route
announcements (aggregate + 3 multihomed ILEC aggregates)
This is current, not counting Owen's proposal. Owen's proposal is about
fixing this problem. The additional bonus on the nibble boundary
analysis is that it grows the network out even more in some cases,
allowing even better assignment schemes with room for reservations to
deal with known growing networks; which in turn can reduce routing table
bloat. If the pricing structure adjusts to match, I'd be thrilled with a
/24 vs the /27 I'm going for today, which would allow me a lot of room
to handle assignments to my subordinate ISPs and if they exceed their
/32, grow them into a /28. Since I can handle 16 /28's, my network would
forever announce 1 aggregate in my foreseeable future except for the few
multihomed ILECs (who would also be protected and safe of having to
announce more routes due to fragmentation).
> I don't personally find a reduction from /48 a compelling argument. If
> anything, a more reasonable recommendation than /48 would tend to help
> folks avoid foolish mistakes like /64... which actually could create
> the lowest-common-denominator effect you fear.
I think his concern is limiting the bits that can work with the childish
implementations that will be used in automatically handling DHCPv6-PD
through multiple end-user routers. The problem is that the standard
doesn't support better dynamic allocation, and the thought is that it
probably won't ever reach a perfected model, so routers will have to do
a divide and conquer method of reassigning networks automatically. The
size of the network directly effects the width and depth that such an
assignment scheme can support.
More information about the ARIN-PPML