Sorry for jumping into the fray at this juncture, I missed Jari's original message :(
On Thu, Jan 22, 2009 at 6:39 PM, Yakov Rekhter <[email protected]> wrote: > Jari, > >> I wanted to provide some background on this question. >> >> As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis we >> had a number of WGs and the RRG talk about LISP. Implementation and >> small scale deployment is going on. The RRG is still continuing its >> work, and they are looking at a number of different solutions, including >> map-and-encap, translation, host changes, and combinations thereof. I do >> not want to preempt the RRG's efforts and at this time we are NOT >> considering any IETF standards in this area. We are, however, >> potentially interested in working groups targeting experimental >> specifications so that we can get more experience about the various >> technical solutions, different people can build systems that work >> together, etc. Some of you may be familiar with the HIP effort; they >> also had a working group that produced experimental RFCs to complement >> the more research oriented work in the IRTF HIP group. >> I think having a focused group that can work out some of the large scale deployment, operations and design issues with this bit of technology would be helpful. We have spent the better part of 2 years (we == the community) working in the RRG and in side groups attempting to design and test a new routing architecture. Putting that work into an official spot, allowing it to work through issues and determine if the design/plan will bare fruit, I think is a good thing. >> My interpretation of the outcome of the first BOF was that the topic was >> very interesting for the people in the room but that at the time they >> felt it was more in research than IETF scope. There were also technical >> debates. That being said, we did not spend enough time on the WG in every WG meeting that this subject came up in both Dublin and Minneapolis there was a great deal of interest, discussion and debate. This, it seems to me, signals that there is interest in seeing how this technology may work out for the community as a whole. I believe this shows a WG would be helpful in containing the work and scope so a result and direction can be determined. >> formation question. So I did not view the results as final. >> Nevertheless, several attempts were made in the autumn to create some >> form of a subgroup in RRG to do this work. However, the proponents were >> only interested in a working group. >> >> So what is happening now is what we did with many other BOF efforts as >> well. We got feedback in the BOF, there's been further discussion, and >> work on various fronts has progressed. Its time to complete the >> discussion about the fate of this effort. We need to see if additional >> information or further changes can result in a WG proposal that is >> acceptable to the community or not. If we can reach a decision on the >> list, fine, if not I will reserve a second BOF slot for the discussion. >> I am mindful of the fact that the list discussion may not reach quite >> the same crowd as a f2f meeting, so unless we get a fairly strong signal >> in the list we probably need to meet as well. >> >> But back to the proposal. In particular, I would like to know how people >> feel about this work being ready for an (Experimental) IETF WG, what the >> scope should be, whether the charter is reasonable. And if not, what >> would make it so. I'd like to see an experimental wg, I think at least the scope could cover: o fleshing out/finalizing the proposed LISP protocol suite o working through and documenting some of the use cases and operations of LISP o characterization of true scalability impact at current traffic rates I think that 'LISP' is a might narrow though, there are other map/encap solutions which may work as well. I'd like to see how something like map/encap works, and if it shows itself to be helpful. > > The question to ask is whether LISP is an appropriate solution to > the problems discussed at the IAB's October, 2006 Routing and > Addressing Workshop. Yakov, I'm not sure there have been any other credible solutions aside from 'map/encap', this seems promising, though certainly it hasn't been proven out in the way that v4 routing as we know it today has been. Certainly there are use cases where there will be issues, certainly there are ways to deal with these use cases. Without some direct experimentation, thought about the problems and focus, we won't be able to address these things. (we == community) > In answering this question we need to keep in mind that such > techniques as (a) caching routing and forwarding information, (b) > use of separate mapping system for Loc/ID mapping, (c) relying on > probing for determining path feasibility are essential/fundamental > to LISP. In other words, these techniques form the foundation of > LISP. Concerns with scaling and operational properties of these > techniques have been raised many times before (both at the previous > BOF, as well as on the RRG mailing list). Yet the LISP proponents > still did not adequately address these concerns. I thought they had addressed some of them, both on-list and in-person at a few of the meetings. Perhaps some details were lacking? > 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 don't think anyone has said one thing or another is 'the solution', I think so far 'a solution might be' has been used though. Without some work, investigation and engineering I don't think we'll be much further toward a solution in another 2 years. I think it's important to gain some experience with the options. > Unless the concerns I mentioned above are adequately addressed, > LISP can not be accepted as a feasible/practical approach towards > routing scalability. Therefore, unless and until these concerns are > adequately addressed, it is totally premature to form LISP WG. we can't know if an approach is feasible/practical until we make an honest attempt to work through both the engineering issues and the operational issues... Did you have options we should also discuss? -Chris _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
