[ih] Exterior Gateway Protocol

[Noel Chiappa]

Part II:

    > Jack Haverty

    > Yikes! When we created EGP circa 1982, IIRC we expected maybe a dozen
    > or so ASes would be sufficient to support experimentation with all the
    > research ideas. 64,000 ASes? No way.

    > From: Guy Almes

    > the weaknesses of this binary intra-AS / inter-AS split.
    > I became particularly aware of that weakness when the IETF moved to
    > expand the size of the AS field in BGP from 16 to 32 bits. In 1987, I
    > would not have anticipated 64,000 ASes. Oh well.
    > And then, again, when working with routers that had to usable in
    > backbone networks and thus have a "full" routing table in expensive
    > fast packet-forwarding cards. ... an example was the need for 10s of
    > thousands of inter-AS routes in the forwarding card of the IBM routers
    > used in the T3 version of the NSFnet backbone.

Reading these comments, I think the underlying fundamental problem is the
poor support-for/use-of 'names' (in the formal theory sense of the word/term
'name') for larger connectivity aggregates in the network.

If you have a node A which is dozens of hops away from two areas, X and Y,
which are connectivity neighbours, the chances that there will be any
use/point to being able to distinguish between X and Y _at A_ is slim.
Unfortunately, the system as built doesn't have a mechanism to allow X and Y
to be 'aggregated' into a single named entity a long way away from them.

(I have to say that I had originally assumed that the problem with that lack
of aggretability was going to be computational overhead; but these days we
can throw so much bandwidth and computing power at the path-selection problem
that that doesn't seem to be the most serious issue. Yes, _delays_ cannot be
extinguished with technology - in a gloal network, the speed of light will
always be with us, so stabilization times after a change always been an
issue... However, it seems that the _management_ of that many separate 
named things is the more pressing issue.)

(A further comment is that alternate path issues make more use of names for
larger aggregates problematic. I.e. if company A is connected to ISP's X and
Y, making full use of the alternate paths to A provided by that is
non-trivial; giving A 'connectivity names' associated with A make it harder to
use its link to B, and vie versa. But to avoid a long note on this problem,
I'll leave discussion of how to solve this, except to note that it was thought
about at length, and there do seem to be solutions, _if_ one is willing to
make adjustments to the overall system architecture in terms of what
funcionality is in which subsystems, and particularly in terms of the
information which flows across the subsystem boundaries. This margin is just
big enough to note that a 'DNS lookip' has to return not just a single name,
but a small section of map of what the nearby part of the network looks
like. This will of course be easier to make use of in an MD/ER mapping system,
of course! :-)


This does touch on a related problem, which is the poverty of namespaces (in
particular in IPv6, where we blew our best chance to do something about
this). There's a quote I can't quite fetch out of my memory, about systems
which have too few namespaces; I can't recall if it was something Jerry
Saltzer or Dave Clark said (or maybe me :-).

The irony is that the stated reason why separate namespaces for identity and
location were not included in IPv6 was that people were concerned about the
security of the bindings between the two. However, the same basic issue
exists (and seems to have been solved) for i) the bindings between IPvN
addresses and AS numbers, and ii) the bindings between IPvN addresses and DNS
names. Oh well.

Alas, the proponents of that separation (including me) weren't smart enough to
pick up on the point - and use it in the campaign for their adoption - that
having those separate namespaces would allow one to change one's connection
point (i.e. one's ISP) without having to reconfigure one's IPvN
addresses. (Our heads were too far in the clouds - we thought that if we
pointed out that location and identity were fundamenally very different
things, and having a _single_ naming system which didn't allow them to be
named separately would _inevitably_ be restrictive, that's all that was
needed. Alas....)

Of course, the easy way to avoid that particular problem is to have one's
_own_ addresses - but that just feeds back into the problem we started with.


Well, that's it for today - my few remaining neurons are all worn out!

	Noel