RE: multi homing pressure

[Owen DeLong <owen () delong com>]

--On October 20, 2005 2:31:39 PM -0400 "Howard, W. Lee"
<Lee.Howard () stanleyassociates com> wrote:

> > Imagine instead, a world where Routing Location Identifiers
> > are not coupled to End System Identifiers and Interdomain
> > routing (AS-AS routing) occurred based on Routing Location
> > Identifier, and only Intra-AS routing depended on the
> > End System Identifier.
> >
> > For example:
> >
> > Host A connected to ISP X then ISP Y to ISP Z which
> > provides service to Host B.
> >
> > Today, A, X, Y, Z all need to know how to reach B.
> >
> > If we separated the RLI from the ESI, then, the fact
> > that B is reached via Z only has to be available
> > information that can be looked up by A, and, X
> > and Y only need to know how to get to Z.  Only Z
> > needs to know how to reach B.  This allows the
> > amount of data kept by each point along the way
> > to be much smaller.
>
> Interesting.  So Host A needs a lookup mechanism.  If
> I'm ISP X, then I'm providing a lookup server?  You'd
> need to figure out how to provide locally-significant
> lookup results for topologically diverse hosts (A).
No.... ISP X needs to be able to look up a mapping
for Host B->Z or B->{G,H,Q,Z} or such.  Much like
a Name->A record lookup occurs today, but, with a
more authenticated/secure protocol.

Further, since this is a "What ASs are proper termination
points for B?" question, it's not locally significant
to A (or locally significant at all).

> What if X and Y (or Y and Z) connect at multiple points?
> Would you hot-potato or cold-potato?  Can you provide a
> TE knob for that?
Yes... This would be router dependent, but, it is do-able.
Instead of X knowing how to reach prefix Y.B and prefix Y.C
and prefix Y.D, X would know all the ways to reach Y.
TE would involve some mechanism for deciding which portions
of traffic destined to Y use which path, and, in this
case could be based on prefix or on some other method.
Specifying the methods is outside of the scope of this
proposal, but, examples could include: round robbin,
shortest queue, least recently used, prefix hashing,
flow hashing, etc.

> It would be interesting to see a table showing how often
> various routes are looked up.  I suspect that a 
> significant portion of routes are seldom, if ever, used
> by most parts of the network, and therefore don't really
> need to be held and recalculated except on-demand.  But

Exactly, and, which significant portion that is is different
depending on where on the network you are.

> I'm not currently equipped to do that analysis, and it
> would be completely different depending on where you are
> in [your | the] network.
Exactly.  That is why I think that global knowledge doesn't
and can't scale in the long run.  Currently, we are approaching
routing the same way we used to approach name->IP mapping.
(Remember the days when the /etc/hosts file was FTPd from SRI?)
DNS is a much more scalable solution for that problem.
I think that routing can be done on a similar basis.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.

Attachment: _bin
Description: