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).
Why wouldn't rewriting work? The "encapsulation" you show below is little different from the rewrite I propose. First, let's start with something that looks a little more like an IPv6 datagram: [Dst: ::B Src: ::A Prot: ICMP [Type: Echo Req [Data: ...]]] Now, let's look at what the first DFZ router would do to the packet: [RLI: Z Dst: ::B Src: ::A Prot: ICMP [Type: Echo Req [Data: ...]]] or [DST: ::B Src: ::A EXT[RLI: Z] Prot: ICMP [...]]] Then, Upon arrival at the first Router within AS Z, the packet is rewritten again: [Dst: ::B Src ::A Prot: ICMP [Type: Echo Req [Data: ...]]] So... Nobody outside the DFZ needs to change anything, all the checksums and such at hosts that should check them still work, and, even IPSec packet tampering would not detect this since the final packet arrives unchanged. Further, any router along the way that doesn't understand the Extension header doesn't have to really look at it, so, during transition, routing can occur on either RLI or Dst. If you encapsulate, you lose that transitional ability.
Well, let's see what else we can do, that MPLS maybe cannot.
Perhaps become ubiquitous implementation in the DFZ?
If the end user does not determine the RLI themselves, but their ISP does (on edge routers), it looks like this:
Actually, even that isn't necessarily an accurate characterization of what I am suggesting. The packet should not be rewritten until it reaches a DFZ router outside of AS Z. Whether that is within AS Y, or somewhere upstream (possibly more than one level upstream) of AS Y, that's where the initial rewrite should occur ideally. If the first DFZ router doesn't yet know about RLI, however, then, the first RLI aware router in the DFZ prior to reaching AS Z should do the rewrite.
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.
Um... No... You don't want multiple RLIs in the packet. You want the router inserting the RLI to have the ability to chose from multiple RLIs. If you start playing with changing RLI along the way, then, you run into serious difficulty with looping possibilities. By choosing an RLI close to the source that, at the time of selection, had a valid dynamic advertised (BGP) AS Path for reachability, you seriously reduce the likelihood of looping 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.
Look... The first DFZ router selects the location of B to be used in todays world, why should this change?
We have some major points here, and one possible ballbreaker:
+ Prefixes (ESI) have gone from the routing process
That's a GOOD thing.
+ Customers are hidden behind their ISPs
I'm not sure what you mean by that.
+ Packets carry their routing information (instead of ESI info)
No. Under my proposal, packets carry both RLI and ESI information, but, in separate fields.
+ Packets may as well be deeply inspected, if necessary
That already happens, but, it is not necessary under my proposal.
- Edge routers need to be extremely powerful, because they have to determine all the ESI <-> RLI information
Nope. DFZ routers (which already need to be extremely powerful) need to be able to perform lookups for ESI->RLI (one way, btw) mapping. This could be accomplished by a protocol similar to DNS, but, more secure and authenticated. Trading a lookup at first sight of destination prefix, then cache against trying to manage a 32 bit routing table (4 billion routes?) is likely a scalability win. Even if it's just 1 million routes, I think it is a win.
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.
No... This scheme needs DFZ routers to do the lookup. This is going to require significant changes to RFCs for full implementation anyway, and, no, the whole point of my proposal is for routers NOT to have to carry full lookup information, so, it is my intent to modify that requirement.
But at least it differentiates between DFZ (aka Internet Core) routing and edge routing.
I think that is the necessary first step. I also think that the idea of maintaining global knowledge of the entire routing data (as required in Par. 2.1.20) scales about as well as the IEN116 hosts file we all knew and loved (hint, when was the last time you FTPd /etc/hosts from SRI?) Owen -- If it wasn't crypto-signed, it probably didn't come from me.