North American Network Operators Group

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

Re: And Now for Something Completely Different (was Re: IPv6 news)

  • From: Mikael Abrahamsson
  • Date: Mon Oct 17 06:56:32 2005

On Mon, 17 Oct 2005, Per Heldal wrote:

man, 17,.10.2005 kl. 07.17 +0200, skrev Mikael Abrahamsson:
Both MPLS and any tunneled VPN over IP means the core won't have to know
about all those prefixes (think aggregation of addresses regionally in the
IP case and outer label in the MPLS case).
Hope you don't imply NAT and private addresses like it is usually
associated with VPN in the IPv4 world ;)
No, no NAT and RFC1918 implied, even though it might be part of it.

Then of course I guess the argument can be made to put everything on MPLS
to avoid the core knowing about anything but outer labels.
<flame>MPLS on its own won't solve anything. Although MPLS has its uses,
it smells too much like another desperate attempt from the telco-heads
in the ITU crowd to make a packet-switched network look and behave like
a circuit-switched network.</flame>
Why? The initial argument for MPLS was that it would solve the core problem and put intelligence at the edge. You would have a core that only needed to know about hundreds of nodes instead of 100.000:nds of nodes.

Growth can't be eliminated. In the future network you'll have routers
that may know a lot about their "local region" of the network but have
to rely on nodes that are several hops (even AS-hops) away to pass the
packets to more remote destinations. These trust-relationships have to
Yes, that is what's being proposed. Know your internal nodes, announce single big prefix externally. With ISPs only having a single prefix and no "single customer" prefixes, routing table can be kept low. Redundancy can be solved with for instance shim6.

alternative. Without improved routing protocols, all we can do is to
pray that the development of routing hardware in terms of memory and
processing capability outpaces the growth of the routing table.
We have done this for 15 years or so, what good has it brought us? Yes, TCAM size etc has been fairly good in keeping up with routing table size, but at quite high cost.

Initiatives like shim6 that changes the behaviour of leaf-nodes are only
a supplement and won't replace the need for true multi-homing for
end-sites. Here we have to adapt to business needs, and businesses have
Why? What problem does multihoming with single prefix solve that a fully working shim6 doesn't? What is the argument that the "internet" needs to know about a lot of end-users, instead of the end-user knowing that each end user might have n number of IP addresses and that there are n^2 combinations to send packets?

Convergence time in the real world today is in the minutes, with shim6 it would for the end user be much quicker to "route around" the problem. Shouldn't be any problem to have failover in the subsecond timeframe, even thought that might need some kind of hello mechanism that is suboptimal because it sends traffic not carrying any data.

single provider. Besides, shim6 doesn't eliminate the need for a
mechanism to locate any globally unique address. What if there's
I thought DNS solved that?

suddenly 10M LIR's, or otherwise a trend towards a market with very
small providers each handling only a small number of customers? Who gets
to decide who may peer with whom, or decide which providers will be
denied the ability to build redundant connectivity with multiple
upstreams?
It costs money to maintain a LIR which limits the number of LIRs economically viable in the world.

--
Mikael Abrahamsson email: [email protected]