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).

> - 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.

> - 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.

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