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

[Matthew Petach]

On 4/25/06, Howard, W. Lee <Lee.Howard at stanleyassociates.com> wrote:
>
> 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.


Concern was raised about end networks changing routing state too quickly
for modern CPUs to handle; the way we handle that today is to dampen
successive transitions once they reach a certain threshold level.  I see no
reason why the current mechanism in use today in the IPv4 world should
not work just as well on the IPv6 network.

> 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.


The point I was making is that if we limit IP allocation policies
based on hardware upgrade cycles, we shackle ourselves to
the ISP that decides that they should be able to run just fine
with their IGS or AGS+, and therefore no additional prefixes
can be allocated because they're unwilling _or_ unable to
upgrade.

If we start putting limits on what can be assigned due to
concerns about what some providers may be unwilling to
upgrade in their core, are we also going to entertain
proposals to limit IPv4 allocations so that those selfsame
providers won't have to upgrade their IPv4 routers either?

Let's be realistic.  We don't have any limits on how much
IPv4 deaggregation we'll support, we just trust the routers
to scale up to support the growth--why are we attempting
to treat IPv6 differently?  Do we not expect IPv6 to take
over for IPv4 in the forseeable future?

> 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?


I mean 'In the IPv4 internet of today, multihoming is a fact of
life, and is expected by businesses.  If IPv6 is ever intended
to be more than an academic mastubatory exercise, the
policies associated with IPv6 allocations will need to support
a similar or better level of provider independence for businesses
as the existing IPv4 allocation policies.'

To that end, yes, I support 2005-1.  I anticipate it being approved.
If it is not approved, and none of the other possible proposals
for IPv6 multihoming for enterprise networks are approved, I
see no reason to think that IPv6 will ever be used as anything
other than an experimental protocol utilized by small groups
of researchers.

> 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?


IPv6 without provider independent allocations is broken,
and will never be widely adopted.  2005-1 is one possible
suggestion on how to fix it.  I support 2005-1 as a well
thought out means to fix an otherwise broken protocol.

> 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.


Yes.  I have previously stated on other threads, and will
continue to state that 2005-1 should move forward, or if
there is sufficient concern about wording, that one of its
progeny or siblings should move forward; but without
some form of provider independent allocation scheme
for non-ISP multihomed networks included in the IPv6
allocation policy, IPv4 will continue to be the dominant
network platform, and no level of critical mass will be
reached to support widespread IPv6 deployment.

> 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 think 2005-1 is sufficiently similar to the current IPv4 allocation
system for my language to be applicable.

> 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?


No, I don't oppose 2005-1 as it stands.  I'm tossing out an idea
for an addition that might help those who live in fear of route
table expansion feel more comfortable with it.
Strictly speaking, though, even with no changes, no amendments,
no adjustments, I think 2005-1 is more than adequate, and can
be approved as it stands without fear of the internet melting down
due to its adoption.

> 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?


Yes.  I am hoping to see IPv6 become something other than
a theoretical protocol developed as an amusing experiment;
therefore, I support 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.


That's nice.  If we don't come to consensus and move
forward, this rocket is never going to lift off.  And if IPv6
doesn't take off, then we'll see some *real* challenges
when IPv4 space starts getting scarce, and the black
market for v4 space starts to solidify.

You're worried about routing table growth in IPv6?  Imagine
what it'll be like when v4 space runs out in 5-8 years and
suddenly those nice class A aggregates are being sliced
and diced into /22 sized chunks for everyone screaming
for provider independent, routable space.  Suddenly,
supporting PI space in IPv6 won't seem that bad.
The same routing table slots are going to get used,
period; all we're discussing here is whether we set
up the policy such that they can be used for IPv6
routes, or if we force them to be used for IPv4 prefixes.

I'm supporting 2005-1 because I'd prefer to see those
prefixes handled on the IPv6 internet.  It sounds like
you'd prefer to say 'no' to IPv6 PI space, and instead
have your routing slots consumed by IPv4 prefixes
instead, and that's certainly your choice.  I'm just
trying to point out why I think it's a more short-sighted
choice that will end up locking us more tightly into the
IPv4 world, and why I favour the other choice, which is
to support 2005-1 or one of its ilk, and help bring the
IPv6 internet into the current millenium.

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060425/8b31acef/attachment.htm>