Regular participant hat on. On 3/07/2015 2:23 am, "Dino Farinacci" <[email protected]> wrote:
>> Joel, Luigi, >> thanks for starting this conversation. > >Yes, thanks for bringing up and providing leadership. +1 !! > >>>First, there is the question of direction for the basic LISP >>>specification. We can leave it as it is. However, folks have asked us >>>about moving it to Proposed Standard. Based on our reading and >>>discussion with relevant ADs, one path to do this would be to refocus >>>the specification away from the core Internet scaling problems, and >>>instead towards a scalable anxd flexible overlay technology. This >>>would not change the technical procedures, but would have significnat >>>impact on the descriptive text. >>> >>> Does the WG think this is a good idea? If so, do folks want to do it? >> >> I think it is a good idea, and I would be willing to work to make it >>happen. In my experience with LISP > >You can count me in to make major contributions or lead technical efforts. Making the spec PS fits the envisaged evolution of the LISP "experiment". The downside here might be that this is also recognition that LISP does not fix the _global_ routing scalability issue (presuming of course that the issue remains) in any short term exercise due to the way operators actually choose to run BGP. Is the global internet ready and willing to separate the locator and identifier in operations yet? I don't think so. I would certainly say that it makes intra-AS routing systems leaner, as a very positive outcome. > >> deployments over the last few years, LISP has brought the most value to >>the table when used as a scalable, flexible, and (I would add to your >>list of attributes) programmable overlay technology. > >Yes, my experience shows this as well. In fact, the marketing value of >LISP is its overlay capability and at the same time the core network is >leaning with less state. This goes for unicast and multicast. So we could >be thinking about all this in the reverse direction (but the requirements >in 2007 was to save the routing table). > >> I suspect this refocusing will make the life of the WG a little >>simpler, as the focus on core internet scaling problems has put the work >>done under a very tight scrutiny, some time making harder to evolve the >>protocol in the direction where a scalable overlay technology should go. I think the scrutiny came through multiple different lenses. Not just global routing scalability. I also doubt that the scrutiny will diminish. But I do like the idea of calling it what it really is. It's an overlay with attractive properties. > >These are not new work items or changes to the LISP architecture. They >are all supported and implemented in various forms in both open and close >products. > >> quicker progress. It's also true that IoT and LISP-MN are probably the >>areas with the greatest potential. Rather than making the charter >>exclusive, I would try to leave the door open. We can use milestones to >>prioritize the initial focus, but at least the WG has a way to later add >>work in those areas. > >I think if we can have the charter describe items generally as >categories, then a specific use-case as IoT or LISP-MN will just fit in >one of those categories. Take care to not leave the door _wide_ open. I look at LISP as a very (very!) well reviewed specification that currently is not overweight with unused/unnecessary features. I have a concern that having all and sundry adding in their pet feature may cause that attribute to suffer. Perhaps it would be sane to pick the 4-5 priority items and work on those, nail them and move forward that way. Cheers Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
