Hi Dino, > -----Original Message----- > From: lisp [mailto:[email protected]] On Behalf Of Dino Farinacci > Sent: Friday, July 03, 2015 12:24 AM > To: Fabio Maino > Cc: LISP mailing list list > Subject: Re: [lisp] WG Charter > > > Joel, Luigi, > > thanks for starting this conversation. > > Yes, thanks for bringing up and providing leadership. > > > On 7/1/15 7:18 AM, Joel M. Halpern wrote: > >> One of the things Luigi and I as chairs would like to do in Prague is spend > some time discussing among the WG participants what we want to work on > going forward. To enable this, we would like to start discussion on the list. > We will also follow the face to face with a summary to the list and further > discussion. > >> > >> There are two aspects that are related but distinct, so to start this off > >> I want > to identify them and ask folks to comment on them separately. > >> > >> 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. > > > 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. > > And I think we should encourage more users and operators to participate. I’ll > help lobby up such organizations. > > >> Second, there are a large number of pieces that people have proposed (many > with drafts). There are probably too many to include everything in the > charter. > Which things do people think are important for the WG. In particular, > explanations of why particular items are important, and comments pro or con > from folks who are not the document authors are particularly useful to the > community. (I doubt that there will be significant negative comment since I > have not seen proposals that are bad ideas. However, the WG has to prioritize > and choose.) > >> > > > > I agree, the new charter should help the WG focusing on LISP applications. > > As > you note there have been quite a few proposals, but I think they can be > summarized in a few areas (and relative use cases): > > - LISP VPN (including integration with IPsec) > > This is really important and is a fall-out from what we already have. There > is little > machinery to be devleoped but focus needs attention on instance-ID assignment > and if multiple mapping systems are used for intra-VPN and inter-VPN > (regardless how many different ISPs are used for a given VPN for the > underlay).
As an alternative VPN technology, what's the major benefit of LISP VPN compared to MPLS/BGP IP VPN? > > - NVO3 use case for DC virtualization (including support for VM mobility) > > Definitely. The working group has decided to go with both a push and pull > control-plane. Bess is working on push ala BGP and there has been references > time-and-time that the LISP mapping database could be used as the pull > control-plane. Now is the time to formalize this. From the data plane perspective, given the fact that there is unprecedented enthusiasm for defining various data plane encapsulations (e.g., VXLAN, NVGRE, VXLAN-GPE, GUE-NVO, GENEVE...) , it seems no surprise to add two more (e.g., LISP and LISP-GPE). From the control plane perspective, as BGP could be used as a pull-based control plane as well due to its prefix-ORF mechanism, what's the major advantage of LISP over BGP? > > - SDN/NFV (including support for service chaining) > > The LISP-TE draft supports this use-case and we have a couple of > implemetnations that use the ELP LCAF to do service chaining. > > > - IoT (LISP as connecting infrastructure for IoT applications) > > Yes, for tracking sensors, for deciding if sensors should move, to provide > access-control, etc. > > > - Mobile Node (LISP-MN mobility) > > I think, as I said in the last email, we can combine “IP address mobility”, > which > means any type of address mobility (including MAC addressing and > geo-coordinates as EID mobility) to be solved with one mechanism. Again, the > question is if the RLOC and EID move together. Due to the new mobility requirements in 5G architecture (e.g., ultra-low latency), LISP-MN mobility may be a competitive candidate. Best regards, Xiaohu > Others to add to the list: > > - How overlays can be used to traffic-engineer underlays. > - How to simplify multicast when the underlay does not support multicast at > all > or partially. > - How mobility of EIDs, multicast, and data-plane security all work together. > - And most importantly with the advent of cloud applications (all that sit > behind > NATs) and residential service (homenet), work needs to be done with > NAT-traversal. > > The last bullet is really important or you limit where you can deploy LISP. I > have > had a lot of implemetnation experience trying to get all the different LISP > features to work across NATs. This includes and is not limited to > RLOC-probing, > lisp-crypto, multi-homing to multiple RTRs, xTRs behind multiple NATs and > firewalls, and multicast. > > > I think the first 3 areas may drive an important change that, in my > > opinion, the > WG should consider to include in the charter: how to support a multi-protocol > encapsulation that allows integration with IPsec, support for L2 overlays, and > support for explicit tagging and end-to-end metadata. With NVO3 selecting > VXLAN-GPE as one of the supported encapsulations, and given the striking > similarities with the LISP encap, I think the new drafts should be required to > support both LISP and VXLAN-GPE encapsulations, as the LISP-GPE draft is > trying > to suggest. > > I think it is clear from the industry that the LISP control-plane can be used > for > multiple data-planes. So we should not limit or specify specifically (and not > in > one place) a single data-plane. > > > There are a lot of common attributes for an overlay technology that works > across the areas described above. It's hard to make a priority, but probably > the > first 3 are the ones where the group can make > > I think we leave this for WG discussion. I don’t think anyone would argue with > this following statement: > > “An overlay needs to move unicast and multicast packets in a secure and > scalable way in public and private addressing environments”. > > That means: > > (1) We need unicast and multicast EIDs. We need to support unicast and > multicast RLOCs. > (2) We need to get VPNs to work when RLOCs and EIDs are private addresses > and come from multiple address-families. > (3) We need the data-plane to provide privacy and control-plane to provide > access-control and policy. > (4) And anything we do must scale. To what degree is debatable. > > 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. > > Dino > > > > > Thanks, > > Fabio > > > > > > > >> Yours, > >> Joel > >> > >> _______________________________________________ > >> lisp mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/lisp > > > > _______________________________________________ > > lisp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
