[arin-ppml] Using fees to encourage route aggregation

[Kevin Kargel]

As always I will stand hard and fast against artificial fees (can you say
"taxes") to control behavior.

The history of the internet has always been that things are arranged so that
what works best is what is easiest.  If you want people to adopt a certain
behavior then make it so that it is easier for them to behave in the manner
you want, they will do it.

> On Oct 15, 2009, at 9:20 AM, Scott Leibrand wrote:
> 
> > Milton L Mueller wrote:
> >>
> >> Thanks for your intervention, Chris. That's exactly where I've been
> >> trying to move. In that regard I find it interesting that despite
> >> the constant worrying about route aggregation, the proposal I made
> >> to use RIR fees to encourage aggregation (or "tax" deaggregation)
> >> has not attracted a single comment. People seem more interested in
> >> the broad ideological classifications than in assessing specific
> >> proposals.
> >
> > Perhaps people were ignoring the "fairness" thread?  :-)  Or
> > perhaps, like me, most people generally agree with that particular
> > point, so there's maybe not as much to discuss.  My own thought is
> > that using fees to encourage aggregation (discourage deaggregation)
> > would probably work, but that there isn't a lot of need for doing so
> > just yet.  If we get to the point where multiple networks are having
> > problems with routing table growth that can't be solved through
> > filtering of distant more-specifics, through charging customers for
> > route announcements, and/or through peering agreements, then perhaps
> > someone will resurrect the idea on arin-discuss for the board's
> > consideration.
> 
> 
> I don't think most people agree with that particular point.
> 
> The RIRs role is NOT to afflict routing policy with their judgment of
> how it should be done.
> 
> The RIRs should focus on allocation policies that meet the needs of
> the community and
> leave routing issues to those that run routers and the IAB/IETF/IESG/
> etc.
> 
> Setting fees based on disaggregation is a quagmire that would leave
> the RIR staff in
> an untenable position. Which view of the routing table would be
> considered the
> authoritative reference for disaggregation? Would momentary leaks of
> more specifics
> count against someone if they just happened to coincide with the
> billing sweep through
> the table? Over what period of time should a prefix have to be
> disaggregated in order
> to increase the billing for the prefix? Should the bill increase with
> the amount of time
> the route remains in the table? If so, how do you account for
> convergence delay in the
> billing process?
> 
> Due to scarcity, IPv4 unfortunately made the RIR the point where we
> needed to
> adjudicate the balance between two strongly conflicting principles...
> The ability
> to issue address space to those who needed (through mechanisms like
> slow-
> start, limited time consumption expectancies, etc.) vs. the ability to
> optimize
> the routing table.
> 
> So far, that tradeoff has been readjusted several times with
> allocation periods
> changed, maximum prefix lengths adjusted, etc.  I don't know for
> certain what
> the future will hold in this for IPv4, but, it doesn't matter too much
> since the RIRs
> won't be issuing IPv4 much past the next 3 or 4 policy cycles anyway.
> 
> However, in IPv6, there really is no need for the RIRs to balance
> this.  End users
> and ISPs are perfectly capable of developing mechanisms to determine
> what
> IP resources from what source are required to meet their needs.  The
> RIRs should
> evaluate resource requests on the basis of justified need per the
> policies set
> by the community without regard to routing.
> 
> Owen
> 
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091015/a1368beb/attachment.bin>