Re: Resolving geo discussions

[Brian E Carpenter <brian@hursley.ibm.com>]

Iljitsch van Beijnum wrote:
> 
> On maandag, apr 14, 2003, at 15:38 Europe/Amsterdam, Brian E Carpenter
> wrote:
> 
> >> What exactly do we want to be in this RFC?
> 
> >  think it needs to build on the observation that there is no congruence
> > between network topology and geography to show that we have no way to
> > make
> > geo addresses aggregate in practice. It doesn't need to be that long.
> > But since it's an abstract "why this doesn't work" argument, I think
> > it needs to be separate from any specific technical proposal.
> 
> I disagree. The whole point of this RFC would be to end the discussion.
> That's not going to happen by simply presenting one viewpoint. Either
> it needs to be an overview that lists all the arguments pro and con and

Of course

> possibly drawing some conclusions along the way, 

It needs to, otherwise it can't be used as a reference to
avoid future repeat discussions.

> or if it only presents
> a single point of view 

I think you mean "a clear conclusion" :-)

> it must get into the nitty gritty and not
> suffice with "I know someone in Jakarta who connects to Reykjavik so
> geo aggregation can't work".

Yes, but there is the pesky interaction with economic forces to consider.
That makes it hard to avoid the final conclusion being a judgement.

> 
> Why don't we do some calculations to see how good or bad it can work?
> 
> For instance, even in a worst case scenario when distribution of
> interconnection is completely random, there is always some gain to be
> had: if there are m interconnects, having an aggregate point to one
> interconnect and then filter out all routes that are identical to the
> aggregate must save 1/m-th in the routing table size in all nodes
> except the one sourcing the aggregate.
> 
> If we accept some constraints, we can do much better. For instance, if
> we use a fully switched network (not inconceivable with MPLS) we can
> have one node that sources the aggregate and holds all more specifics,
> all other nodes only need the aggregate and the more specifics learned
> from the local interconnect, which is 1/m-th of all more specifics on
> average.

I don't think that allows for the economic constraints that
mean that certain traffic is only allowed to travel on links
paid for by certain parties. In other words you can theorize
about some ideal mathematical model, but how do you mix in
the economic constraints? One of today's constraints, for example,
is "get rid of the packet as quick as you can, unless it's going
to my own customer" and that has major impact on the BGP4 topology. 
I think this quickly gets into Research Group territory.

> 
> In a routed network, the gains aren't as big as all intermediate nodes
> need to know the more specifics for packets that may need to be routed
> through them, but some quick guestimates land around the 50% mark.
> That's 18 months according to Moore, which doesn't sound like much but
> 1.5 years interest on the "aluminum factory" as one former boss used to
> call it (our new network cost the same as an aluminum factory (and
> probably used as much electricity too)) adds up to a substantial pile
> of change.

But it isn't just Moore's law. It's convergence time. And this is exactly
where we are still waiting for useable output from the Routing
Research Group.

   Brian