> From: "Louis A. Mamakos" <louie(_at_)TransSys(_dot_)COM>
> The Internet architecture never gave the end system some mechanism to
> help it make this binding decision when trying to communicate with
> non-local peers.
> ...
> There was no protocol to ask the network "which of address should I
> use to talk to this remote end system?"
Ah, memory lane! I proposed a related mechanism - chosing the address to
use for a *destination* host with multiple addresses - at IETF #1! It used
an ICMP message with the list of potential destination addresses, sent to
any first-hop router.
Actually, I proposed adding three different mechanisms: the one to select
the best destination address, one to find routers (which we now have), and
one to debug routes (I wasn't clever enough to figure out the TTL trick
used by trace-route).
There is a reason why we don't have the third - and it's related to why
doing it for the case of multiple source addresses is something we don't
have either.
It seems easy enough to have such a mechanism for destination addresses in
a mono-metric routing architecture - you just send the list of potential
destination addresses to a first-hop router, which just says "which
destination is closer". Since by definition such a list can be ordered by
the metric, it's a no-brainer, right?
Wrong.
If you have multiple first-hop routers, depending on which of your
first-hop routers you pick, you may get back a different answer. You really
have to ask each of your potential first-hop routers "how far is it to
whichever of these destinations is the closest", and then compare the
answers you get back to find the shortest one.
However, if two routers are connected to two different AS's, that means in
that case that the answers you get back (particularly back in the EGP
days), are probably not directly comparable. Since most routers running BGP
now use a fairly complex set of rules (operating on fairly complex route
"descriptions") to select which route to prefer, it's not trivial to
compare what each router thinks is the "best".
As a theoretical aside, it gets even harder in any multi-metric routing
architecture (which I expect the Internet is not too far from having - it's
already appearing locally with things like QOSPF). I will leave why as an
exercise to the reader.
Selecting which *source* address to use to get to a given destination
address, in a host which has multiple real interfaces, is also potentially
tricky. You basically have to talk to the first-hop router on *each*
interface, give them the destination, and say "how far are you from that"?
Then you collate the answers you get back, and order them.
Again, the problem is that if the two interfaces are connected to two
different AS's, the answers you get back are likely not directly
comparable.
You can't say to one router "here are my addresses and the destination,
which is best", because that router doesn't know that the world looks like
from the other potential router.
So in many cases you wind up having to basically flip a coin.
Whether you'd get enough benefit from what's a fairly complex mechanism
(talk to multiple boxes, collate the responses you get back from them), one
which isn't always guaranteed to work, to make it worth it is probably the
reason this has never been done.
If we had a more unified routing architecture, this would be easier, but we
don't.
Noel