|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: multi homing pressure
[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. > 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... > [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...) > > 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 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. > 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. > 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. > 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. > > 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. > > + Prefixes (ESI) have gone from the routing process > That's a GOOD thing. Yup. Longest match sucks. > > + 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. > 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. Oh, and you do of course have to distribute the mapping info. > > 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 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)... 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. Apart from that, I like it, because it is almost as simple as my own idea, but obviously more thoroughly thought through ;) (That's a lot of th'es there). Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <[email protected]>) --------------------------------------------------------------[ ELMI-RIPE ]---
|