[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)

[Jack Bates]

I know Owen responded, but I wanted to expand on some points.

On 11/17/2010 2:34 PM, Ted Mittelstaedt wrote:
> You said in the Rationale that you want ARIN to lower prices for the 
> smaller orgs.  I think that right there would encourage more of them to
> get their own numbers, thus increasing the DFZ
>
There is a strong reason not to block on RIR PA minimums. PA allocations 
do not always match ASN assignments, and there will be people 
multihoming using longer than /32 prefixes. It is our hope that this 
will be at a minimum with v6 as newer technologies support multihoming 
with multiple prefixes instead of the current method. This, however, is 
not an allocation policy concern.


>> By increasing the maximum amount of space allowed (possibly 
>> dramatically),
>> if anything, this should reduce the impact on the DFZ.
>>
>
> And the logical reason for this is....
>

The reason, as Owen stated separately, is that if I have to keep 
returning for allocations, they will end up getting divided, and as a 
provider I will have multiple networks I must advertise. However, this 
is actually unlikely, as I suspect most ISPs with 3+ transit peers will 
need a granularity of up to 16 networks advertised to properly balance 
traffic, as natural BGP balancing doesn't work at certain bandwidth 
ranges. In v6, it is unlikely that you will receive 16 separate 
allocations. In v4, you often could end up with many more allocations 
that exceeded the number of prefixes you'd need for granular balancing.


> As I see it, sticking one sentence in the Rationale saying that the
> lowering the bar that the criteria change makes should not cause DFZ
> bloat because of X is no skin off your nose.  So your refusal to do
> it is self-defeating.  Which is more important, getting the proposal
> accepted or maintaing your personal paradigm that even speaking about 
> DFZ bloat is flawed?
>

I think the issue is that we would even consider it as a DFZ bloat 
issue. Smaller allocations force DFZ bloat, but there is an expectation 
that even large allocations will be divided to help BGP with policies 
and balancing. It would be hoped that this would be done with as little 
granularity as necessary, but in IPv4 it has often been shown not to. 
That being said, in IPv4, I have way more networks advertised than 
necessary to balance my traffic and it is because of how restrictive the 
allocations are.

Policy, I believe, already and will continue to state that the recipient 
of an allocation should advertise the aggregate. If they advertise 
longer prefixes for balancing, this allows the aggregate to handle those 
cases where people's routers can't handle the longer prefixes. 
Allocation Policy != Routing Policy, and I suspect it never will.


Jack