North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: multi homing pressure

  • From: Owen DeLong
  • Date: Wed Oct 19 17:29:43 2005

> Always remember: For every customer, their stuff _is_ mission
> critical. So everyone will take the multihoming road if they
> can afford it.
> We can make it more expensive, or we can offer other solutions.
Why should we do either?  Why not fix the way we do routing so
that it's OK for everyone to multihome?

The fundamental problem is that IP addresses are serving more than
one purpose, and, as a result, we have a bunch of unnecessary
baggage on the routing system.

Today, an IP address serves as an End System Identifier
_AND_ as a Routing Location Identifier.  This is sort of
divided in the Network/Host portions, but, the problem
is that it isn't really divided.  The Host portion
of the address is only part of the End System Identifier,
and, the network portion is also necessary in order to
uniquely identify that Host.  There's the rub.

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.

We already have a separate RLI in IP, but, we fail
to use it this way because we are missing:

	The way for A (or X) to look up the Host->RLI

	Routers and routing protocols that think in
	terms of RLI reachability instead of Host
	group (prefix) reachability.

Todays RLI is called an ASN.  Imagine if you could
lookup the Origin-AS(es) for a given prefix through
a query (similar to DNS, some protocol to be
developed) and then, instead of sending to B, you
send a packet addressed  as:


Now, until it reaches ISP Z, nobody needs to look
at anything but DST RLI Z to make a forwarding
decision.  Ideally, I think this should be implemented
so that A sends to default and the first DFZ router
does the lookup and DST RLI insertion, but, it could
be done at the source host.

I realize this requires code modification and protocol
modification to make it work, but, doesn't this solve
the routing table size problem and allow universal
multihoming?  A multihomed site that was not in the
DFZ could simply return multiple RLI records and
the inserting router could choose what it thought was
the best one.


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

Attachment: pgp00039.pgp
Description: PGP signature