> Hi Dino, Hey Xiaohu.
> As an alternative VPN technology, what's the major benefit of LISP VPN > compared to MPLS/BGP IP VPN? You can put LISP-VPN anywhere. MPLS/BGP is typically run within a single service provider. With LISP-VPN, users can initiate and provision their own VPNs. That is just one difference. > 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? There have been many pros and cons using BGP as a push control-plane and LISP as a control-plane. At the high-level, I’ll state one difference. The LISP control plane (the mapping database nodes), are in less places in the network than BGP nodes. So that means less coordination and management. > Due to the new mobility requirements in 5G architecture (e.g., ultra-low > latency), LISP-MN mobility may be a competitive candidate. Why do you say that? Compared to other solutions its better. Or some technical aspect? Dino > > 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
