Re: [lisp] WG Charter

Dino Farinacci <farinacci@gmail.com> Fri, 03 July 2015 17:17 UTC

Return-Path: <farinacci@gmail.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 036D31A010C for <lisp@ietfa.amsl.com>; Fri, 3 Jul 2015 10:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 SDjc3bZqWSTO for <lisp@ietfa.amsl.com>; Fri, 3 Jul 2015 10:17:43 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007541A0108 for <lisp@ietf.org>; Fri, 3 Jul 2015 10:17:42 -0700 (PDT)
Received: by pdbep18 with SMTP id ep18so66656696pdb.1 for <lisp@ietf.org>; Fri, 03 Jul 2015 10:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QatGXMo6uH+wASuB/6f1r3SROWAF8cVeeX1bDP0xksU=; b=Oz8xLoC3bcGgedQylaxAAkYaD6WZbutEDtp7dMc2inrayXc7PtC4lXmM8q6dSRYxd0 9sopFVw410yFAZGVUvCx0+V3bILB8AWcS0JaJmKeVqDpQoH0ZxQFrEyT2yWk7fNDMl8S fAyxSYXMnOTVmRYb4jgRsIuXRls6yPKhZ0tXu9q9rG/AHEmzz+1WNBE4U7PfbA6Y4wt+ K9Bc1FSKWFpS3zc3Wn4q6wOlV5p8osxCrXOrLP3Iid2HMHQCXp4DYRNHJ2e9R4i5VQ6L NjoHyA3pR1aSIVkH/PSAkPBWWb+/iMjeOedRpECT55r0IblwZB3cDKP0QIrykHMvjg9U XQsQ==
X-Received: by 10.70.118.196 with SMTP id ko4mr79892623pdb.77.1435943862667; Fri, 03 Jul 2015 10:17:42 -0700 (PDT)
Received: from [172.20.10.2] (mobile-166-171-251-080.mycingular.net. [166.171.251.80]) by mx.google.com with ESMTPSA id fs16sm9688880pdb.12.2015.07.03.10.17.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jul 2015 10:17:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0833DF40@NKGEML512-MBS.china.huawei.com>
Date: Fri, 3 Jul 2015 10:17:40 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B28EBFE9-9AF6-4D21-AED8-F774E6AD799B@gmail.com>
References: <5593F6A6.9010402@joelhalpern.com> <55943528.2070409@cisco.com> <DDB406BD-B997-43D0-A6B2-B79E8DA58CC7@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0833DF40@NKGEML512-MBS.china.huawei.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/5DBwdoEwzpPGFXWUXuAhbP6KLkM>
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 17:17:45 -0000

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