|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: multi homing pressure
Because of the number of misconceptions of my idea presented, I'm posting this to the list. Those uninterested, feel free to ignore. Those interested, feel free to follow up with me directly. After this, I will not be continuing this on the list unless there is significant interest from multiple parties. Owen --On October 21, 2005 12:12:22 AM +0200 "Elmar K. Bins" <[email protected]> wrote: [email protected] (Owen DeLong) wrote:Why wouldn't rewriting work? The "encapsulation" you show below is little different from the rewrite I propose.Except that it conserves the original addressing information, which I believe to be important. Look at what I proposed again... My rewrite does NOT modify the original addressing, it ADDs data to the header. First, let's start with something that looks a little more like an IPv6 datagram:You're only talking v6? Why? Anyway, let's follow this through... Because we don't really need to solve this in V4. V4 multihoming is well understood and is unlikely to hit a scaling limit on router capabilities before we hit an end of life on address space. [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: ...]]]You have used special fields in the IP header. Well, that's an elegant way to do it _if_ you have this field. You do not have this in IPv4, and that's what we'll be stuck with for the next couple of years, unfortunately (or not: I can remember v4 addresses much more easily...) Again... Multihoming already works in V4 and there is no real need to solve this in the V4 world. 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.Good point you have here.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.I see a couple of shortcomings to your idea: - it is limited to an IP protocol that carries a RLI header field - you only include one RLI in the packet header You only need one RLI in the packet header. More would actually be bad. Let me 'splain. If you are routing on RLI, then, you need to choose the best path and stick to it. If the packet doesn't make it through that way, that's OK... That's what retransmits are for. If you start rerouting it on the fly, it's likely to loop a lot before dying, but, little else is achieved. Worse, it's likely to loop even if it might have gotten there given one path and only one path chosen as best by the RLI inserting router. I do neither believe that we'll get rid of v4 soon, nor do I think it is a good idea to let the sender decide to which RLI to route the packet. The benefit of multihoming is lost then. No, it is not. Since the RLI inserting router has up to date dynamic information about which RLIs are reachable and at what cost (BGP distance vector data), you have the same overall effect as dynamic routing today. Just instead of trading prefix routes everywhere, you trade AS reachability info everywhere and map prefixes to ASs. 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.Definitely not. Definitely so. If you start playing with changing RLI along the way, then, you run into serious difficulty with looping possibilities.That is not intended. Another way to avoid loops must be found, and I believe the danger is pretty small. The RLIs in the packet are not changed in transit. But of course every new router can choose towards which RLI to send the packet. Luckily, distance on a working path in the Internet generally decreases as you approach a target you have chosen. I do see that there is a danger of looping, but I believe a way to detect that can be found. Why. Why not keep it simple and recognize that when routing changes, some packets get lost during the shuffle. This is the way it is today, and, this wouldn't be any worse with this system. Also, this means that loop detection continues to work essentially the way it does today, and, it doesn't require near as much new code or protocol support as what you propose. 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.Yes, but you lose the benefit of multihoming, because the rewriting edge router may carry outdated information or simply make a "bad" choice. I'd rather have routing intelligence in the core than in the edge. No. You have nearly the same advantage you have today. If the path goes away, then, hopefully by the time of retransmit, the RLI inserting router will have learned that that RLI destination is no longer reachable, and, he will insert a different one in the retransmitted packet. Same as what happens today with the retransmitted packet being sent a different way. > 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?I am not sure why you believe that the firsts DFZ router that is being traversed does the choice today. In paths like (from source to multihomed-target): A B C D T A B E F T Who exactly chooses? IMHO it's AS B that does the selection. And: B is closer to the target, aka the source of the routing information. Its BGP table is more probable to be up-to-date. Right... B is the first DFZ router. A is not likely DFZ since A is not multihomed in your scenario. No need for A to be DFZ if A only talks to B. > + Prefixes (ESI) have gone from the routing process That's a GOOD thing.Yup. Longest match sucks. Nope, but, big routing tables suck. > + Customers are hidden behind their ISPs I'm not sure what you mean by that.Neither customer Z's ESI nor RLI (they don't need one) are visible in the core. Only their ISPs' RLIs are visible. Z's ESI is visible in the core, but, not carried in the routing table. Z does not have an RLI, but, instead uses the RLIs of their provider(s). 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.If I understand the idea correctly, you have to distribute two types of wide-area routing information: One ESI-based and one RLI-based. This is because any DFZ box max or may not be able to RLI-route and/or, if it sees that that's not been done yet, perform the translation. Of course, not every DFZ router needs both those tables, but there are some that do. Initially, yes, there will have to be hybrid table overlap (RLI
global table and prefix-based global table). However, don't
confuse prefix-based global table with ESI map. The ESI map
would be a distributed database (like current A record lookups
in DNS) for Query(ESI)->{RLI, RLI, RLI...} (set of destination
RLIs for given ESI).
In the long run (once this is ubiquitous on core routers), the
global prefix-based table can be abandoned freeing router memory.
Hopefully that would occur before the global table and this table
grew to require significant hardware upgrades, and, would make
significant room for caching ESI->RLI lookups.
Oh, and you do of course have to distribute the mapping info. No, you don't have to distribute it. You _CAN_ provide it for lookup instead. > But at least it differentiates between DFZ (aka Internet Core) > routing and edge routing. > I think that is the necessary first step.Then I do not understand why you want the DFZ routers to be able to translate. I don't know what you mean by translate. 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?)Alright, then please do explain how in your model the system is going to bootstrap itself...I believe, 2.1.20 is there for a very good reason (to save me the hassle and fly around the world pushing DVDs full or initial routing information into my routers)... Well... Since we already have RIRs, I don't see a reason that the top level of the hierarchy for this information couldn't be managed as ANYCAST servers at well known addresses run by the RIRs and/or IANA. All space originates from there anyway, so, it is a natural point of hierarchy. In essence, the router will learn the path to the Root and Top Level RLIs which will be fixed ASNs assigned as part of this protocol deployment. Only the root is truly necessary. I am not sure whether I have fully understood your idea, its implications (I've tried to describe above what I understood, but I'd like to be corrected there); I do see that your idea is based on the assumption that it only has to work with an IP protocol that has special header fields for routing infor, and is not applicable to the Internet as of today (except in a very small part, called "IPv6 world"). And what I do especially not like is the source of the packet predetermining the topological destination, because it only has a limited view. The source of the packet does not determine it. The first DFZ router (often many routers removed from the source) determines it's best path. Just like today when the first DFZ router makes a choice, e.g. between forwarding to 701 or 3561 to get to 10565. Once the packet is handed off to 701, it's not going to come back and go via 3561 in most cases. If 701 loses it's connection downstream towards 10565, it will likely drop the packet. Apart from that, I like it, because it is almost as simple as my own idea, but obviously more thoroughly thought through ;) Thank you. (That's a lot of th'es there). lol Owen Attachment:
pgp00046.pgp
|