Re: [lisp] WG Charter

Xuxiaohu <xuxiaohu@huawei.com> Fri, 03 July 2015 07:37 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73A31A1A90 for <lisp@ietfa.amsl.com>; Fri, 3 Jul 2015 00:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otYuYtUBK5e9 for <lisp@ietfa.amsl.com>; Fri, 3 Jul 2015 00:37:40 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57351A1A8C for <lisp@ietf.org>; Fri, 3 Jul 2015 00:37:39 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUQ96418; Fri, 03 Jul 2015 07:37:38 +0000 (GMT)
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jul 2015 08:37:37 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.28]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 3 Jul 2015 15:37:32 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Dino Farinacci <farinacci@gmail.com>, Fabio Maino <fmaino@cisco.com>
Thread-Topic: [lisp] WG Charter
Thread-Index: AQHQtAjOzjCgrih44k6XWK54/JDuTJ3Gbd4AgAFq8YCAAS4+YA==
Date: Fri, 3 Jul 2015 07:37:31 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0833DF40@NKGEML512-MBS.china.huawei.com>
References: <5593F6A6.9010402@joelhalpern.com> <55943528.2070409@cisco.com> <DDB406BD-B997-43D0-A6B2-B79E8DA58CC7@gmail.com>
In-Reply-To: <DDB406BD-B997-43D0-A6B2-B79E8DA58CC7@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/j3Eb7y_lYXIRwERSIS98LOyQSs0>
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] WG Charter
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2015 07:37:42 -0000

Hi Dino,

> -----Original Message-----
> From: lisp [mailto:lisp-bounces@ietf.org] 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
> >> lisp@ietf.org
> >> https://www.ietf.org/mailman/listinfo/lisp
> >
> > _______________________________________________
> > 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