nanog mailing list archives
Re: Faster 'Net growth rate raises fears about routers
From: Greg Maxwell <gmaxwell () martin fl us>
Date: Tue, 3 Apr 2001 10:52:09 -0400 (EDT)
On Tue, 3 Apr 2001, RJ Atkinson wrote:
At 08:37 03/04/01, Greg Maxwell wrote:Replace the internet with a highly aggregated IPv6 network which uses transport level multihoming and you gain a factor of 1000 improvement at core routers (and 100,000x further from the core where you no longer need to be default-free) and still have the oppturnity for a further 5x by going to a state-of-the-art CPU (providing that your cpu speed reasoning is valid).Precisely which "highly aggregated IPv6 network which uses transport level multihoming" is one talking about ? What's the RFC on this ?
It's possible to 'solve' these problems in the future: Forbid IP level multihoming for IPv6 which crosses aggregation boundaries. I.e. absolutly no multihoming that inflates more then your providers routing tabling, connect to whoever you want, but no AS should emit a route for any other AS without aggregating it into their own space without a special agreement of limited scope (i.e. not globally!)
AFAIK, IPv6 multihoming is identical to IPv4 multihoming, with all the same adverse implications on the default-free routing table -- hence the creation of an IETF MULTI6 WG to try to change this. If I've missed some recent advance in the IETF specifications, please share the details (preferably citing RFC and page number :-) with the rest of us.
IPv6 multihoming *is* the same. What I argue is that: Routers are the wrong place to do multihoming for anything but Tier-1 connectivity. Multihoming belongs in the end node. SCTP (2960) is a transport level protcol which offers what amounts to a superset of TCP. One of it's features is multihoming (2960; section 6.4). With such a protcol it is possible to accomplish all of the realibility benifits of IP multihoming while achieving much greater scalability, flexibility, and performance. We need to stop looking at IP addresses as host-identifyers (thats what DNS is for) and look at them as path-identifyers. I'm not sure of an RFC detailing specifics of an Internet architecture based on these concepts, thats one of the reasons I asked here. I'll troll around more and see if I can find anyone working on such a document and if no one is, I'll create one.
Current thread:
- Re: Faster 'Net growth rate raises fears about routers, (continued)
- Re: Faster 'Net growth rate raises fears about routers Chris Adams (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers mike harrison (Apr 03)
- RE: Faster 'Net growth rate raises fears about routers David Schwartz (Apr 03)
- Message not available
- RE: Faster 'Net growth rate raises fears about routers Paul G. Donner (Apr 02)
- Re: Faster 'Net growth rate raises fears about routers Sheldon Dubrowin (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Bora Akyol (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Scott Francis (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Simon Lyall (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Yakov Rekhter (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Greg Maxwell (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers hardie (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Travis Pugh (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers hardie (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Shawn McMahon (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Jesper Skriver (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers RJ Atkinson (Apr 03)
- Whitelist contacts Mike Batchelor (Apr 03)
- Re: Faster 'Net growth rate raises fears about routers Jesper Skriver (Apr 04)