> LISP is a pet project. Personally, it makes me want to scream every > time someone talks to me about how great LISP is, or will be in the > future. If you folks want it to grow out of the pet project stage > anytime soon, then you should stop treating it like a pet project and > start thinking about how to make it scale up effectively -- not just > in technical terms (like negative map cache entries, which are a > disaster) but also in business terms, like how do you get an EID block > so you can actually take advantage of this new technology.
You make it scale up by starting to deploy something. That is where we are with LISP. If we do say it is great, it means we have received good results over the last 6 years. It is time to take it to the next level. Many people are interested in LISP, to deploy for their own use-cases, to fund companies to build specific products for specific use-cases, and to get infrastructure ready for the demand. If there isn't a public mapping database system deployed, enterprises will do it themselves because it is easy enough to do. But we really don't want this to turn into many "private clouds" as we see with the various cloud based services being offered by industry. I think there will be private mapping database systems but I think there will also be public ones as well. The question is to try to avoid the complexities of a hybrid private/public. The same ones we see with cloud infrastructures right now. Jeff, I see environments deploying overlays where all end-nodes are ONLY EIDs. So the negative map-cache entries don't even play there. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
