[arin-ppml] Some observations on the differences in the varioustransfer policy proposals

[Kevin Kargel]

I want to support Scott (at least I think that is what I am doing in what he

says about RIR's and whther they need to have every answer.  I do agree that

the RIR is primarily a registry, and at inception was not meant to be a 
regulating body.  Could it be that we are getting too big for our britches?

>From the RIR perspective I don't think there is a problem with 
mini-allocations (<=/24).  In fact allowing mini-allocations will increase
the 
customer base.

The people who will have a problem with small allocations will be the end 
users, who will find limited connectivity as peering points respond to 
excessive de-aggregation by aggregating and filtering route advertisements.

This is not to say that small allocations will not have their use.  They
will 
still be great for the near direct connected organizations who need a small 
secure common block and don't mind manually inserting a routing entry for
it. 
What the small allocation will not work for is the SOHO implementation that 
needs a /27 for various and sundry public servers on a global market.  That 
customer will still be better off going to his provider for a re-allocated 
block.

The whole de-aggregation thing will be self healing.  Peering points will 
route using tables near the maximum size the hardware can handle and they
will 
do whatever is necessary to not break themselves.  End users will have 
connectivity to the limits of their providers hardware.  Some providers will

spend more on hardware to have greater cpability and pass that cost to their

customers.  Other providers will spend less, provide less granular routing
and 
charge less to their customers.  Business will dictate which is the better 
strategy.  End users who can't route because of aggregation will renumber or

NAT and migrate to numbers that route more easily.

Historically this has been one of the ways the internet has evolved.
Someone 
has a neat idea, and tries it.  If it works it gets implemented, if it
doesn't 
work it gets relegated to the bad idea pile.  Sort of a Darwinian approach
to 
networking.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Geoff Huston
> Sent: Sunday, October 19, 2008 9:25 PM
> To: Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Some observations on the differences
> in the varioustransfer policy proposals
>
> Hi Scott,
>
> >> In your article you imply that the RIRs' registry
> functions are not
> >> the proper lever from which to apply the various
> regulatory functions
> >> that the community has indicated are needed.  Where/how would you
> >> propose the regulatory function reside / be applied instead?
> >>
>
> Again, the real question is, MUST the RIRs have an answer for
> _everything_? Must the RIR's devise complex procedures that
> attempt to counter particular behaviours,  at the common
> community cost of more onerous procedures with higher
> overheads. And without any practical enforcement mechanism
> why will others even listen to the RIRs?
>
> To quote from the article:
>
> "But the observation should be made that markets in all
> manner of good and services have a rich history in human
> societies, and the role of the regulator is similarly one
> with a rich history. Market regulators exist in many guises
> and in many regimes, and can exert influence through various
> direct and indirect means. There is no need to believe that
> this issue of transfers and address markets requires a
> comprehensive solution based solely on the resources,
> capability, authority and enforcement authority of the RIR's.
> Once the RIR's are no longer address allocation entities much
> of their ability to enforce certain behaviours goes with that
> role, and the residual role, that of operation of an address
> registry, necessarily has to take a more neutral stance if it
> is to be a role that is discharged effectively."
>
>
>
>
> >> Or, to put a more practical face on the same question: how do you
> >> propose that the industry deal with the deaggregation that will
> >> result from the widespread transfer of small netblocks (as allowed
> >> under prop-50)?
> >>
>
>
> Thats a very good example, because deaggregation in the
> address space has been a constant factor for decades. i.e. if
> enforcing strong aggregation in the routing space was a
> metric of success of the policy framework associated with
> allocation, then the metrics of the routing system over the
> past 10 years would have to assign a failing grade here.
>
> Again, to quote from the article:
>
> "However, fragmentation of the routing space has not been
> directly linked to the further allocation function, and the
> results of this decoupling of policy with a risk of any
> negative outcome is clearly evident in the continuing
> fragmentation observed in the routing space."
>
> So, no, I don't think that any transfer policy proposal will
> do any better than the allocation policy framework, and the
> allocation policy framework has been, on the whole, ineffectual.
>
>
> >> I agree that restricting deaggregation through regulating
> access to
> >> the registry will not be 100% effective, but it seems more
> likely to
> >> be effective than any alternative I've seen so far.
> >>
>
> Well with no successful practical experience to call upon so
> far, I suppose that we can all have a guess at what an
> effective policy may be in this area.
>
> regards,
>
>     Geoff
>
>
>
>
>
> _______________________________________________
> 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: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20081020/b818f568/attachment.bin>