Robin, > -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Monday, January 26, 2009 11:18 PM > To: RRG > Cc: [email protected]; [email protected]; > [email protected]; Dino Farinacci > Subject: Re: [Int-area] [rrg] Please respond: Questions from > the IESG as towhether a WG forming BOF is necessary for LISP > > Short version: Responding to Dino's reply to my critiques of LISP. > > The LISP team should do detailed critiques of APT > and Ivip as part of convincing IETF folks of the > merits of LISP-ALT. > > Will it be possible to do firmware upgrades so all > DFZ routers ca. 2014 will handle packets with > modified IPv4 and IPv6 headers, to forward the > packets the ISP network of the ETR, without > encapsulation, its overheads and PMTUD problems? > > If so, then maybe we could go straight to this > approach and forget about encapsulation and all > its complexities. > > > Hi Dino, > > Thanks for your reply: > > > Sorry for the long email, > > We are attempting to re-engineer one of humanity's most excellent and > important communication networks. Long detailed messages are often > appropriate. > > > >> LISP has too many fundamental problems to be considered a > >> potentially practical solution. Some of these problems require > > > > LISP is not perfect and still evolving but let me point out that > > every design has fundamental problems. At this scale, it's very > > hard to be perfect Robin. And as Noel has stated so many times, the > > hard decisions must be made to incrementally deploy this. So things > > might not look pretty on the surface, but jeez, you got to do what > > you got to do. Else, this will all be academic. > > I wasn't suggesting a proposal should be perfect. I pointed out > problems which I consider to be fundamental - not "on the surface". > Some can be fixed by adding new design elements, but I think the > others are only fixable by radically altering the current design. > > I stand corrected about LISP's approach to PMTUD - the latest draft > does include an outline of a workable solution.
I don't know if you were fishing for a response, but the stateful solution outlined in the latest LISP draft still has problems. It should also be mentioned that the approach (drop first; return PTBs for subsequent) is not new and has been proposed many times over the years. The approach in the current LISP draft still relies on ICMPs coming from anonymous network middleboxes (which Dino himself has said that we cannot depend on), and provides insufficient means for authenticating any ICMPs that may come. For example, even if the ICMPs were delivered, and even if they included the LISP nonce, it would be impractical for the ITR to cache enough nonces of enough recently-sent packets especially at high data rates. So, the only option is to ignore ICMPs (leads to black holes) or honor ICMPs (leads to denial of large packet service). I have said this before, but AFAICT DF=1 is busted. Fred [email protected] > > We really want to solve this problem, sincerely. This is not lip > > service, we are not just writing papers, we want to rev the > > Internet, this is serious. > > I have always known you and the other LISP folks really care for the > Net and are working hard to devise the best possible improvements. > > Despite it only having had broad-based commercial, political and > inter-personal impact in the last 15 years, the Internet is a > momentous development in human relations. We all want to see changes > which will enable it to remain technically viable - and hopefully > elegant - for the long-term future. > > However, I think you jumped straight into some seemingly attractive > approaches which turn out to have problems I consider to be serious. > > It seems that you and the APT folks thought for a few moments about a > real-time mapping system and figured it was out of the question. I > think it is not at all out of the question - and when you have > real-time mapping distribution, you can do some elegant and valuable > things: > > 1 - Separate out reachability testing and ETR choice mechanisms and > let (actually require) the end-user networks to do it themselves > - or pay someone else to do it for them. > > 2 - Enable the end-user networks to do real-time incoming TE control. > > 3 - Send the mapping update stream to local query servers, so there > is reliable and very fast responses to mapping requests - and > therefore no need to delay or drop initial packets. > > 4 - Charge a small fee per update to pay for most of the mapping > distribution system. > > 5 - Provide much better support for the TTR approach to mobility: > > http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf > > I think the ALT system is a lot niftier than CONS, but still, you are > delaying initial packets (APT and Ivip are not), forcing every ITR to > do its own reachability testing and monolithically integrating those > testing and ETR choice mechanisms into the core-edge separation > scheme itself. > > I don't think we should be rushed into thinking we can't possibly > have local full-database query servers in ISPs and larger end-user > networks, or that it is impossible to push the mapping to them in a > few seconds (real-time). One advantage of the real-time approach > over LISP-ALT, APT's approach or the TRRP DNS-like global query > server approach is that it is streamlined and includes multiple > mapping changes (dozens or perhaps a hundred IPv4 mapping changes) in > a single packet. > > > > I want to address each of your 7 points below. I have cc'ed the > > [email protected] mailing list so the folks who want to focus > on details of > > LISP can see this thread. > > OK, we are also transmitting to [email protected] and > [email protected] . > > > >> 1 - Delays in delivering initial packets in a flow. This is either > >> due to sending the packets along the ALT network (which takes > >> time and involves sending substantial volumes of data packets > >> over the ALT network, rather than just mapping requests) or to > >> sending mapping requests only, and waiting for the ITR to get a > >> response before it attempts to send traffic packets. > > > > We have a memory/bandwidth tradeoff. So we have to make a > hard design > > call. I'd rather have mappings cached and timed out so they can be > > updated when they need to then to hold all the possible > mappings for the > > Internet in an ITR. > > > > There is no such thing of a free lunch. You either store > all possible > > mappings or you fetch them when you need them. > > That is the dichotomy between LISP-CONS/ALT and LISP-NERD. However > there is another approach (APT and Ivip): full push to local query > servers. > > RAM and hard drive space is very cheap. The query servers don't need > to be Cisco-style routers. They can be COTS or high-reliability > rack-mount PCs - with gigabytes of RAM and terabytes of hard disk > storage. > > In Ivip, IPv4 mapping consists of 12 bytes: > > Start of the micronet (32 bits) > Length of the micronet (32 bits, but typically 16 or less) > ETR address (32 bits) > > So if you have a COTS server with 16GB of RAM (this will no-doubt be > the common amount of RAM in PCs by the time a core-edge separation > scheme is deployed) then you can easily dedicate 12GB for mapping > information. That is a billion micronets (more or less, depending on > the storage format), which will do the trick for many years to come. > (IPv6 mapping is more bloated, but there is a longer time-frame for > implementing millions or billions of IPv6 micronets - time for RAM to > get cheaper still). > > I think you - and the designers of APT and TRRP - have been somewhat > captive to established ways of thinking about how to solve a > "routing" problem: with more "routing" style structures. This means > more routers, more messages and replies zipping around the world etc. > It doesn't have to be like this. > > I need to do more work on the fast-push system of Ivip - but you are > welcome to critique it in its current form: > > http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 > > If your design choice with LISP is optimal, or the only one you think > is available, then you should be able to point out why it is > impractical or undesirable to use an approach such as Ivip's: > real-time fast push on a global basis to local query servers, with > local pull from there to ITRs, followed by pushed updates from the > query server to the ITRs if a micronet's mapping changes within the > caching time of the mapping reply. > > Likewise, you presumably have a critique about the practicality or > desirability of APT: slow push to local query servers (Default > Mappers) in each ISP, local pull from ITRs querying the Default > Mappers, local push of mapping updates from DMs to those ITRs which > need it (I think) and (again, my recollection) the Default Mappers, > rather than the ITRs, doing reachability testing and choosing which > ITR address an ITR uses. > > The Net will soon be delivering gigabytes of video data to homes, in > near-real-time, for a few dollars. Generally, a packet can be sent > from any host to any other host in 0.2 seconds or less. > > In this scenario, why do you think global push to local query servers > - including high-speed, real-time push - is impractical or > undesirable? > > > >> According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > >> & 11 the experimental LISP ALT network's ITRs drop initial > >> packets and send brief map request messages. Even if we think > >> this delay doesn't matter, I am sure enough potential adopters > >> would - and therefore make it difficult or impossible > for LISP or > >> any other such solution to be widely enough adopted to solve the > >> routing scaling problem. > > > > Then why was/is ARP deployed in a 10^4 host-based bridged > network with > > basically the same properties. First packet loss is not > persistent when > > you look at all the traffic that originates from a source site to > > another destination site. > > This doesn't apply to small end-user networks. If there are to be > hundreds of millions of these sites, meaning hundreds of millions of > EIDs or (Ivip) micronets - then these are mainly going to be small > "sites", such as home offices, or more likely mobile devices. The > initial packet delay will directly impact usability, since there may > only be one human user at each such "site". > > If many small "sites" use a common ITRs in a large ISP, there will be > less trouble with this, since it will be more common for one site to > generate a packet to some EID/micronet which the ITR has mapping > from, due to another "site" sending a packet there too. However, the > frequent delay of initial packets (actually, it seems you are > planning to drop all initial packets) will still be a problem. > > If LISP is not meant to scale to a hundred million or a billion or > whatever "sites", then by whatever same smaller target number of > EIDs, micronets or whatever, this would make alternative approaches > such as Ivip or APT even more immune from whatever scalability > critiques you might make of them. > > > The host vendors are probably thinking, if we do LISP in > the host, you > > could wait to send your TCP SYN before the mapping is available. > > On IPv4, with most human-used hosts behind NAT, you can't put a LISP > ITR in the sending host, because the map reply won't come back to the > host. > > In a scenario in which LISP is widely - ubiquitously - deployed, many > DNS servers are going to be on EID space. This means the ITR will > often need to do a mapping lookup before it can send a DNS request. > The sending host will be on EID space and so the DNS server's ITR > will need to do a mapping lookup too before it can send the return > packet. This will suck to a high degree in the current arrangement > where the DNS server sends a single packet. The ITR of the DNS > server will drop that packet and send a mapping request for the > original sending host's EID. Then, after a while, the sending host > will realise it got no DNS response. If it sends the same request to > the same DNS server, it will get a response back quickly, since now, > the DNS server's ITR has the sending host's mapping in its cache. > > But what if the sending hosts does it it might reasonably do: send > the request to a different DNS server? Then the same pattern as > above occurs again. > > > > Guess > > what, you don't send that TCP SYN before you get the DNS > Reply. ;-) I > > wonder why? Well I'll spell it out. If a host needs an > address to make > > the connection, we can say it also needs a locator to make > a connection. > > So you are proposing that every DNS reply also include full LISP > mapping for every one or more EIDs of the one or more IP addresses > returned? I doubt if that will always fit in one packet. > > > The design choice of LISP *is to just change software in > CPE devices* to > > get the feature of decoupling rather than changing all the > hosts at a > > site. > > OK . . . LISP mutates again! I have been following LISP intently > since about March 2007 and I don't recall any mention of changes to > hosts or to CPE - by which I guess you mean DSL, cable and fibre > router/firewalls. > > Do you propose putting the ITR function in the DSL > modem-router-firewall? That is not such a bad idea, since it has > (presumably) a public IP address and so can receive the map reply > message from the globally distant query server (in the case of LISP, > the mapping queries are typically answered by the destination > end-user network's ETR). > > Ivip has the option for putting ITR functions in a sending host which > has a public address, or in a device such as a > DSL-modem-router-firewall. It would not be out of the question to > put an ITR function in the sending host behind NAT, but then the > sending host would need to build a persistent tunnel through NAT to > the one or more local query servers - in order to receive mapping > updates from those query servers. That is possible, but not part of > the current plan. > > > That's a huge deployment advantage. > > I don't see any advantage in terms of deployment, since it involves > changes to more and more equipment, including customer equipment. > Ivip's ITFH (ITR Function in Host) is optional - if it is cheap and > convenient to do this for servers or devices like DSL-routers, then > by all means do so. It only makes sense when the device is > well-connected. It would be a bad idea to put an ITR function in a > host or router at the edge of the network connected by a slow, > expensive or unreliable link such as a wireless link. > > > So these CPE devices get packets before they have mappings. > > OK - for instance, the ITR function is in a DSL-modem-router-firewall > device. > > > We don't even want to consider a host > > to CPE router signaling protocol and all it's complexities > to solve this > > and to keep the architecture pure, we don't want to snoop > on DNS, SIP, > > or any other protocol that can give us a hint on where the > host is about > > to send a packet. > > I agree. > > > > So the cost is *either* first packet loss or sending the > packet on the > > ALT using it as a request for a mapping. > > These are not the only choices. > > Another choice is to using a different architecture with local query > servers - as does APT and Ivip. I think you have approached this > without thinking widely enough about the alternative ways of doing > things which are different from traditional approaches like routers > and DNS. > > If you send the packet on the ALT network (for the purposes of > delivering it to the ETR ASAP, as well as to elicit a mapping reply > from that ETR) then you are going to greatly increase the volume of > traffic on the ALT network. Many of these packets will be short - > but what if someone sends a 1500 or 9000 byte packet? > > If you don't send the packet via the ALT network, then you either > drop it, or delay it until the mapping arrives. But that could be > longer than 0.5 or 1.0 seconds, considering how many ALT routers the > mapping request packet needs to go through to get to the ETR, how > these ALT routers could be all over the world, and how the ETR could > be on the other side of the world anyway. This is a lot slower than > the current system which usually takes 0.2 seconds or less to > delivers packet anywhere in the world. (The round trip from > Melbourne Australia to Latvia is about 400ms.) > > > >> 2 - LISP-ALT's long-path problem > >> http://psg.com/lists/rrg/2008/msg01676.html > >> http://www.antd.nist.gov/~ksriram/strong_aggregation.png > >> > >> [Fix? Another fundamental problem in the architecture. Could > >> be partially solved by more meshiness, but that would greatly > >> increase the complexity of the network and so raise more > >> scaling problems.] > > > > Well this I believe is a duplicate of 1 above. So it's not really > > *another* problem. > > In terms of delaying packets, I agree. Do you agree the long-path > critique is valid? > > The long path involves more than delay. It involves traffic flowing > (often) all around the world due to the fact that the highly > aggregated structure of the ALT network will frequently result in > different levels of the ALT hierarchy of routers being distributed > all around the globe, since the physical location of organisations > who are responsible for various parts of the address space does not > correlate very strongly with geography or the topology of the Net. > > This is a traffic burden, particularly if you are sending initial > packets on the ALT network for ASAP delivery to the ETR, rather than > just map requests. (However, Ivip involves pumping mapping > information around the globe anyway, and if your ALT network only > handles requests, not traffic packets, the actual volume of traffic > should not be too much of a problem.) > > Each operator of each ALT router needs to have a commercial > relationship with those other ALT routers they connect with. > Otherwise, why would they accept the traffic? I haven't seen any > business plan for the commercial relationships which pay for the ALT > routers and their traffic. > > Ivip's fast push system involves a charge per update, which will > finance the construction and running costs of most of the fast-push > system, which will be run collectively by the various RUAS (Root > Update Authorisation System) companies, each of which generates the > real-time mapping changes for multiple MABs (Mapped Address Blocks - > BGP-advertised prefixes encompassing thousands, or hundreds of > thousands of micronets). > > > >> 3 - Problems creating a highly aggregated ALT network in order to > >> speed the flow of packets up and down the hierarchy, while also > >> making the network robust against the failure of its routers and > >> tunnels. This has not been discussed much on the RRG, but it is > >> an obvious problem. > > > > If we can do this with BGP, which we have decades of > existence proof why > > can't we do this with a tunnel topology 1) where a tunnel > can be rehomed > > much quicker and easily than physical links and boxes we > have to do with > > today, allowing aggregation to occur at the edges of the > ALT network, > > and 2) these tunnels stay up because there is robust > connectivity below > > the tunnel level to keep them up, hence there will be less > route-flaps > > for EID-prefixes. > > I don't recall any prior mention of rapidly reconstructing tunnels to > maintain the ALT topology. I agree with your point 2 that the > tunnels will be reasonably robust due to relying on existing > connectivity which is generally ensured by BGP. > > But what happens when two ALT routers loose their connection for a > moment? Do they try to set up one or more tunnels with the same role > in the ALT topology as the one which just died? This is your point > 1. It could get messy, but I guess it could be done, by using other > interfaces which, for some reason (I guess) have connectivity while > the interfaces used for the first tunnel don't. But that is the sort > of situation which I think BGP would naturally resolve, generally in > a few seconds or less. > > My concern is more about what happens if an ALT router dies. In > your highly aggregated hierarchy, a mid-level ALT router is a single > point of failure for sending mapping requests to all the ETRs in the > branch below this router and from all the ITRs in that branch to ETRs > outside the branch. > > When a mid-level router dies, you can't just re-establish tunnels - > it is dead. The routers below need to establish tunnels to another > ALT router which can take the dead one's place. > > How is this going to work? Say one lower-level router finds it can't > reach the mid-level router in question, it is going to assume the > mid-level router is dead. So the lower-level router tries to set up > a tunnel to the one or more backups. If it does so, either this > won't work at all, or the next level up will have to adapt to the > original mid-level router having routes for most of its patch of the > ALT address space, but with the backup having the router for the > smaller patch of space handled by the lower-level router which just > made a tunnel to the backup mid-level router. > > > I think it's the complete opposite of what you claim. I > think BGP will > > be more stable and scalable then the underlying BGP. > > I assume you mean that the BGP of the ALT network, operating over > tunnels, will be more stable than the BGP of the Internet. This is > your point 2, and I largely agree. But what if an ALT router dies? > > > Plus, what we > > propose for the use-case of BGP uses quite a few features > of it. Recall > > this is eBGP over GRE. > > > > We have an infrastructure where we can 1) ping to see > liveness of nodes > > on the ALT. We have traceroute to determine the path a > Map-Request takes > > on the ALT. We can ping/traceroute "underneath" so we can see the > > diameter of the tunnel. > > I don't understand "diameter" in this context. > > > Not only do we have a solution but we use > > existing rudimentary tools for management. > > > > And the address allocation hierarchy can map this logical > ALT topology. > > And if the Registries are involved in managing part of this > ALT network > > (which we hope and think they will), we can keep this consistent > > relationship. > > > > Do you realize the goodness of this? It's huge Robin. > > I am sure you can make the ALT network reasonably robust, at a cost > of complexity and with a loss of the original attractive design goal: > a very high degree of aggregation. > > I imagine you can reduce the excessively long paths by collapsing the > network as much as possible to reduce the number of levels a packet > typically has to ascend and descend. This will reduce the > "long-path" problem significantly. But then, each participating > mid-level ALT router (there are fewer of them) covers a larger part > of the address space, and my concerns above become more acute, when > such a router fails or becomes really unreachable. > > I imagine you can reduce the geographical scatter component of the > long-path problem by centralizing the ALT routers geographically. > However, that privileges some operators and creates costs and > difficulties for others. > > I still think it is fundamentally wrong to have a global query server > network for any system like this, where waiting for mapping replies > involves delaying or dropping traffic packets. > > I think a much better solution is to push the mapping to local query > servers in each ISP (APT and Ivip) - and into any larger end-user > networks which want to run their own local query servers (Ivip) so > their ITRs can get marginally faster, more reliable, responses than > by using the query servers of their ISPs. > > > > There's more too, you then throw SIDR in the mix and we > have secured the > > ALT, we have secured mappings, we created a PKI for routing use. In > > fact, the first SIDR deployment could happen on the ALT to be > > verified/experimented before it goes on the underlying BGP. > > PKI is a great idea, but I think most people believe it is highly > desirable to find solutions which do not require it. > > > > And note, that the infrastructure will/does carry exactly 2 > > address-families. So we can do 6-to-6-over-4 with this > approach. That > > means we can get two site to be *IPv6-only* and be able to > talk to each > > other. > > > > If you are a IPv6-only site now or a dual-stack site, you > could talk to > > the new IPv6 Google services. I think this is a pretty huge feature. > > > > This is clean and architecturally pure, no double NATs, no > CGNS, and no > > applications breaking. > > Are you discussing just the mapping queries going over the ALT > network? Or are you discussing the use of LISP to enable, for > instance, two IPv6 sites to communicate via the IPv4 Internet, while > one or both sites has no native IPv6 connectivity? A concrete > example would help. > > > >> 4 - LISP-ALT's Aggregation implies provider dependence. > >> This is Christian Vogt's critique: > >> http://psg.com/lists/rrg/2008/msg00259.html > > > > Not true. Aggregation here is for the EID-prefix. Service > providers do > > not carry EID-prefixes in their cores so you don't depend > on them. The > > decoupling of the address creates this. > > Christian's critique is not that an end-user network which has > (permanently, by some arrangement) a slice of EID space is bound to > its current ISP (the one it uses for connectivity). > > The critique is on this potentially erroneous basis: that the > end-user network is bound to maintaining connectivity (via a tunnel) > to the ALT router which handles this part of the EID space. It needs > to do this so mapping queries for its EID space will get to its ETR. > > The potentially faulty aspect of this is the assumption that the > end-user network runs its own ETR. > > But if its one or more ISPs run the ETR this end-user network uses, > then the end-user network still depends on those ETRs having tunnels > to potentially distant ALT router for its section of the EID space. > > I don't know if anyone has considered the scaling problems of a busy > ETR maintaining tunnels to about as many ALT routers as the end-user > networks it handles packets for. > > The ALT router for this section of the EID space will, I assume, be > located at some ISP somewhere, or some other commercial organisation > which rents out the EID space to this end-user network. > > Maybe that organisation is an RIR. But when this scales to tens or > hundreds of millions of end-user networks (I assume this is a goal of > LISP - it is of Ivip) I doubt if RIRs will want to be dealing with a > hundred million end-user networks directly, either for address > assignment or for tunnels to receive mapping requests to their ETRs > from the ALT network. > > For these large scaling arrangements, there will need to be > potentially multiple levels of address splitting. Ivip allows for > this, and for multiple levels of companies providing interfaces to > accept mapping changes from end-user networks (or more likely from > reachability testing companies they hire) and funnelling them to the > limited number of RUAS organisations which run the fast-push mapping > distribution system. > > Any way you do this core-edge separation business - LISP, APT, Ivip > or TRRP - if the end-user network gets a patch of stable address > space to call their own, year after year, then that network is going > to depend on some company or other organisation for that space. The > end-user network will need to pay for this, and depend on the > organisation to handle mapping. > > In the case of LISP-ALT, the organisation needs to run (or have > someone else run) an ALT router (plus backups) which has a tunnel to > the ETRs in the ISPs which the end-user network is currently using > for access. If that organisation's ALT routers go down, it is not > the fault of the access ISPs - it is up to the end-user network to > ensure it obtains its EID address from an organisation which provides > a reliable ALT router service. > > Also - assuming the space is covered by a PTR in order to provide > 100% multihomed service for packets sent from hosts in non-upgraded > networks - this organisation has to run PTRs which covers this > end-user's EID space. For this to be scalable (not to bloat the DFZ > routing table excessively, as we go to millions of end-user networks > with EID/micronet space), the PTRs needs to advertise a prefix which > covers the EID space of thousands or hundreds of thousands of > separate end-user networks. > > Since the sending hosts (in non-upgraded networks) could be anywhere > in the world and since the ISPs used by all these end-user networks > (covered by the one BGP advertised route) could be anywhere in the > world, in order to ensure reasonably direct path for traffic packets, > there needs to be a largish number of PTRs physically all over the > Net. Then the organisation which runs this PTR system needs to > recover costs from individual end-user networks according to the > traffic the PTRs carry. (This is the Ivip business model for > OITRDs. I am stating this as an imperative for LISP, because I can't > imagine any other business model for PTRs.) > > In the case of Ivip, the equivalent organisation needs to do the same > as just stated for OITRDs and provide the real-time mapping > distribution service, with a small charge per update. > > Either way, the end-user network has a long-term technical and > commercial dependency on whichever organisation supplies its EID > (LISP) or micronet (Ivip) address space. This is why my message > continued to state that a problem such as this is common to all > core-edge separation schemes: > > [Fix? Seems to be a fundamental problem, but every core-edge > separation scheme involves supplying stable EID, micronet etc. > address space to end-user networks, so there must be some > kind of dependence on some organisation - though not > necessarily an ISP.] > > {Experiments? There's no need for experiment - problems such > as this can be clearly foreseen.} > > So while I could take this off the list of "unresolved" problems for > LISP, since other schemes have comparable problems - I think LISP > could be improved by more clearly stating the types of commercial and > technical relationships each participating end-user network will rely > upon. Also, the physical distance to the ALT router from wherever > the end-user network's ETRs are directly affects the delay > experienced at the start of sessions. I think that is part of > Christian Vogt's concern. > > I think I have done a better job of explaining all this with Ivip's > business model for OITRDs: > > http://psg.com/lists/rrg/2008/msg01158.html > > > The dependence is now on the > > ALT. And if your site resides in a specific region of the > world, you get > > your EID-prefixes from that registry. So readdressing your > domain would > > only occur if you moved it from one region to another (let's leave > > mobile ASes out of this for now). > > I think a good core-edge separation scheme should make the EID > (micronet) space entirely portable, with little or no compromise in > performance or costs regarding mapping no matter where the end-user > network chooses to connect its EID space (or some part of it) > to the Net. > > This is easier for Ivip, since the mapping change command only > involves a few dozen bytes and is made quite infrequently. > > For LISP-ALT, the mapping connection is an incoming stream of > requests or initial packets which also function as requests. It is > time-sensitive, since only when a response arrives at the ITR can > communications without delay begin. So the physical proximity (delay > and reliability) between the ALT router for this section of the EID > address space and the the ETRs of the ISPs currently used by the > end-user network is really important. I don't mean San Jose to LA > distances - I mean Australia to the USA, Germany to China etc. > > These do seem to be a fundamental difference between LISP-ALT and > Ivip. However, both systems will only work well with a widespread > set of PTRs/OITRDs. > > > >> 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > >> others discussing the inherent PMTUD problems in any map-encap > >> proposal, there has been nothing from the LISP team to indicate > >> they have a solution. They seem to think there is no problem. > > > > In section 5.4 of draft-farinacci-lisp-11.txt we describe > two proposed > > solutions, one is stateless, and the other is stateful. The stateful > > creates no new table data structures but requires storing > an addition > > 2-bytes of effective-MTU state per mapping. > > OK - I apologise for stating that you thought there was no problem. > > I haven't considered MTU problems of sending traffic packets along > the ALT network, in its GRE tunnels (which impose their own > encapsulation overhead) - but I understand the current LISP test > network doesn't send traffic packets over ALT. It is my impression > that your long-term plans are to use the ALT network only for short > map request messages, not go get initial traffic packets to > the ETR ASAP. > > Version 08 (2008-07-10) introduced a stateless technique and version > 11 (2008-12-19) adds a stateful approach, derived from the OpenLISP > project, who regarded the stateless approach as inadequate. > > My assessment of both approaches is in a separate message: > > LISP PMTU - 2 methods in draft-farinacci-lisp-11 > http://www.irtf.org/pipermail/rrg/2009-January/000885.html > > I think the stateless section is poorly written and ill-conceived. > The stateless approach for IPv4 DF=1 packets and IPv6 packets (that > is, virtually all traffic) would limit traffic packets to 1464 bytes > (IPv4) or 1444 bytes (IPv6). Only once there was jumboframe links > between every ITR and ETR could L be globally adjusted upwards from > 1500 bytes to ~9000 bytes or whatever - but this would not be > possible for a decade or two. Fred Templin expressed the same > concerns in a recent RRG message. > > The Stateful approach, which I understand is derived from OpenLISP, > is similar to Ivip's approach: > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > > I need to write this up as an I-D, but it is a more detailed spec > than your LISP approach, with mechanisms for occasionally testing for > MTUs longer than the assumed limit and for strictly minimising the > number of traffic packets which are used to probe the PMTU. Every > packet whose length, once encapsulated, is in the "zone of > uncertainty" for this ETR is either delivered or rejected with a PTB. > The former raises the lower limit to the zone and the latter > reduces the upper limit. > > > >> 6 - Lack of business case for LISP's Proxy Tunnel Routers: > >> http://psg.com/lists/rrg/2008/msg02021.html > > > > You cannot fault a technical design for a business case. > > A complete solution to the routing scaling problem involves much more > than a technical design. > > All the technical stuff (sometimes split into "architecture" vs. > "engineering") needs to facilitate someone wanting to build and run > each part of it - which generally means they (or someone not too far > removed from them) needs to be able to make money from it. > > > > A PTR is > > solving a technical problem. And if we want to *truly* keep > lots of PI > > type routes out of the core *and* avoid NAT solutions which > are just way > > too high in opex, the PTR is the only solution we have to turn to. > > > > And on the contrary, I do believe service providers, interconnect > > providers, registries, third-parties and even governments > will provide > > PTR services. Will they make a ton of money out of it, well > that remains > > to be seen. > > I think my critique is valid - you seem to have no business case for > LISP's Proxy Tunnel Routers. > > You are welcome to adopt the Ivip approach for address management and > OITRDs: > > http://psg.com/lists/rrg/2008/msg01158.html > > This is directly applicable to LISP and PTRs, as long as you have a > concept of a Mapped Address Block, containing many EIDs. For that to > be the case, you need to develop business arrangements concerning who > really "owns" the MAB and how they rent this space out as EID space > for thousands of end-user networks. > > > >> 7 - The scaling problems of potentially thousands of ITRs each > >> probing reachability to one ETR, and likewise, one ITR probing > >> reachability to many ETRs - this is one view of the > "Locator Path > >> Liveness Problem" of draft-meyer-loc-id-implications-00. > >> http://www.irtf.org/pipermail/rrg/2009-January/000809.html > > > > That is not in the LISP design. Everyone just thinks it is. ;-) > > > > Dave and Darrel's draft is providing a warning about how > bad probing can > > be. They do not take a position whether it should go into > any proposal. > > They are just saying, beware of the Frankenstein that may > result and can > > be an interpretation to not do probing at all. > > The scaling problem of thousands of ITRs continually test > reachability for one ETR (or to every ETR on the LISP mapping list > for a given EID), plus reachability through each ETR to a given > destination network, or of each ITR having to test reachability to > thousands or tens of thousands of ETRs have been obvious from the > start: early 2007. > > This is true of LISP, TRRP and to a somewhat lesser extent APT. (I > haven't read RANGER yet.) > > Only Ivip avoids these scaling problems by making the end-user > network responsible for their reachability testing and for deciding > which ETR the packets for each micronet should be tunneled to. > > > > Like I mentioned in a previous RRG email message, one has to ask the > > question if an ITR *should* switch from one RLOC to another > when there > > *may* be a path failure *somewhere in the middle of the > network*. Please > > note my very fine qualifications. > > > > If we want to solve this problem, we could do this today by having a > > host switch it's TCP connection to another A record. This > doesn't happen > > today because people deal with packet loss, since it > doesn't last long > > *and* rerouting actually works quite well. > > > > Van Jacobson always made this comment and I'll never forget it, "The > > fact that the Internet drops packets is it's greatest feature". > > > > What else can either an xTR or TCP host do when sending ICMP > > Unreachables are off by default in most modern routers, or they are > > filtered by firewalls, and route aggregation hides failures close to > > packet sources. > > The alternative has been available to you and anyone else since July > 2007: Ivip. A fast-push mapping system to local query servers means > the ITRs don't need to test reachability or make any decisions about > which ETR to use. The mapping has a single ETR address. > > What is wrong with this approach? > > > >>> Unless these concerns are adequately addressed, claiming that LISP > >>> is an appropriate solution to the problems discussed at the IAB's > >>> October 2006 Routing and Addressing Workshop is nothing more than > >>> a proof by an emphatic assertion. > >> > >> I agree entirely. > >> > >> I believe the LISP team could have made much better use of > the RRG - > >> by participating fully in the debates resulting from these > critiques. > > > > We were asked to do research in RRG. That was a reasonable > request. So > > the research stuff in LISP has been and will continue to be > presented in > > RRG. > > OK. > > > As for the engineering issues, the real details and bits > and bytes, we > > want a forum to discuss and work out issues in an open > forum. I've been > > going to IETF for 20 years now, that forum is called a > working group. > > > > The working group doesn't have to standardize what it is > working on. And > > the charter and the numerous requests we have made requests *for an > > experimental working group*. > > I think this is fine. > > However, I think there are sufficient fundamental, well known > problems with LISP-ALT that if this was my proposal, I would fix them > before asking people in general to join an IETF WG and help me with > it - or drop the proposal. > > > >> Experiments won't help solve most of these problems. I am not > >> against experimentation and I think it is great that there > is a LISP > >> experimental network. > >> > >> However, I would never have taken a proposal to the point > of writing > >> code, running a network and inviting others to write compatible > >> implementations when the proposal had so many fundamental problems. > > > > There is constant implementation feedback back into the design. > > Experienced engineers know how this cycle works. You start with > > something you think can hold together, you try things out, > you refine, > > you revisit design, you go forward with implementation. That's the > > process of *detailed* engineering. > > > > For the old timers, that was the difference between TCP/IP and OSI. > > I am all for detailed engineering, running tests etc. However, the > worst problems I perceive with LISP-ALT will not be illuminated by > any amount of testing, as I explained in the message you are > responding to. > > > Do you think Ivip is so overblown and over-complex that it warrant's > no serious consideration? > > Just because I write stuff in detail doesn't mean the system itself > is over-complex. Ivip ITRs and ETRs are much simpler than LISP ITRs > and ETRs. > > > I have been giving your work the honour of detailed critiques for 18 > months. I would appreciate you and your colleagues returning the > favour by reading: > > http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf > > http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 > > Ivip business models: fast push & OITRDs > http://psg.com/lists/rrg/2008/msg01158.html > > and telling me - and the RRG - what you think. > > > Also, I am keen to know from you, your Cisco colleagues and from the > folks at Juniper how practical it would be to create firmware > upgrades for all the DFZ routers in use ca. 2014 or whatever - > whenever the routing scaling solution is to be implemented. > > I think it is practical and highly desirable to encode the ETR > address in the IPv4 header (actually 30 bits, which is fine) or a 20 > bit prefix label in the IPv6 header. Then, in the longer term, we > don't need encapsulation, its complexity, its overhead and its damn > PMTUD problems. > > As far as I know, both these proposals could be implemented as > firmware upgrades, or built-in optional features, in the DFZ routers > which are likely to be in use in 5 years time, but only you guys can > say this is so or not: > > ETR Address Forwarding (EAF) - for IPv4 > http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01 > > Prefix Label Forwarding (PLF) - for IPv6 > http://www.firstpr.com.au/ip/ivip/ivip6/ > > Maybe we can do that in time for the introduction of the routing > scaling solution - and thereby completely avoid encapsulation and its > PMTUD complexities. > > > On mobility - what is your objection to this arrangement? ETR-like > Translating Tunnel Routers with two-way encrypted tunnels to mobile > nodes. Mapping only changes to a new TTR when one is really needed 0 > which is typically only when the MN moves 1000km or more. So mapping > changes are not at all frequent and in particular are not needed > every time the MN gets a new CoA: > > http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf > > > If I was proposing to the IETF that a WG be formed for my project, I > would first want to establish for myself - and for IETF people in > general - that my project was either the best in its class, or one of > the very few with the most promise. > > I don't see how you can do that when you fail to read - or at least > fail to discuss in public - alternative schemes to LISP. > > Ivip and APT are broadly comparable to LISP - they are all core-edge > elimination schemes for both IPv4 and IPv6. They are both well > enough documented to be suitable for serious critiques from anyone > who believes LISP's approach is superior. > > Just because you have more people - with more experience and > resources - working on LISP and have running code, doesn't mean your > LISP-ALT design is better than APT or Ivip. > > > - Robin > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
