I wanted to answer on this, because I thought along the same lines. owen@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@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---