Re: [Ideas] Your Input requested: Charter Proposal New Version

Dino Farinacci <farinacci@gmail.com> Fri, 11 August 2017 04:11 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C12132021 for <ideas@ietfa.amsl.com>; Thu, 10 Aug 2017 21:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PxJGtH3_glDt for <ideas@ietfa.amsl.com>; Thu, 10 Aug 2017 21:11:41 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 DDE78131D1D for <ideas@ietf.org>; Thu, 10 Aug 2017 21:11:40 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id t86so2431939pfe.1 for <ideas@ietf.org>; Thu, 10 Aug 2017 21:11:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uInAXt7/T36r18CQk+G6dfMVfuAm194LWFPPvv9CiEo=; b=KM+2WzasYQOPXLWQ2nsCS2kZ9fa/zSI2yoxzp7mqvhO6SvflATryTErPW1UeyCUtt7 NHvCh1AKPaxAI1ThbLoCQXwlwy40EF6DUVkUmHUoG9cx3VVtgL4PMCvn7rC8TWvsQQtE YJT5bbXQj6P5zjsxtRTZhH5gtl9NagLTG0Iv0aeSfwqY4ug6RJl4/Xs8LfodCYrmgUoj ihCYR7h0we6Z1VKex6CS6BCgUvSla8ylvyoQa2nF/le14Vf8RDl7SNEJ/9T/mx+vIsMj VrMOzBU0UBfQhCAo1AFM0zy0MCIvVYA24NU1BlmBgg0SFpACiGuSRh6R7NzxLkgkrsYP 67mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uInAXt7/T36r18CQk+G6dfMVfuAm194LWFPPvv9CiEo=; b=LHcgf2jq60sJ+Ur/5UP/7x3+53BAt9F87GGTOk+bCg2a0oHbJkg0BSd7Afu+gpM8Gy AGFeoBlesNob6gV/y8wuGJposZKrWsSThj+7T8wIJC577Gy9PLqi0ET+hN3uIAQ/W8Gx ka3zod8DLa4IazWQ7gsWvzQr7H6DLTsG0xPqgTmwIL3AH6Mav+y/XNQ3x73gjeEuEiYr qEaUDscScUPTLD+vv/3q5P3jt4DyvmhYCqX4FV65MIQAG6xrnCw82Qc3/l4+w0H0xhz/ UWWaFggWStQjZDR8pYwCYI2JUiBPl30V2CyArfXPaVgRFPmhgAho5qPGibqb8sWL3CmU rVVg==
X-Gm-Message-State: AHYfb5gmED5woHARBLDyMoCIBC/knTV+mxMPOvXSTqaLybclgPbrRfDp uOHkFv1Ck3EwXw==
X-Received: by 10.98.76.201 with SMTP id e70mr15046298pfj.262.1502424700483; Thu, 10 Aug 2017 21:11:40 -0700 (PDT)
Received: from [10.0.18.198] ([64.65.188.150]) by smtp.gmail.com with ESMTPSA id g79sm13543655pfd.163.2017.08.10.21.11.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 21:11:39 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAG-CQxovAnF9Y4HWMFRndPvayTUQJZVxgZo49WWTJUEpjMm-Lw@mail.gmail.com>
Date: Thu, 10 Aug 2017 21:11:38 -0700
Cc: Padma Pillay-Esnault <padma@huawei.com>, Tom Herbert <tom@herbertland.com>, "ideas@ietf.org" <ideas@ietf.org>, Alexander Clemm <alexander.clemm@huawei.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CDA80D6-C463-4E5E-891D-2BE29251A705@gmail.com>
References: <CAG-CQxpxDXxLXdu0a2GdBRfTFLM_C+jqCz58HoNim52C7Yzr8g@mail.gmail.com> <CALx6S35qzym9quRRdv-TFDJW-hRXe+iGi8Db5T16JD8mExbr4w@mail.gmail.com> <CAG-CQxoWTrhhTD7gOyceDn+WEKqDfa11rqv2810Hdg028z4Ygg@mail.gmail.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0ED16F@SJCEML703-CHM.china.huawei.com> <EC7A99B9A59C1B4695037EEB5036666B026FED52@SJCEML702-CHM.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0E0ED3A0@SJCEML703-CHM.china.huawei.com> <EC7A99B9A59C1B4695037EEB5036666B026FF77B@SJCEML702-CHM.china.huawei.com> <CAG-CQxovAnF9Y4HWMFRndPvayTUQJZVxgZo49WWTJUEpjMm-Lw@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/L8DMB7y0pF58wrphtsm0q7PkMS0>
Subject: Re: [Ideas] Your Input requested: Charter Proposal New Version
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Aug 2017 04:11:42 -0000

> Please send your comments and feedback on the list.

Enclosed are my brief comments. Sorry for the delay but I’m on vacation.

> At the same time, end users require greater privacy for their networking information and protection from outside threats, while operators demand greater operational efficiency. Identity-enabled networks aim to enable networking applications and services that provide a high degree of privacy and control of end points over their networking data, coupled with greater inherent security than provided by today’s networks.  

I would add “… control of end points over their identity address, location address, and data coupled with …”.

> To this end, the working group shall:
> 
> - define and develop a common mapping system, control plane, and related protocol that provide a common solution for identifier/locator protocols that map identifiers to locators as well other new mapping combinations as needed, as well as network virtualization protocols that map virtual to physical addresses

I don’t know why there the use of the word “common” appears throughout. The charter really shouldn't intend to interoperate existing locator/ID split protocols so I would say “define and deploy a mapping system”.

And the existing locator/ID split protocols have their respective control-planes optimized for the tradeoffs they set out to design. Having something that works for all of them, to attempt interoperation, not only doesn’t make sense, but will make them run inefficiently and probably make them not useful.

> Specifically, the IDEAS WG is chartered to work on these areas for the modular framework:
> 
> - Definition of primitives for interworking with identifier-location split protocols

This isn’t useful to anyone. Having a HIP host talk to a LISP host solves nothing. It just creates complexity. And what if the LISP host has an IPv4 EID? 

This will cause a misinterpretation of the usefulness of locator/id split. I believe this should not be in the charter.

> - Identifier/locator mapping and resolution (e.g. discovery, pub/sub, multihoming, ...)
> 
> - Registration and lifecycle management of identities and their associated identifiers.
> 
> - Identity authentication and authorization (e.g. access to framework, update of information for identifiers..) 
> 
> - Definition and enforcement of basic networking policies (e.g. ability to look up an identifier-locator pair, permit forwarding traffic for particular endpoints on a per-identity basis…)
> 
> - Identity and Identifier Metadata (only fixed or slow changing, e.g. type)
> 
> - Management aspects and Data Models where appropriate.

The above items are all useful and need to be defined and more importantly deployed, so we can experiment with the solutions that meet the requirements of this working group.

> The IDEAS WG will collaborate with other Working Groups to ensure interoperability with LISP, HIP, ILA and other relevant work. Furthermore, it will try to reuse technologies already developed when appropriate.

I think the IDEAS WG should work with these working groups to make sure their control planes are extended to meet the requirements from IDEAS. But not to make them interoperate.

Dino