[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)
jbates at brightok.net
Wed Nov 17 19:05:56 EST 2010
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
>> 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
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.
More information about the ARIN-PPML