Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

  • From: Tony Li
  • Date: Tue Sep 13 17:19:32 2005



> The rules today have not resulted in and overly huge number of
> multihomers.


I suspect that is a matter of perspective.  Even if 10% of all sites are
multihomed, and we continue in the IPv4 multihoming model, then we will
end up with slow exponential growth of the routing table which
eventually overtakes and buries us.


> The IPv6 crowd evangelists on the one hand insist there's
> no need for NAT, while on the other hand provided no solution to
> multihoming, and what's been evolving in the various "fixes" for that
> are less palatable than running a multiport NAT box. The choice is
> simple: live with NAT or provide portable address space. The marketplace
> is not likely, IMO, to accept shim6.


Why not?

I should point out that another perspective on shim6 that should be more
to your liking: in actuallity, shim6 is just another incarnation of NAT.
 It turns each host into a NAT that sits just underneath the transport
layer.

This seems like a fine compromise to running a multiport NAT or (worse)
a distributed multiport NAT.


> End systems should not be making decisions on where packets go beyond
> the local network segment. This has been tried before. It was called
> Token Ring Source Route Bridging. It was a bad idea then, and it's a bad
> idea now to have end stations deal with routing. SRB came into being to
> save the network elements from the burden of keeping track of the
> functioning of the network. Then Ethernet switches came along, spanning
> tree, and so forth.


That would fly in the face of other requests already made here.  I tend
to agree that routing should stay in the routing subsystem and that
those asking for routing features would be most likely to get them if
they asked routing to provide the functionality.


> That's true today. Router memory complement has increased over time. So
> what? Cost of processing power and memory are a tiny fraction of what
> they were when the routing table was in the 20,000 prefix range.


Flatly not true.  Paid for a line card lately?


> Processors in current routers are well below the fastest on the market.
> There's plenty of horsepower headroom. There's plenty of opportunity to
> expand the amount of memory.


Processors are not just for protocol processing.  There are also impacts
 on the costs of forwarding, as each prefix ends up in the high speed
static RAM associated with your forwarding engine.  Such silicon is not
cheap, and while we are currently ahead of the problem, we can easily
let the problem grow without bound and leave ourselves in a very bad spot.

Scaling the routing subsystem is in everyone's best interest.



> That multihoming was not properly addressed as a core goal to solve in
> IPv6 is one of the failings in the whole effort. 


No doubt.  However, the fact of the matter is that we are where we are.


> The shim6 approach is,
> IMO, not going to fly. A multiported NAT box for $179 or less (present
> product in the marketplace) provides a simple solution without the end
> stations being involved. Sure, it uses NAT.


If, in fact, this is the choice of the market, then the issue is solved
and PI space is unnecessary.  A fine outcome in my book.


> Relying on Moore's Law to continue to make
> routing equipment keep up is going to be a necessity.


Moore's Law has not, and does not apply to routers.  Thus, costs are
going up non-trivially.


Tony




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.