Re: [lisp] WG Charter

Terry Manderson <terry.manderson@icann.org> Fri, 03 July 2015 01:07 UTC

Return-Path: <terry.manderson@icann.org>
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 532251AD0C1 for <lisp@ietfa.amsl.com>; Thu, 2 Jul 2015 18:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 FSInIFBmWCxA for <lisp@ietfa.amsl.com>; Thu, 2 Jul 2015 18:07:20 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87CA1AD0BB for <lisp@ietf.org>; Thu, 2 Jul 2015 18:07:20 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 2 Jul 2015 18:07:18 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 2 Jul 2015 18:07:18 -0700
From: Terry Manderson <terry.manderson@icann.org>
To: Dino Farinacci <farinacci@gmail.com>, Fabio Maino <fmaino@cisco.com>
Thread-Topic: [lisp] WG Charter
Thread-Index: AQHQtAjVmK05q0UEc0igBjvP3d7DpJ3HaVMAgAFq8YCAATnVAA==
Date: Fri, 03 Jul 2015 01:07:17 +0000
Message-ID: <D1BC1719.63D2E%terry.manderson@icann.org>
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: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3518766432_103183037"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/ONgq-UL7B8gt5Xgb7TywhOmRTis>
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 01:07:22 -0000

Regular participant hat on.

On 3/07/2015 2:23 am, "Dino Farinacci" <farinacci@gmail.com> wrote:

>> Joel, Luigi,
>> thanks for starting this conversation.
>
>Yes, thanks for bringing up and providing leadership.

+1 !!

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

Making the spec PS fits the envisaged evolution of the LISP "experiment".
The downside here might be that this is also recognition that LISP does
not fix the _global_ routing scalability issue (presuming of course that
the issue remains) in any short term exercise due to the way operators
actually choose to run BGP. Is the global internet ready and willing to
separate the locator and identifier in operations yet? I don't think so.

I would certainly say that it makes intra-AS routing systems leaner, as a
very positive outcome.

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

I think the scrutiny came through multiple different lenses. Not just
global routing scalability. I also doubt that the scrutiny will diminish.
But I do like the idea of calling it what it really is. It's an overlay
with attractive properties.

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

Take care to not leave the door _wide_ open. I look at LISP as a very
(very!) well reviewed specification that currently is not overweight with
unused/unnecessary features. I have a concern that having all and sundry
adding in their pet feature may cause that attribute to suffer. Perhaps it
would be sane to pick the 4-5 priority items and work on those, nail them
and move forward that way.

Cheers
Terry