[ppml] 2005-1:Business Need for PI Assignments

[Leo Bicknell]

In a message written on Wed, Apr 27, 2005 at 10:15:20AM -0700, Tony Hain wrote:
> What is absurd is making generalizations about design choices without
> acknowledging the trade-offs.

It's equally absurd that those who designed IPv6 to 10 year old
specifications turn a deaf ear to those who've been operating
networks ever since.  We've learned a lot of things in the last 10
years, and many of us don't think it's inappropriate to incorporate
many of them into the protocol before it's deployed.

> long past time to get over it; auto-configuration requires numbers on the
> order of 60 bits no matter if you choose random numbers or have a central
> registry like the IEEE. In fact the RFID crowd wants to stuff their 96 bit

It's statements like this that have operators tune you out completely.
Autoconfiguration does not require 60 bits.  AppleTalk had
autoconfiguration circa 1991, with a 8 bit host space.  Other
failures of the protocol aside, the numbering side of things worked.
In 8 bits.

This is the primary problem with the operator <-> IETF interaction.
More than a few times the IETF has come out with something saying
"it will never work if you don't do it this way".  The operators
then point to it up and running on the live network, shrug, and the
IETF runs back to figure out why the operators don't believe them.

> thingies into an IPv6 address so one could argue that we were short sighted
> in giving the bits to the routing function and should really be squeezing
> them back down to 32 bits. In any case if routing can't do the job with 64
> bits then it is time to find a new routing system.

One of the lessons operators learned the hard way was that one size
does not fit all.  Some customers can have a /29 and be happy until
the end of time, others need a /6 and still want more.

The other lesson the operators learned was that by the time you
realize the problem it's going to be extremely painful to fix it.

Indeed, the recent presentation at ARIN illustrates the problem.
Potential usage for a /4 in our lifetimes.  Given we had 128 bits to
work with that outcome is a failure.  There's no other way to describe
it.

Let me repeat, because this isn't a proposal to change something.

If the operators do exactly what the IETF told them to do we consume a
/4 in the next 50 years.

Now, by your own statement, if the routing system can't do the job
(consuming a /4 in the next 50 years is a failure to me) then we need
a new routing system.  But this is the IETF's routing system, not
something the operators came up with that's already being shown to
fail.

> Much of the insistence on 'doing it the same as IPv4' is in fact a
> short-sighted approach that explicitly curtails the ability to do new things
> in the application space. Yes we are bad predictors of the future, but we

More addresses do not allow you to "do new things in the application
space".  This is snake oil being sold by the IETF.  I have yet to
see even a single conceptual idea for IPv6 that cannot be done over
IPv4, much less one with working code.  From AppleTalk to IPX to
DECNet to XNS to IP the applications have stayed the same, and have
not cared one iota about address size.

The exact details of how the protocol works may change slightly,
in some cases, but the majority of applications don't care.  One
of the smart things smart people did years ago was to layer things.
The application, up at layer 7, doesn't really care what the layer
3 network does.  Indeed, with a well written application I can run
telnet from my freebsd box over IP, XNS, or AppleTalk, and the
application doesn't even know the difference.  It's all stuffed in
a library.

The only way IPv6 "enables new applications" is via more address
space.  I can't number all the grains of sand in the world today,
so an application that depends on talking to all of them doesn't
work.  More addresses make it work.

> had the foresight to not allocate the entire space up front. We are working
> with 1/8 of the space right now, so if the current policies prove to be
> insufficient over the next 50 years we have the opportunity to start over a
> few more times which should get us well beyond 100 years. As Geoff & David

That's short sighted.  IPv4 is going to last at least 40 years in
the end, probably more like 50.  Given the rate at which we learn
I think it's not unreasonable to expect an order of magnitude
improvement.  That means we should be looking at a 400 to 500 year
timeframe.  The computing industry and our knowledge grow exponentially,
not linearly.

> lifetime issues. The driving issue for a fixed size was to allow
> organizations the freedom to switch providers without having to rebuild
> their entire subnet plan. See

I don't know anyone who redoes thier subnet plans today when they
renumber.  Perhaps that used to occur, but today if someone comes
to me as a provider and says they have 12 subnets and want to
renumber into my space, I give them, imagine this, 12 subnets.

I don't see why the same thing couldn't happen in IPv6.  If someone
had 12 IPv6 subnets and came to me I would give them 12 new subnets.
If any renumbering occurred in the past it was due to gross ineffiency
in their numbering plan.  That's been worked out and we're going
into V6 with our eyes wide open.

The idea that an ISP would say "oh, you had 12 subnets at your old
provider, so we're only going to give you 6" is absurd.  As long
as they don't get in trouble with an RIR an ISP will do whatever
it can to make a customer happy, after all they are paying the
bills.

> This thread is about PI space. One of the things that is not discussed much
> is changing the overall routing model from 'everyone has to know everything'
> to regional knowledge. The routing community is saying they don't want a
> swamp, but at the same time they don't want to change anything about how
> they make routing decisions. The business community is saying that a

Well, I don't know about others.  I'm willing to change, but let me
start with something the IETF needs to learn.

Networks are not regional.
Networks are not regional.
Networks are not regional.
Networks are not regional.
Networks are not regional.
Networks are not regional.
Networks are not regional.

It is possible to have a regional network.  The great firewall of
China and everything behind it is a good example.  However that is
very much the exception and not the rule.  Businesses are actually
worse on this point than ISP's.  The fact of the matter is that
network traffic crosses boarders for reasons that have nothing to
do with geopolitical boundaries, but all about economics.

What's worse is that these parameters change on a daily basis.
@home went from the top of it's game to nothing.  Cogent built a
business out of stitching together a lot of smaller networks.  Asian
countries sent all their bits to the US and back for a long time,
only recently building local exchanges.

The whole reason the Internet works today is that it is adaptable.
Partial routes, full routes, peering here but not there, transit,
partial transit, they all serve a place.  While I don't know what
would be the best way to "upgrade" the routing system, I know some
things that don't work.  The first of them is any expectation that
a power heirachy will stay in place for any length of time is dead
wrong.  We've got 5,000 years of recorded history to prove that.
So building a heirarchial routing system won't work.  Please stop
trying.

> context using strict geographic allocations. ISP's don't like either of
> these because it changes the relationships and perception of roles, but the
> overall result fits well with existing practice in non-IP networks. 

I note that all the other existing networks are being phased out
and moved over IP networks at an ever increasing rate.  Frame, ATM,
Circuits, Telephony, they are all moving over IP packet based
networks.  While some of the other schemes worked well for a while,
in the end they will be replaced by something better.

> driven decisions. Unfortunately there is no trivial technical metric that
> draws a clean line in the sand about who gets to have a routing slot and who
> doesn't. Once you acknowledge there is no technical metric the question
> becomes who's political approach wins.

Who gets a routing slot is not a technical question.  It has an
upper bounds defined by a technical limitation (how many routes can
the system support), but inside that technical limitation it is a
political and economic problem.  Given that it is political and
economic, and that the IETF is full of technical people, I recommend
they stop trying to "solve" that problem.

Maybe the IETF has some grand vision of the future they haven't
been able to articulate.  That said, the operator community is
smart, and from where I sit is looking at IPv6 and laughing.  The
emperor has no clothes.  It's IPv4 with bigger addresses, nothing
more, nothing less.  When you have college educated people who have
15 years experience running networks looking at the proposal and
going "that doesn't make a lot of sense" something is seriously
wrong.

-- 
       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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050427/c71e2a0e/attachment.sig>