Re: [lisp] WG Charter

Xuxiaohu <> Fri, 03 July 2015 07:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A73A31A1A90 for <>; Fri, 3 Jul 2015 00:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id otYuYtUBK5e9 for <>; Fri, 3 Jul 2015 00:37:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A57351A1A8C for <>; Fri, 3 Jul 2015 00:37:39 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BUQ96418; Fri, 03 Jul 2015 07:37:38 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 3 Jul 2015 08:37:37 +0100
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Fri, 3 Jul 2015 15:37:32 +0800
From: Xuxiaohu <>
To: Dino Farinacci <>, Fabio Maino <>
Thread-Topic: [lisp] WG Charter
Thread-Index: AQHQtAjOzjCgrih44k6XWK54/JDuTJ3Gbd4AgAFq8YCAAS4+YA==
Date: Fri, 3 Jul 2015 07:37:31 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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 07:37:42 -0000

Hi Dino,

> -----Original Message-----
> From: lisp [] 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,

> 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