[ppml] Just say *NO* to PI space -- or howto make it less destructive

[Howard, W. Lee]

I've made some changes to this message:
I removed other mailing lists.  I'm not a subscriber.
I changed to plain text formatting.  
I tried to focus on ARIN public policy proposals.

Matthew Petach wrote:

> > dynamicity.  Huston's study indicated that there are folks whose BGP
> > announcements flap (due to TE) intentionally 1000's of times a day.
> BGP flap dampening is already well understood for limiting the impact
> of flapping routes on your CPU, if that's a concern; it has no bearing
> on address allocation policy decisionmaking.  

Dampening works, for the value of "works" which equals "suppressing new
(better?) information about the path to a network," which is often equal
to "misrouting data because a new path was not calculated."  If,
following 
this proposed policy, aggressive dampening becomes commonly required by 
operators to maintain their networks, it might have a bearing on support

for this policy.  

> pool.  The policy cannot allow itself to be shaped by the
least-capable 
> routers, or we'll be chaining ourselves to the past,unable to make
adequate
> forward progress so long as there's any network out there that's still
running
> old hardware that's unwilling to upgrade.
> I agree we need to be reasonable--but please, let's not "dumb down"
the 
> v6 internet just because some people aren't willing to step up to the
plate and
> upgrade their routers when needed. 

For values of "unwilling" approaching "unable."  As the number of
prefixes
approaches infinity, and the beta cycle (or dynamism) approaches zero,
the
CPU required will approach infinity.  Even if you decide to recalculate
routes once a month, memory requirements increase, potentially beyond
what
current or foreseeable routers can handle.  Yes, this is a reductio ad
infinitum argument; the trouble is that there is not common agreement on

what the break point is, or how fast it might approach.

If it takes six months of testing to be confident in a new core router, 
and you replace 5% of your routers every week, and you ignore all other 
maintenance, you could replace your core in a year.  Another year for
distribution and edge.  Any other kinds of devices take another year,
for testing and rollout.   That's assuming you employ as many engineers
as needed, and ignore other work.

I certainly don't mean you have to agree that these issues should be
paramount in policy-making, but I think that before being ignored, it
should be acknowledged that otherwise competent operators potentially
have a serious problem.
	
> Provider independence is here already, period.  It's too late to try
to put 
> the horse back in the barn

I don't understand what you mean here.  Do you mean "policy proposal
2005-1
is in last call and I believe it will be approved"?  The last call part
of
the process exists for a reason; the AC will review comments about
2005-1
before deciding whether to promote the proposal.  Or are you talking 
about other regions, which set their own policies?

> Trying to stop provider independent addressing in IPv6 is simply
another way
> of saying 'IPv6 addressing is broken, let's just stick with IPv4
instead' -- because 
> that's what the practical outcome is.  

Are you asserting that IPv6 is, or is not, "broken"?  Is a PI policy
like 2005-1 intended to "fix" IPv6 or is it simply meeting the original
requirements from the IETF?

> Any addressing scheme that tries to
> deny the need for provider independent addressing is less capable for
> businesses than what they have today in the IPv4 world, and will
therefore 
> not be used.

Interesting assertion.  In the context of 2005-1, which provides
specific
"bridles" to use your metaphor, are you suggesting it should move
forward,
or not?  Whether it is too permissive or too restrictive is another 
interesting question, but doesn't sufficiently inform the process.

> So.  Given that PI allocations are going to happen in IPv6 just as
they have in
> IPv4, 

When you say, "just as they have in IPv4," what do you mean?  Do you
mean,
"any applicant in the first ten years will get one with little
justification,
and anyone after that will have to provide documentation of their need"?
2005-1 isn't identical to IPv4, but uses IPv4 as its basis.

> I *do* agree that stipulating that only the largest possible aggregate
assigned
> to a given AS *should be* announced by the AS is a reasonable addition
to 
> the policy to help encourage aggregation, and prevent stupid routing
mistakes

In this context, do you oppose 2005-1 since it lacks such a
recommendation?
If this is an RFC2119 "should" then can the policy stand without it?

> I don't see why the discussion is dragging out for so long.  This
isn't rocket 
> science.   Let's just nail the policy down, and move on with more
productive
> work.

Is that a statement for or against 2005-1?  

As to your statement about rocket science. . . developping consensus
among
people with opposite perspectives is distinctly difficult.  I've never
tried rocket science, but I know of some nuclear physicists who find 
consensus-building to be challenging.

> Matt
	
Lee