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

[Bill Darte]

> The people who need these small blocks today can't get them from
> ARIN, and are not ARIN members.  They don't get to vote.  Insted,
> they get their addresses from an upstream provider that has direct
> incentives (from charging a fee for address allocations to wanting
> the customer to be in their own non-portable space to make it more
> painful for the customer to leave) to prevent proposals like this
> from succeeding.  They are the ones who get to vote.  It also seems
> to be futher hampered by the fact that only a small group of ISP's
> go to the meeting and raise their voice, often for better or worse
> making it the loudest one by default.
> 
> To address the proposal itself, I'm happy to start with a /22 and
> move to a /24 limit as necessary.  The problem is that the proposal
> wants to tie that to routing table growth.  Since ARIN doesn't
> control the size of the routing table, that should be a non-starter.
> 
History suggests that assignment policy has an impact on route tables and
they have
an impact on routability.

Making changes to the assignment boundary suggests  to me that we should be
cautious.
Introducing policy that is untenable because it is mismatched with filtering
policies is non-productive.

The policy statement does not tie the process to the routing table...it
introduces caution and prudence.

More to the point, it does not put any objective measure on the
> routing table impact -- which due to my beliefs from the previous
> paragraph will mean an increase by so much as 1 route will be used
> to argue against it in the future.  There is a hidden implication
> the routing table size should stay the same, or decrease.  That's
> bogus.  

In defining Objective measurements, there would argument.... 
the AC discussions ran more along the lines of looking for 'significant' if
not catostrophic impacts. 
No one is trying to find trivial fault in order to argue against the policy.
If the AC were clearly against 
this policy, it would have simply been defeated.

It will clearly increase in the short term (as people
> renumber they will have to announce both in many cases), and it
> should have a long term impact to increase the routing table (as
> it becomes easier for people to set up their redundnat networks the
> way they should be set up).  It also doesn't supply a measurement
> interval that's meaningful, during the time proposed we'll still
> be in the initial cut over period, with the double announcements
> and the like.  That's not a good time to judge success or failure.

Well you got pretty near contructive criticism here.... do you have a
timeframe to suggest 
that you think is meaningful or reasonable for judgement?

> 
> It is up to ARIN to give ISP's and large end users the IP space
> they need.  Period.  The measure of success is that the people who
> need IP's can get them with a reasonable amount of effort, in a
> reasonable amount of time.
> 
> The issue of routing table size should not be in any of ARIN's
> proposals, just like issues of which ISP's filter which routes
> should not be in them either.  The routing table size question is
> great in some other forms, and answers to it may influence how
> ARIN's members vote on some proposals, but it has no business being
> in a proposal.

It is not in the proposal.... it is in the process of assessing the
viability of a proposal.

> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>