North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: multi homing pressure
> 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 data. 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: DST RLI: Z DST HOST: B SRC HOST: A 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. Owen -- If it wasn't crypto-signed, it probably didn't come from me.