Subject: RE: [arch-d] It's the routing, people!

From: [email-masked] (Noel Chiappa)
Date: Tue, 14 Nov 2006 13:32:10 -0500 (EST)

> From: "Tony Li" <[email-masked]>

    > Once all of the components of an aggregate share the same next hop,
    > then they can all be replaced by the aggregate.

Actually, there are (admittedly unusual) circumstances in which this doesn't
work (in the sense of "provide the best paths", although the traffic will
still get there). (I really, really liked this algorithm until I discovered
cases it didn't work in! :-)

For instance, start with a large site X made up of pieces X.1 ... X.n. X is
connected to A on one side, and B on the other side of X (i.e. the path from
the X-A connection point to the X-B connection, through X, is long). A and B
(as well as X) are part of a cycle in the topology, a cycle which is longer
than the path A-B via X; let's call the far point of the cycle Q.

Now, applying your algorithm at A will cause A to drop all paths to
individual pieces of X, and pass only a summart route for X on towards Q;
similarly at B. However, traffic arriving at Q for someplace X.i within X
would really like to see data on paths to the individual elements of X, so
they know whether to go the B-way around the cycle leaving Q, or the A-way,
in order to use the optimal entry point into X (i.e. avoid having to traverse
most of X to get to their partucular destination).

The algorithm you mention (share next hop -> replace with aggregate) is a
good heuristic, but alas doesn't always work.

I conjecture that in Destination-Vector there's no optimal local aggregation
algorithm (i.e. one which uses only data at a single node) because of cases
like this, where you need information on the topology far-away, in order to
decide if the information you are about to discard is really useful or not.

    > for proxy aggregation to be effective, all providers at a certain
    > radius must collaborate to proxy aggregate. Otherwise, longer prefixes
    > will pull traffic in non-intuitive directions.

Rather than say "at a certain radius", I'd rather say "along a sensible
aggregation boundary" (i.e. a continuous loop - surface, if the graph is not
expressible in a plane - around the destination).

To me, it's one of the major failings of our current routing architecture
that we have such poor tools to manage what I call "abstraction action
boundaries" (to differentiate them from what I call "abstraction action
boundaries" - i.e. the line drawn around X.1 ... X.n to create an abstraction
X). In fact, do we have any at all? (My apologies for my ignorance about
this, but I'm not very up on the latest BGP stuff, since I've concluded that
Destination-Vector designs are inherenly inferior, and therefore
uninteresting.)

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "Tony Li" <[email-masked]>
Date: Tue, 14 Nov 2006 11:03:34 -0800

> cases it didn't work in! :-)

Noel,

Your example points out again that aggregation breaks optimality.
That's not news.

I think it's a bit over the top to say that it "doesn't work".  You
still have reachability and failover.

> decide if the information you are about to discard is really 

The algorithm is irrelevant.  The issue is the tradeoff between
scalability and optimality.  If we're not prepared to sacrifice some
optimality, then we cannot possibility achieve scalability.

Even in Nimrod, consider the scalability of a core router that does full
optimal routing.  The amount of data necessary is, if I understand local
abstraction control correctly, effectively the full map of the Internet,
down to every individual Ethernet.  I think that you'll agree that this
is untenable.

> Destination-Vector designs are inherenly inferior, and therefore

Thank you for the insult.

Regards,
Tony