[ppml] Policy Proposal 2002-3: Micro-Assignments forMultihome d Networks

[Bill Darte]

> From: Jeff S Wheeler [mailto:jsw at five-elements.com]
> Sent: Thursday, August 28, 2003 12:22 PM
> To: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2002-3: Micro-Assignments
> forMultihome d Networks
> 
> 
> On Wed, 2003-08-27 at 16:03, Leo Bicknell wrote: 
> > In a message written on Wed, Aug 27, 2003 at 02:11:38PM 
> -0500, Bill Darte wrote:
> > > There is always a diversity of opinion and very little 
> evidence to support
> > > the contentions.
> > > 
> > > I simply hate making decisions with too little or no 
> facts to rely on.....
> > > especially when experts within the same realm cannot agree.
> > 
> > Unfortunately many of these things come down to predicting the
> > future, and worse predicting the outcome of actions that have never
> > really been tried before.  Sadly, we're mostly stuck in a situation
> > where trial and error is the best option, which is often very hard
> > for an engineer to accept. :)
> 
> I'm sure you've followed the entire thread closely, Bill, and while I
> can understand your concerns that micro-assignment policy may spur new
> route table growth and perhaps even hasten address space exhaustion, I
> believe Leo's excellent suggestion to "rate-limit" micro-assignments
> will limit the global bgp-speaking community's exposure. You 
> didn't seem
> to address this in your follow-up post, but I would like to hear your
> thoughts on the feasability of the "rate-limit" mechanism by the ARIN.

First, let me explain that I have no concerns about the route table
exploding as a result of 2002-3 implementation.  I express the concern
because I have heard it expressed by some that I try to represent.  There is
no evidence to suggest that moving the boundary two bits to /22 would cause
a large problem.  Even if there were, filtering would limit its impact.
Rate-limits mechanisms are a way to comfort those with concerns in this
area.

Rate-limits are implicit in the follow-up mechanism proposed with the 2003-3
policy.  That is, that the route table be analyzed for growth during each of
the first 2 six-month periods following implementation..... implicitly,
action would be taken to limit assignments if there were substantial
difficulties with the policy implementation...... which I doubt would
happen.  Of course, some discussion suggested that a one-year analysis would
too short a period of time to assess the real impact....perhaps it should be
18 months or 24.

Limiting the number of assignments to 200 with a first-come, first-served
'wait-list' is another way of more precisely defining the process.  Whether
this is a reasonable number or one higher or lower is on the table for
discussion.


> 
> I am confident that more route table growth will still be produced by
> irresponsible deaggregation than from any other source. I'm 
> sure you can
> agree that a successful multi-homer micro-assignment policy, with a
> clear growth path into the traditional ARIN addressing policies, can
> reduce the number of advertised routes for non-contigious 
> space, due to
> growth assignments from ISPs with conservative allocation policies.
> 
> I further suggest that if the ARIN chooses to assign these blocks only
> within a documented /10 (or similarly-sized chunk of space 
> which can be
> easily added to prefix-lists) and does not carve /24s out of it, ISPs
> can aggressively filter the micro-assignment space; making 
> certain that
> recipients do not cause undue table growth through poor configuration.

The current proposed language speaks of a reserved block from which such
assignments would come.  This block would of course be identified for
operators to use as they see fit.

> 
> --
> Jeff S Wheeler <jsw at five-elements.com>
> 
> P.S. I sure wish the mailing list set a Reply-To: header.
>