Re: [lisp] WG Charter

Dino Farinacci <> Fri, 03 July 2015 17:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 036D31A010C for <>; Fri, 3 Jul 2015 10:17:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SDjc3bZqWSTO for <>; Fri, 3 Jul 2015 10:17:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 007541A0108 for <>; Fri, 3 Jul 2015 10:17:42 -0700 (PDT)
Received: by pdbep18 with SMTP id ep18so66656696pdb.1 for <>; Fri, 03 Jul 2015 10:17:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id ko4mr79892623pdb.77.1435943862667; Fri, 03 Jul 2015 10:17:42 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id fs16sm9688880pdb.12.2015. (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 <>
In-Reply-To: <>
Date: Fri, 3 Jul 2015 10:17:40 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Xuxiaohu <>
X-Mailer: Apple Mail (2.2102)
Archived-At: <>
Cc: LISP mailing list list <>
Subject: Re: [lisp] WG Charter
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


> 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 mailing list
>> _______________________________________________
>> lisp mailing list