[arin-ppml] A challenge to the assumption that a big DFZ is aproblem
David Farmer
farmer at umn.edu
Tue Dec 15 19:53:50 EST 2009
Ted Mittelstaedt wrote:
....
> What I'm really asking is, CAN a
> router be built that's fast enough for a much larger DFZ in the core?
> I'm not asking if such a beast would be "too expensive", I'm not asking
> if such a beast exists today, I'm asking if it's theoretically
> impossible to build such a device - in the same sense that it would be
> impossible to build a square balloon out of thin, flexible rubber.
>
> Ted
Theoretically, yes it could. But ARIN policy shouldn't be based solely
on what is theoretically possible, anymore than it should be base solely
on what we did or was possible three years ago. It should be heavily
based on what is practical now and in the next few years, say 2 to 3
years for discussion, with a little bit of influence from the
theoretical and the past.
So I agree ARIN policy should be forward looking, but at the same time
we can't get to far ahead of what is operationally possible at this
moment today.
Think of it this way, it takes 6 month to a year to get policy through
the ARIN process. Then depending on the policy it could easily take a
year or two for that policy to impact a significant number of resource
holders. So depending on the policy 2 to 3 years, maybe up to 5 years
in some limited cases, seems like a reasonable policy horizon to be
working with.
That said lets look at the theoretical a little, even if it is mostly
out of scope for ARIN policy for now;
As has been said, ~1M routes is fairly common today, the equipment has
been available for 5 years or more. But, there is still more than a
little bit of stuff that is limited to ~250K, this is being phased out
or moved into non-DFZ uses by most people. And, ~3M route solutions are
just starting to become available but are not at all common yet, but
over the next few years I expect they will become more and more common.
There are software techniques that could shrink the effective size of
the DFZ, some were talked about at the last NANOG/ARIN meeting, but
these are not going the magically reduce the DFZ by a factor of 100 or
anything like that. There are different network architectures along
with those software changes to BGP that can limit the number of routers
that need a full DFZ in there forwarding plane. In this case More's Law
for regular CPU and memory could play a much bigger role. But these
changes are not purely technical, economics in the form of what the
market finds acceptable will play a big role in what will truly happens.
There are two markets at work here, enterprise and lower tier
providers purchasing transport services from backbone providers, and
what technologies and architectures they find acceptable. Then the
backbone providers purchasing core routers from equipment manufactures,
and technologies and architectures they believe their customers will
find acceptable.
So if ~3M route forwarding hardware, along with these software
techniques, start to become common place in the next 2 or 3 years then a
~10M route DFZ might be reasonable in 3 to 5 years, but this is highly
speculative. Further, I don't see ~100M route DFZ being a reasonable
option in any planning horizon that I would be talking about now. Also
remember that the speeds and feeds don't stand still while all of this
is happening we are talking about 40G and 100G interfaces becoming
common place in the backbone while all of this is happening too.
So it is not hard to imagine this being an order N cubed problem,
O(N^3), from a silicon complexity point of view.
Personally, I believe long term the game changer is going to be IPv6 and
getting a working solution that splits the identifier and locator, in a
why this is what NAT does today for IPv4, just not very well. If this
can happen then high performance general purpose CPUs at the boundary of
the enterprise or user edge network and the provider network could
really make a difference and the kind of changes you are asking about
could maybe happen. This kind of solution is only in the testbed stage
right now, go look at LISP. And, there are lots of people highly
skeptical of this being able to work at Internet scale. So other than
resources for experimentation this is not ready for ARIN policy work by
any means.
Thats enough for now!
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
More information about the ARIN-PPML
mailing list