multi homing pressure

Thu Oct 20 12:28:52 UTC 2005

I wanted to answer on this, because I thought along the same lines.

owen at delong.com (Owen DeLong) wrote:

> 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.

My idea (somebody had it before, I'm sure, but then, it is
my head that got invaded by it, so here she comes...):

Rewriting would IMHO not work easily, but encapsulation would.
Admittedly, this idea has occurred and lead to MPLS
implementations (which are weak at interconnecting ISPs anyway).

Well, let's see what else we can do, that MPLS maybe cannot.

If the end user does not determine the RLI themselves, but
their ISP does (on edge routers), it looks like this:

A is the customer, Internet access provided by X
B is the customer of Z
Y is an intermediate system

A -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> X
X -> Add envelope -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...]
X -> [RLI: Z [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> Y
Y -> [RLI: Z [something]] -> Z
Z -> Remove envelope -> [Src: a.b.c.d Dst: e.f.g.h Data: ...]
Z -> [Src: a.b.c.d Dst: e.f.g.h Data: ...] -> B

Routing decision is thus made by looking up paths for Z.
Multihoming works the same, but we get multiple RLIs in the packet.

If B is multihomed, I am not in favour of A (or X) selecting the
location of B to be used. I believe the routing system should
be able to determine that, like it's done right now.

We have some major points here, and one possible ballbreaker:

+ Prefixes (ESI) have gone from the routing process
+ Customers are hidden behind their ISPs
+ Packets carry their routing information (instead of ESI info)
+ Packets may as well be deeply inspected, if necessary

- Edge routers need to be extremely powerful, because they
  have to determine all the ESI <-> RLI information

Ballbreaker (shared with Owen's idea):
- This scheme needs the ISPs' edge routers to do the looking
  up, and if we do not find a way to incorporate updating
  the lookup table into part of the routing system, we are
  in violation of Par. 2.1.20 of draft-irtf-routing-reqs-03.txt,
  which is a very sensible requirement IMHO.

I'm not saying this solves all problems, but I did not want this
idea lost in the mists of time; maybe it's a starting point, maybe
it is not (I'm still not through with the draft).

But at least it differentiates between DFZ (aka Internet Core)
routing and edge routing.

Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
                          (PLemken, <bu6o7e$e6v0p$2 at ID-31.news.uni-berlin.de>)

--------------------------------------------------------------[ ELMI-RIPE ]---