[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PI/metro/geo [Re: The state of IPv6 multihoming development]



On Tue, 29 Oct 2002, J. Noel Chiappa wrote:

>     >> the Internet has to be up to way over 1M "nodes" by now, where "nodes"
>     >> only include[s] routers and networks

>     > Well the IPv4 routing table is only a little over 100k

> Perhaps I should have said "physical routers and networks". In other words,
> I'm counting all the routers and subnets in the entire Internet. That's the
> actual problem the routing has to deal with.

Any particular reason for this?

>     > And so are you (at least to some degree) as you dismiss geographical
>     > aggregation, despite the fact that geography is much structured much
>     > more hierarchical than any aspect of IP and the routing thereof.

> Look, when getting packets from host A to host B - which *inevitably* means
> finding a path to get packets from host A to host B - it's *completely*
> irrelevant if host A is only 3mm from host B, iff the shortest path between
> them *through the actual network* is 117 hops.

Absolutely true. However, if we can build a naming hierarchy in which
most multihomed networks connect to two places that are very close in
the hierarchy, this buys us aggregatability. Obviously, this is never
going to be a long term solution, but it makes for a very good short
term solution as it can work pretty much immediately by just adopting a
new address allocation scheme and some creative BGP filtering.

> Yeah, I dismiss "geographical aggregation" of routing-names for extremely
> large networks. Competent mechanical engineers dismiss perpetual motion
> machines without examining them closely too. There's a very good reason in
> both cases.

It's hardly the same thing, as perpetual motion is something that
doesn't work in theory or practice, no matter which way you slice it.
(Obviously I'm not saying something can't move "forever", but rather
that you can't derive energy from something forever.) You can make
routing work in any way you want, it's just that some ways are cheaper
or faster than others. That's one of the problems with networking: even
if done wrong it can work so people don't even see they're doing it
wrong. But then sometimes this is an advantage as you can still get
things to work even if there is a reason why it can't be done right.

>     > It seems to me that in order to have simple routing, you have to live
>     > with simple forwarding, which has many undesireable properties, such as
>     > a longer path and less redundancy.

> What is "simple" forwarding, or "simple" routing, for that matter? These are
> not terms with any clear meaning that I am aware of. I was talking about
> "scalable" routing, which I carefully defined.

Simple = using little information. Flat routing gives you all the
information you need. Depening on aggregates leads to less optimal
forwarding decisions.

> To really cover this topic is a PhD thesis (and that's for the mono-metric
> case), but in general if you want to be absolutely sure of getting optimal
> routes, you have to get rid of information hiding; i.e. flat route the entire
> network. Needles to say, this doesn't scale well. The whole art in large-scale
> routing is managing that tradeoff between routing efficiency and overhead.

> The K/K paper does show that, given certain reasonable assumptions about
> topology, that the increase in path length due to their information hiding
> scheme grows very small as the network gets larger, although of course their
> whole paper is about mono-metric systems.

It seems to me you have some very clear opinions on how this should
work. Can we expect a draft?