Hello Jeff, Again thank you for your interest in LISP and please be sure that we are considering your comments as they merit to be.
In our discussion last week, I proposed to add a discussion about the risk of cache poisoning with negative replies. The draft with this discussion will be submitted with the other comments that we will receive during the next IETF. So that, the draft should be presented publicly available during mid of August. Otherwise, feel free to participate in the effort for securing the mappings (see draft-saucez-lisp-mapping-security-00) where we are looking to see how to avoid someone to cheat with the mappings it provides. However, in our mail exchanges, I said that the cache management was more than a security problem and was more important than just negative replies. You can inject a lot of entries with positive replies as well, particularly in IPv6. You can have this by massively de aggregating the prefixes. Again, this is not a security problem, this feature can lead to security but cache management is first a general problem in LISP and in Map-and-Encap in general. It thus merit to be discussed in the main specs. However, researches have shown that the cache management was not as dramatic as we could expect. Of course the first study in 2007 was with a mid-size campus network and I could understand that you considered that the work was not relevant. Nevertheless, the study has been repeated this year with a traffic trace from an operator (and not a pet-operator, a real one that has millions of customer today) and the conclusion is the same. So if you still think that our research sucks and is not representative, I would be very happy to get a traffic trace on your network and do the evaluation. The only limit we have is the time you are ready to wait for the simulation to complete! Do not hesitate to provide us a 10-year full packet trace from your network and we will do all the work for you to see if LISP could be used in your network or if it would become a catastrophe. On 11 Jul 2011, at 06:57, Jeff Wheeler wrote: > On Mon, Jul 11, 2011 at 12:29 AM, Dino Farinacci <[email protected]> wrote: >> I don't know what you mean, but if your definition of a 'destination >> network' is either a single or multi-homed site, then the FIB would hold 50K >> entries. > > I am not responding to all of the points raised in your message, > because you are still missing the fundamental problem that negative > replies from the LISP Mapping Service, which should be cached in the > ITR, can cause the table to be inflated to a size that is, literally, > ten times the number of possible positive mapping entries. Once > again, read my original LISP mailing list post on this subject. > As I am mentioning since a few days now, your are focusing on a small part of the problem. The real problem is cache management in general. Negative replies are only a very very small part of the problem. > If you read the part in the MS draft that dictates negative replies > must not overlap any possible positive mappings, and consider how RIRs > are currently allocating IPv6 address space to networks, you should > easily realize how this part of the MS protocol needs additional > flexibility. Quite simply, a 50k entry IPv6 table would indeed > consume 500k entries when negative entries are included. > Could you provide more information about the numbers? From where is the 10 factor coming? > The simple arithmetic is in my original post, months ago. > I think that the problem is more than just simple arithmetic so please provide more details about how you obtained your results. Sorry I am just a researcher so I do need a lot of details to be able to understand the things. Thank you again and please ask for a slot at next IETF to make the discussion growing. Cheers, Damien Saucez > -- > Jeff S Wheeler <[email protected]> > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
