Geoff Huston writes:
| If you look away from an address -based hierarchy and define other objects
| as the 'atoms' of a routing system then there may be some benefit. Even
| today, with some 105,000 objects in the routing table (*) there are only
| some 12,000 AS's (*) and 15,500 AS paths selected (*). This tends to
| indicate that grouping addresses not by bit boundaries, but by origin AS's
| has some potential, in my view (*).
Unfortunately, a view of the universe of AS paths is anisotropic.
Your view and mine differ. Moreover, your view has benefited from
filtering done by people with closer views of things far away from
you, who then pass along information in a way reminiscent of the
children's game of "broken telephone". In that game, a complicated
message is whispered from child to child until the last child to
hear the message is asked to try to reconstruct the original message.
The results are often funny. Try it at home.
While some good comes from "broken telephone" (passing along what
you select, rather than what you hear) in the global routing system,
in the form of information hiding, the grim news is that the atoms
are far from indivisible. Some split pretty regularly, with a prefix
heard along one AS path at one moment, and then along another -- shorter
or longer, perhaps -- at another moment. Not to mention the prefixes
which grow (revealing more, often longer AS paths) and shrink (aggregating
which eliminates AS paths).
While it is tempting to consider a message that says, "this AS Path is
invalid for all prefixes", it is not computationally practical to
compress the on-the-wire message (saving space) in favour of
maintaining an association between AS paths and prefixes (requiring
space and/or computation), and dealing with prefixes which share
AS paths but which do not share other attributes (e.g. communities,
or in some implementations, origins).
Moreover, it would be another example of overloading of the AS path,
which is already used as a funny sort of metric as well as an announcement-
loop-prevention mechanism. Using it as a tag to consolidate
reachability information may not seem soooo different from AS-path
filtering (e.g., ignore ^3561 174_), but such filters are static
and local, and really are used to constrain metric-exploration in
the event of a failure (of e.g. ^174_, which we don't want to try
to find behind 3561 when the direct link(s) fail).
| there are other ways to look at the network that also provide
| some tractable level of grouping that could make interdomain routing scale.
That's good to know, but I haven't seen them described that I remember.
Do you have pointers, please?
| Some approaches, like an AS-based approach,
| attempt to bypass an effort to structure the address space as the
| aggregateable element of the routing system, and the corollary is that the
| approach has pretty much the same leverage in a V4 world, a V6 world, or a
| heterogeneous world.
I think you are trying to say that it should be possible to
use a lookup on the IP (whatever v number) address and find
some description of a location in the network. This is
a good idea, and is part of separating location and identity,
but unfortunately you would have to do the lookup at each
hop, or throw away the hop-by-hop model and use "aggregate flows"
along the lines of MPLS LSPs (or some other tunnel/map-and-encap system),
or rewrite the addresses into a form that does not need
to be looked up at subsequent hops (but which can be rewritten
back to the original form at/near the destination), along the lines
of 8+8. Note that I ranked those three options by increasing amount
of difficulty of implementation and operation, from my perspective.
| * Your mileage may vary.
My mileage is kilometreage. :-)
Sean.