[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Owen DeLong]

On May 31, 2011, at 8:49 AM, Mike Burns wrote:

> This is all an unnecessary and needlessly confusing set of rules whose only purpose is to attempt to impose some restriction on the downwards slide towards disaggregation which will happen whatever policies we prescribe.

I believe the question here is a matter of degree and that with good policy we can reduce the degree significantly.

>  
> In a fluid transfer market, nobody will purposely select to fill their needs with a smattering of smaller netblocks, they will by nature attempt to acquire the largest block to suit their purchase requirements, if only to relieve them of configuration complexity.
>  

Unless price pressures encourage them to do otherwise. I think it's very likely they will.

> In fact, my guess is that people will tend to round up, to allow for a little more room to grow within a contiguous block, bounded of course by the cost of holding unused inventory of addresses. 
>  

Some will, some won't. As you mentioned, I think that pricing could become a significant motivator here
and that it might well serve to motivate people in the opposite direction of the desired result.

> Larger netblocks are more likely to be routed everywhere than smaller ones, and this alone will drive consumers towards aggregation.

Only for relatively small definitions of the term "smaller". Filtration at less than /20 is virtually impossible. Filtration
at the point of /18s would be beyond dysfunctional. From a filtration perspective, I doubt anyone would think
much about the difference between a /12 and 64 /18s.
>  
> Creating a new and confusing set of rules related to timeframes for allowed purchases, tracking original registration sizes through potentially multiple transactions, restricting sellers from selling off chunks of their holdings, these things are exactly what would be wrong in putting the steward's lightest touch on things.
>  

Again, I disagree. To prevent a transfer market from becoming a completely disruptive process to
the stability and function of the internet, there need to be some limitations. The question is what
is the minimal set of functional regulations. I believe that some restrictions on disaggregation
are vital.

> Because they would inevitably lead to buyers with a real need not getting addresses in a timely fashion, additional listing requirements (like original allocation size), and of course, lots more transactions happening off the books and leading to a decay in Whois accuracy and representing a failure of our primary stewardship role.

You keep insisting that any attempt to regulate the market will increase transactions off the books,
yet, you have no proof of this and you continue to ignore the significant risks that would be taken
by organizations attempting to engage in off-the-books transfers. It's a great bogey-man, but, I am
not convinced that it is a real threat or that a significant volume of these transactions would, in fact,
occur.

>  
> And where is the evidence that this will serve as an actual check on disaggregation, and where is the evidence that we are BGP-table bound, in any real sense?

There are currently almost 400,000 routes in the global table. There are many large AS's that are
carrying more than 75,000 interior routes not visible in the global table. There are not very many
routers out there that can sustain a FIB with more than 500,000 unique destinations.

We are most definitely BGP-table bound in a very real sense.

Additionally, we are on the ragged edge of churn-bound in a very real sense in some cases.
There is significant documentation to indicate that more prefixes increases churn, though, not
in a directly proportional manner.

As to whether this would serve as an actual check on disaggregation, it at least serves
nearly as well as current policy without transfers does, so, it at least preserves most of
the functionality of current RIR policy which is about the best I think we can actually do.

If you have an idea for a more effective mechanism, I think that would be great. If you don't,
then I think it is better to at least make some attempt to limit disaggregation than simply
open the flood gates and watch the internet collapse under the weight of its routing
table.

>  
> The check on the growth of the table will not come from the RIR's, in a post-exhaust world, it will come from the decisions of the network operator group about what the minimum routable block size is.

At what cost. Escalating the minimum routable block size will likely lead to disruption and
instability for existing users of smaller blocks. I consider that an undesirable consequence
of a failure of stewardship. I think it is far better to attempt to manage the transfer process
so as to reduce this probability, even if we cannot eliminate it altogether.


Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110531/97586b69/attachment.htm>