[arin-ppml] Why should we do Proposal 121

[Jack Bates]

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.


Jack