LWN: Comments on "Re: nfsv4? "

Re: nfsv4?

dlang — Sat, 06 Nov 2010 20:55:21 +0000

BGP consolodates netblocks in it's table, so you don't need the huge amount of data on every router, only on the ones that have many different paths. thus a router that is outgrown in one place can be moved to another place.

I don't consider it 'a bit sad' that routers get outgrown, I consider it a normal fact of life, the Internet grows over time, we know today what size router you would need for the worst possible case, but nobody buys that size router (even the core ISPs don't hit this worst-case). Everyone is buying something that's "good enough for now" and part of doing so is the fact that you may need to upgrade later.

large and medium sized companies are able to get multi-homed addresses. The place I work started doing so 12 years ago when getting 4MB on a router was a very expensive thing to do (IIRC the first BGP routers we got cost >$30K) at the time we were a 30-40 person company

Re: nfsv4?

Lennie — Sat, 06 Nov 2010 19:46:53 +0000

It is just sending changes, that is what BGP does.

It's not so much the size alone, it is the amount of changes that the router-CPU has to crush through per second.

When providers need new hardware just because the routing table has grown to big for their router that is a bit sad, right ?

When we are not giving large and medium size companies a multi-homed address because the routing table can't deal with that, that is also sad.

Re: nfsv4?

dlang — Sat, 06 Nov 2010 18:52:27 +0000

the size of the route tables was a critical problem about 10-15 years ago, but during that time the amount of memory that can be put in a router has increased by a factor of >1000 (we're now talking about gigs of ram instead of megs of ram), so having the routing tables increase by a factor of 10 or so should not be a big problem.

if the problem is that the BGP protocol is sending the entire file for every update, that is easily fixable by adding a mode where a router can send diffs instead of the entire file.

Re: nfsv4?

Lennie — Sat, 06 Nov 2010 10:57:17 +0000

Routing table size and especially growth is definitly a problem for network-hardware manufacturers and internet providers, but it isn't a problem which is talked about with people from outside of that community.

It is actually the reason why IP-address-blocks have such a high price, a way to discourage people from getting their own. The more address-blocks are given out, the larger the routing tables.

Their was hope that IPv6 would bring along a solution to the routing problem. But the one solution for routing-table size that was proposed for IPv6 did not happen.

Here is a graph with the size:

http://bgp.potaroo.net/

You have to remember that any change in routing anywhere in the world could lead to an update being sent to every router in the world. That means that their are a lot of updates. That means on a quiet saturday still many updates per second.

The larger your network and thus more other networks you connect to, the more updates you get. Their are workarounds, but non of them are great.

One proposed solution is called LISP, which is a very confusing name for anyone with some background in programming. :-)

Re: nfsv4?

smurf — Thu, 04 Nov 2010 13:10:22 +0000

> Perhaps I'm missing something

Well, the vehemence of Theo's reaction and the real-world gravity of whatever problem he's reacting to have historically been shown to correlate by well, not a whole lot. On average.

Worse, sometimes the correlation is negative.

In this case, anything that can't do multicast is not useable for IPv6 anyway. For instance, router advertisements won't be visible.
But if you can't get a route to the outside world, you can just use RFC1918 addresses and be done with it.

Re: nfsv4?

dwmw2 — Thu, 04 Nov 2010 02:36:31 +0000

I'm not sure I recognise any of those three as being real problems.

The neighbour discovery system means that you need working multicast in your Ethernet drivers, which has occasionally been an issue, but not very often.

Global routing works fine. Theo may mean portability, in the sense of Mobile IP which is better defined in IPv6 in Legacy IP and won't always suffer the triangle routing problem, but isn't widely implemented yet. But it's still an improvement on IPv4.

SIOCGIFCONFIG was deprecated anyway around here, and I can't imagine why anyone would care about struct sockaddr being a power of 2 in size. Hell, if it matters that much to you, you can make struct sockaddr_storage however large you like.

Perhaps I'm missing something