Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"

Uma Chunduri <uma.chunduri@huawei.com> Wed, 05 July 2017 23:40 UTC

Return-Path: <uma.chunduri@huawei.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 1AA71131463 for <ideas@ietfa.amsl.com>; Wed, 5 Jul 2017 16:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 FZu-5ik0Q-9S for <ideas@ietfa.amsl.com>; Wed, 5 Jul 2017 16:40:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD98A129AAD for <ideas@ietf.org>; Wed, 5 Jul 2017 16:40:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJV04830; Wed, 05 Jul 2017 23:40:35 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Jul 2017 00:40:34 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.142]) by SJCEML703-CHM.china.huawei.com ([169.254.5.136]) with mapi id 14.03.0301.000; Wed, 5 Jul 2017 16:40:29 -0700
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Robert Moskowitz <rgm-ietf@htt-consult.com>, tjw ietf <tjw.ietf@gmail.com>
CC: "ideas@ietf.org" <ideas@ietf.org>
Thread-Topic: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"
Thread-Index: AQHS9ZPE963S1drr902KkhfKflevlaJFubYAgAAC9gCAABhC4IAAe9cA//+RvFA=
Date: Wed, 05 Jul 2017 23:40:28 +0000
Message-ID: <25B4902B1192E84696414485F5726854019E2956@SJCEML702-CHM.china.huawei.com>
References: <9084360a-160e-944a-96aa-0b33379ccdb8@htt-consult.com> <CADyWQ+FK7AJA4vvKG9oT+EwRVJkGWU7iiw62jCpLykxJeqeuGg@mail.gmail.com> <1788bf20-2ee5-c2fd-0108-ff4b2b779848@htt-consult.com> <25B4902B1192E84696414485F5726854019E2929@SJCEML702-CHM.china.huawei.com> <e5c17a49-9e54-8a1b-ec0d-a6ca5238af39@htt-consult.com>
In-Reply-To: <e5c17a49-9e54-8a1b-ec0d-a6ca5238af39@htt-consult.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.54]
Content-Type: multipart/alternative; boundary="_000_25B4902B1192E84696414485F5726854019E2956SJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.595D78F4.0073, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.142, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a9c7c8d0e79e69d1888db5d6c56bb68a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/2bN6pm6Je4qE63OHNgzm1-LPbsY>
Subject: Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"
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: Wed, 05 Jul 2017 23:40:41 -0000

Bob,

In-line [Uma]:

--
Uma C.

From: Robert Moskowitz [mailto:rgm-ietf@htt-consult.com]
Sent: Wednesday, July 05, 2017 4:06 PM
To: Uma Chunduri <uma.chunduri@huawei.com>; tjw ietf <tjw.ietf@gmail.com>
Cc: ideas@ietf.org
Subject: Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"

Uma,

In your list below, DHT is something (that is flat name space) that LDAP does poorly.
[Uma]: Thx for clarifying that. But flat space or not is completely a different discussion.. (and has to be discussed too)
  But LDAP IS a mapping system that has been around for lots of years.
And it has authentication in terms of who can add/update and who can inquire on what.
And EAP is NOT minimal RTT!
[Uma]:  You are right of course. We may not need minimal RTT in some cases and mutual AUTH (can be debatable). I see,  40+ EAP methods give the spectrum of all choices.
It is often yet another wrapper to have some common wrapper.  In this case, it would be PANA delivering EAP.
[Uma]: Indeed, some lower layer is required to carry EAP. As PS talks about we need a private channel for AUTH and policy updates.
So we will discuss this all.
[Uma]: Yes, we need to discuss a bit on this.


Bob
On 07/05/2017 06:58 PM, Uma Chunduri wrote:
Hi Bob,

> I said 'requirements' to soften the blow, so to speak, about 'why NOT LDAP'.  Plus the data model to see if it can fit into an LDAP schema.
> Of course we could always go with DAP instead for richer policy control and distributed data support!

I am not sure if this would be LDAP or something else. I presume the context is entities authentication and subsequent operations to indicate policy. Is this correct?

If Yes, I have couple of thoughts:


1.      We ought to focus on category of entities (low power/regular nodes/routers) and see what suits best. Perhaps one of the EAP methods suitable to the environments (minimal RTTs, mutual authentication if needed in some cases)?

2.      Regarding policy - I see your point of "richer policy" but we may have to start with much more simpler policy (say white list/black list on Identifiers) as some of it has to be distributed/shared across without any privacy concerns

3.      Regarding distribution of public parts of policy and other information with Identifiers, we ought to see if we have to use any existing mapping servers (DDT, DHT, Blockchain or some simplified/selective pull based "new" protocol among each providers Identifiers).

May be we might have to discuss problems and requirements bit deeper to hash out the above.
--
Uma C.

From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of Robert Moskowitz
Sent: Wednesday, July 05, 2017 7:16 AM
To: tjw ietf <tjw.ietf@gmail.com><mailto:tjw.ietf@gmail.com>
Cc: ideas@ietf.org<mailto:ideas@ietf.org>
Subject: Re: [Ideas] draft-padma-ideas-problem-statement and "Common Infrastructure"

Tim,

Well it seems I got an upgrade to contributing to the problem statement.  I missed that in the last go around hours before the draft cutoff.  Thanks Padma.

I said 'requirements' to soften the blow, so to speak, about 'why NOT LDAP'.  Plus the data model to see if it can fit into an LDAP schema.

Of course we could always go with DAP instead for richer policy control and distributed data support!  (was it actually 20 years ago that I worked on this stuff? yikes!)

Bob

On 07/05/2017 10:05 AM, tjw ietf wrote:


Bob!

Brian and I had chatted briefly about charter direction and we wanted to hear some of the discussions during the session. And that's what they pay us the big bucks for!

But I have to agree with your plan of attack.  If we could give some guidance:

- work on the problem statement and gap analysis but don't invest larger cycles of time on them.

- requirements are good to capture, but we will shy away from turning them into published documents as they will change over time

- some discussion on LDAP is very necessary as the code base has gotten quite mature.

tim

On Wed, Jul 5, 2017 at 9:35 AM, Robert Moskowitz <rgm-ietf@htt-consult.com<mailto:rgm-ietf@htt-consult.com>> wrote:
Disclaimer:  I had a hand in edits to this version, though I am not listed in the Ack section.  In particular I pushed for "Common Infrastructure", not "Common Control Plane".


We have been talking a lot about Identity and Identifier and metadata.  One of the tasks of this workgroup (and charter item) needs to be data modeling of what is intended to be stored/available.

Further there needs to be Yet Another Gap Analysis (YAGA?  :) ) on why NOT LDAP or some other mature xyz data store access protocol.  I start with LDAP as there is actually a fit, and the various server implementations are very mature with good, secure, backends and data replication tools.

It is time to start thinking charter.  The problem statement, gap analysis, and use cases is barely a start.  What the group is going to DO is focus now.

So I propose two work items:

Common Infrastructure data modeling (and someone other than me can do it in YANG).
Common Infrastructure protocol requirements with a subsection on LDAP comparision.

Bob


_______________________________________________
Ideas mailing list
Ideas@ietf.org<mailto:Ideas@ietf.org>
https://www.ietf.org/mailman/listinfo/ideas






_______________________________________________

Ideas mailing list

Ideas@ietf.org<mailto:Ideas@ietf.org>

https://www.ietf.org/mailman/listinfo/ideas





_______________________________________________

Ideas mailing list

Ideas@ietf.org<mailto:Ideas@ietf.org>

https://www.ietf.org/mailman/listinfo/ideas