Re: [lisp] WG Charter

[Dino Farinacci <[e-mail]>]

> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp