[arin-ppml] A challenge to the assumption that a big DFZ is aproblem

[David Farmer]

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