Hi David, Thanks for your reply, in which you wrote:
> My understanding/summary of what I heard this week > (Tuesday, IIRC) is that the RRG will *not* recommend any > of the proposed solutions (or any other?) but rather will > recommend "concepts". What exactly constitutes a > "concept" wasn't clear (at least to me), even though it > was briefly discussed. OK - I haven't yet listened to the earlier part of the Tuesday meeting, or the Friday meeting. I guess the RRG would recommend development of a set of technical concepts which would (ideally) fit together to create the complete solution, or perhaps recommend some parts of the solution for engineering development while leaving other parts up for further research and discussion. I guess the RRG wouldn't recommend "develop the proposals in this set of IDs", but would carefully describe the key principles and characteristics of whatever needs to be developed. Ivip is my way of developing a set of approaches which looks best to me. Later in the year I plan to produce a reasonably terse technical description of what this involves, without mentioning Ivip and whilst trying to leave open questions of terminology. This will be part of a future, shorter, version of ivip-arch, which will be a high-level architectural overview with a list of benefits, challenges, goals and non-goals. I am writing the Ivip IDs to help in this RRG brainstorming, research and decision phase. These IDs are structured to aid understanding and hopefully to prompt people to think of new and better ideas. They are not ready to be tweaked into Standards Track RFCs. I envisage that by the time some of our ideas today wind up in an IETF WG in mid 2009, they may be combined with other ideas from outside the RRG's experience - and the whole project would probably have a different name. >> Does your BOF announcement mean something like this? >> >> 1 - You think LISP is so practical and desirable that it is "the" >> routing scalability solution to the exclusion of others - and >> perhaps for other purposes. > > The LISP BOF proposal has nothing to do with any other > proposal. OK - I understand you think that engineering development in an IETF WG is the best way to develop LISP, rather than another year developing as part of the RRG research phase. My view is that the RRG schedule is good, and that the routing scalability problem isn't so urgent that we need to rush into engineering development of any of the proposals. The scalability problem is partly about BGP convergence and stability, and partly about many end-users who would like multihoming being shut out of it due to the difficulties of BGP. However, in terms of costs of running the DFZ routers, the picture is neatly summarised by Geoff Huston's graph: http://bgp.potaroo.net/ which shows a doubling every 4 years in the single most important metric of the routing scalability problem - the number of advertised routes. I figure the doubling time will drop to 3 years or even 2 as the pressure to slice up IPv4 space grows, once the fresh pastures have all been sub-divided around 2011/12. Meanwhile, anyone who wants to run DFZ routers just plugs more RAM into their routers, or buys new ones which have the RAM and CPU capacity to cope with the growth. To some extent, these router replacements would occur anyway, due to need for more and faster ports etc. My guess is that even if your LISP BOF doesn't lead to a WG this year, that a map-encap scheme will begin development in a WG by mid 2009, with some RFCs emerging around 2012. My aim with Ivip is that people will actively want to deploy it, and will wait for the RFCs before doing so - rather than having to be cajoled into adopting it. By then, there will be a much greater fervour for slicing and dicing IPv4 space more finely without further burdening the BGP control plane. LISP, ALT, Ivip or TRRP will all be able to do this. They will all be able to support multihoming, portability and TE (though Ivip's TE capabilities are not explicit). What is in question is how elegant, cost-effective, flexible, attractive, and open-ended they are. In particular, how would each scheme support mobility or extension so some purpose we haven't thought of yet? By then there will probably 500,000 to 600,000 DFZ routes, meaning that some subset of the routers in the DFZ today will have had to be upgraded, depending on their CPU power, RAM and the number of neighbours they have. I don't think this major architectural change to the Internet is so urgent that we need to rush things faster than what I envisage - RFCs in 2012. At the very best, your accelerated plan for LISP would have you in a WG in late 2008, rather than mid 2009. So that is a 9 month head start, meaning - all other things being equal - that you would have a set of RFCs 9 months ahead of whenever the RRG process would produce RFCs. The number of DFZ routes doubles every 4 years, so with the RRG time-frame, the RFCs would be ready when the number of DFZ routes was 14% higher than with your proposed schedule. Solving the problem before it gets 14% worse doesn't seem like a good enough reason for pushing one of the current immature map-encap proposals out of its RRG nest, onto a fast-track of development, when I think another year in the RRG incubator growing up with its nestlings would lead to a much stronger adult bird. I think the RRG process is very productive. I think it would be more productive still if people did some critiques of Ivip like I and others do of LISP, APT and TRRP. > I'll just note that if someone has a proposal that they > feel has moved into an engineering phase, the "right > thing" (IETF process-wise) to do at that point is propose > a BOF, assuming of course that the authors/proponents of > that technology want the IETF to standardize that > technology. Sure, this is the right thing to do, given your confidence and sense of urgency about LISP. > Finally, note that its soley IESG's decision to approve > or disapprove BOFs, and if the outcome of a BOF is that > the participants of the BOF want to form a WG, that is > also soley the IESG's decision. > >> 2 - You think the RRG's timetable is too slow > > Yes. OK. On one hand, I can understand your desire to press on and develop your system into a fully fledged set of RFCs ready for global adoption. You have proof-of-concept code running in a number of sites and you are putting test traffic through it. I could imagine not wanting to write more code until you have a more stable set of RFCs to work from, since if you write code now and later the WG changes something in detail or in principle, you will have some potentially very disruptive changes to make to a large body of work. Also, I imagine you want to have RFCs ASAP so you can plan the hardware of the next generation of routers. This is particularly the case for LISP, since you have the ITRs and ETRs doing such complex functions. You can tell from: http://www.firstpr.com.au/ip/ivip/lisp-links/#critiques that I think LISP is nowhere near being an optimal solution to the routing scaling problem. I guess you expect to enough people who think LISP is the way forward that the other proposals - APT, Ivip and TRRP so far - needn't be considered as serious alternatives. Or maybe you are expecting to develop LISP in a WG and have one or more of the others, or whatever the RRG chooses, also developed in parallel in another WG starting mid 2009. I don't know enough about the IETF to say how common this is - to support two WGs working on the same problem in incompatible ways. I guess this could happen if there was broad support, say 40 to 50%, for both proposals, and no prospect of one side merging with or ceding to the other. Then the IESG would be faced with choosing one over the other, or letting both projects develop as best they can, hopefully learning from each other, with later decisions - including by end-users - determining which is widely deployed. However I can't understand your confidence in LISP being ready for engineering development right now. I think the problems your proposal faces include: ALT is a global query server system, and so will often be slow to get mapping to the ITRs compared to the local query servers of APT or Ivip. This leaves you with the problem of either expecting end-users to adopt the new address space when it suffers from poor performance due to delayed initial packets, or coming up with some way of speeding up the delivery of the initial packets to ETRs, without the ITR having the mapping information. The only way you have of doing this at present is routing them around the ALT network - the EMACS multicast idea has to many problems. This is assuming that you solve the problem of ALT's strong aggregation leading to structures which take no account of geography and lead to packets crossing oceans and continents between one ALT router and the next, as they ascend the hierarchy to a router which covers the destination, and then descend the hierarchy towards that destination. Christian Vogt (message 259) also argues that this aggregation implies provider dependence. I think there are a bunch of problems we haven't fully explored regarding ALT's use of the ETRs as the authoritative source of mapping. This is a highly decentralised system - making it hard to enforce good authentication of who is announcing mapping for what EID prefixes. You haven't articulated a plan for PMTU and fragmentation problems which makes good sense to me or Fred Templin - and no-one has written to the list in support of your current plan. There are things I consider dead-wood in your proposal - which don't need to be there - LISP-NAT and "gleaning". By choosing a pure pull system, without any "Notify" (immediate push to ITRs which need the changed mapping info), you constrain the latency of mapping distribution to be bounded by how short the ETRs make the caching time of their replies. This means an ETR could run the mapping pretty hot, with a 20 second caching time, but this would place a huge burden of computation and query traffic on the ITRs and the ALT network as well as on the ETR and any other authoritative ETRs - in proportion to how many ITRs were actually handling packets addressed to this EID prefix. You specifically disclaim the use of the map-encap system for direct support of mobility, but I think you misunderstand how map-encap can and arguably should support mobility. You seem to assume that the ITR should tunnel packets direct to the mobile node. But the mobile node will often be behind NAT, so could never be reached and treated like an ITR. I am convinced that mobility needs to be handled along the lines I propose: mobile nodes make tunnels to nearby "Translating Tunnel Routers" - like choosing one or more nearby home agents. This is a second level of the 3 layer model, the first being whatever mobility stuff happens in the access network, such as handover between base-stations, which preserves the mobile node's care of address. Then, the map-encap system has its mapping changed to tunnel packets to the TTRs. This is the third level, which enables optimal paths from non-upgraded correspondent hosts (or from the TTRs of mobile correspondent hosts). The three levels make perfect sense and produce a powerful new form of mobility which is compatible with all existing hosts - which can never be the case with traditional mobile IPv4 or IPv6. I think the reason you reject the routing system's involvement in mobility - including the use of the map-encap scheme, which is a much lighter weight, less costly, more flexible, faster, more scalable, scheme than BGP - is that you assume that mobility means a mapping change for every change of access network. Yet with the 3 level model I propose, it only needs to change when the mobile node needs a new TTR, which will typically only be if it moves 1000km or more. Many people don't move that distance month-to-month, or from one year to the next. So for most users, mobility doesn't mean frequent mapping changes. Their mobility requirements will be met by the access networks existing mechanisms (level 1) and the way the mobile node builds tunnels to its chosen TTR (level 2). The map-encap scheme typically won't be seeing frequent mapping changes due to mobility for most users, but it is an absolutely crucial part of the system, because it enables optimal paths from all correspondent hosts to whichever nearby (<1000km) TTR the mobile node is currently building its 2 way tunnels to. LISP precludes the fast (less than a minute) mapping changes which would be so valuable for mobility, while assuming it can't be done because mobility would involve mapping changes every few minutes. I argue that it is practical and desirable to get mapping to all ITRs in around 5 seconds, and that the rate of updates for mobility will generally be very low - since most people don't move 1000km very often. You haven't critiqued these arguments, so perhaps you haven't really understood them. By your own reckoning, your current mapping distribution proposals - including ALT, which is what I understand you are focusing on - are too poorly developed to be able to accurately characterise their performance. In: http://www.employees.org/~swb/draft-brim-lisp-analysis-00.txt you wrote: Some potentially interesting mapping mechanisms have been proposed but are still very incomplete. Therefore this document primarily discusses the base LISP protocol, and then discusses possibilities with some of the mapping mechanisms but does not try to be a complete survey. Maybe you are confident of greatly improving the situation by the time of the BOF. Maybe you are planning a scheme by which the ALT network's often circuitous path problem can be largely resolved. Then, I think you would need to run some pretty complex simulations, based on realistic ideas of where the various ALT routers would be located, the degree of aggregation per hierarchical step etc. to be able to estimate the spread of response times to a realistic sample of queries. Scott Brim wrote in defence of the "ALT's long paths" argument in: http://psg.com/lists/rrg/2008/msg00584.html but this is based on two notions: 1 - That most traffic is within a region. 2 - That there will be contiguousness between EIDs in one region. By the second point, I think he means that both ends of a communication, whether on EID space or RLOC space, will have a high degree of correlation in their address space. For instance, if all of Australia used 203.0.0.0/8, that most traffic in Australia would be to somewhere in this prefix, so the queries and responses on the ALT network from ITRs in Australia would typically not suffer from ALT's global nature, or much from the long geographic distances between routers at each hierarchical level - thereby avoiding the worst delays predicted by the critiques. However, I question these assumptions. Firstly, traffic is all over the place - partly due to the international nature of the Web, but also due to the largely non-geographically based nature of peer-to-peer, worm and spam traffic. Secondly, it is my impression that IPv4 addresses are geographically all over the place. >> and due to the urgency of the situation you want to move LISP >> into the IETF WG phase ASAP. > > For the what I understand to be the scope of Routing > Research Group (the routing system), the issues are well > documented. I don't clearly understand this. >> http://www.1-4-5.net/~dmm/draft-meyer-lisp-eid-block-00.txt >> http://inl.info.ucl.ac.be/system/files/draft-mathy-lisp-dht-00.txt >> > Some haven't been published by the secretariat yet (like > the lisp-eid-block draft; in my experience they don't > publish drafts during the IETF). Others, like the > multicast draft, aren't quite finished, but will be > before Dublin. OK - I was providing the URLs for the benefit of RRG members. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
