Hi Dino, > -----Original Message----- > From: Dino Farinacci [mailto:[email protected]] > Sent: Saturday, July 04, 2015 1:18 AM > To: Xuxiaohu > Cc: Fabio Maino; LISP mailing list list > Subject: Re: [lisp] WG Charter > > > 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.
If IP-based tunnels (e.g., MPLS-in-GRE or MPLS-in-UDP) are used between PE routers, is there still any difference on applicability between these two VPN technologies? > > 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. In the data center network environment, route reflectors could be run over spine nodes or even servers. As such, these route reflectors could be looked as mapping database nodes. Hence, from the coordination and management perspectives, these two approaches seem almost the same, No? > > 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? Compared to other HA-based mobile IP solution, I think id/locator split solution looks better in the long run since it has the potential of eliminating the path stretch issue. Best regards, Xiaohu > 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
