Re: [lisp] WG Charter

[Xuxiaohu <[e-mail]>]

Hi Dino,

> -----Original Message-----
> From: lisp [mailto:[e-mail]] 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
> >> [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