Re: [Ibnemo] 答复: 答复: [Sdn] Defining a Common Model for intent

PEDRO ANDRES ARANDA GUTIERREZ <pedroa.aranda@telefonica.com> Tue, 16 June 2015 11:12 UTC

Return-Path: <pedroa.aranda@telefonica.com>
X-Original-To: ibnemo@ietfa.amsl.com
Delivered-To: ibnemo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BAF1B3253 for <ibnemo@ietfa.amsl.com>; Tue, 16 Jun 2015 04:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.091
X-Spam-Level:
X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_29=0.6, LOTS_OF_MONEY=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 u4GZ1jC2tvpV for <ibnemo@ietfa.amsl.com>; Tue, 16 Jun 2015 04:11:55 -0700 (PDT)
Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D26C1B3060 for <ibnemo@ietf.org>; Tue, 16 Jun 2015 04:11:52 -0700 (PDT)
Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4DA06E0272; Tue, 16 Jun 2015 13:11:50 +0200 (CEST)
Received-SPF: PermError (tgtimjc804.telefonica.com: domain of pedroa.aranda@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=pedroa.aranda@telefonica.com; helo=ESTGVMSP101.EUROPE.telefonica.corp)
Received: from ESTGVMSP101.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 2F17DE021A; Tue, 16 Jun 2015 13:11:50 +0200 (CEST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 16 Jun 2015 13:11:49 +0200
Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0621.eurprd06.prod.outlook.com (10.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.190.14; Tue, 16 Jun 2015 11:11:46 +0000
Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0190.013; Tue, 16 Jun 2015 11:11:46 +0000
From: PEDRO ANDRES ARANDA GUTIERREZ <pedroa.aranda@telefonica.com>
To: DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com>, "Bert Wijnen (IETF)" <bwietf@bwijnen.net>
Thread-Topic: [Ibnemo] 答复: 答复: [Sdn] Defining a Common Model for intent
Thread-Index: AQHQqAkNxGCG74JulEubNltpFpIVrJ2u0xoAgAAokID//+pTAIAAB1QAgAAuhQA=
Date: Tue, 16 Jun 2015 11:11:46 +0000
Message-ID: <D1A5CF97.1E164%pedroa.aranda@telefonica.com>
References: <00f301d09b13$79cc2410$6d646c30$@ndzh.com> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CD945@nkgeml505-mbs.china.huawei.com> <013e01d09ef5$190b6e20$4b224a60$@ndzh.com> <865C20BAAE8BBD4C89E7D6FE694F6B3B2D3CDF47@nkgeml505-mbs.china.huawei.com> <021a01d09fb6$e1c51c00$a54f5400$@ndzh.com> <80B0B523-E50E-46F8-9FDC-CC861D2BF96E@telefonica.com> <A747A0713F56294D8FBE33E5C6B8F58129514E55@szxeml513-mbx.china.huawei.com> <1BCA2E06-E15A-46C5-9ED5-7A1042CB3DAE@telefonica.com> <A747A0713F56294D8FBE33E5C6B8F58129515001@szxeml513-mbx.china.huawei.com> <50DE494F-5E08-426A-AAA0-3D9269CC131F@telefonica.com> <A747A0713F56294D8FBE33E5C6B8F581295151A1@szxeml513-mbx.china.huawei.com> <7DA15C94-271A-412E-A4C7-F7F15AABEB1E@telefonica.com> <A747A0713F56294D8FBE33E5C6B8F58129515677@szxeml513-mbx.china.huawei.com> <557FBE42.3020900@bwijnen.net> <A747A0713F56294D8FBE33E5C6B8F581295156DD@szxeml513-mbx.china.huawei.com> <557FE37C.3050509@bwijnen.net> <D1A5B3E4.1E12F%pedroa.aranda@telefonica.com> <557FF354.5070104@bwijnen.net> <26654089-CAD7-4916-8D93-99F001E07AAF@telefonica.com>
In-Reply-To: <26654089-CAD7-4916-8D93-99F001E07AAF@telefonica.com>
Accept-Language: es-ES, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.1.150515
authentication-results: telefonica.com; dkim=none (message not signed) header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [195.235.92.36]
x-microsoft-exchange-diagnostics: 1; DB4PR06MB0621; 3:OmvK8vqi8ctYtNKR2vQM9SB2zWU+wR5MzuHl6Em2QtELbZfKNgSoO8hQ3xeMAvOtBHu7bwZMBSmv+EBzfNMVk39KcFyf9RD/e4Ae1luL6V+boSvzR8+aFlqT/VwAHAMwCslgBK//GeTjXXXV9Ztc6A==; 10:w/BhTC4uQhWrPaHGQR4Z9LEfzi8CJtr8+3oA8mPsBRn2mwiqlTy6pURxOv6wssAKySSBVEPTss896mV229Vjb67k8GOudoMpyxJzICsc1+I=; 6:w0ya/Vx/ixNtj7BotQlxhbd7s0GRIPdDwQ/suS+SBgOM57Gu35/ohckLilz0Ta9J
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621;
x-microsoft-antispam-prvs: <DB4PR06MB062129851F2D0AF16E241A3E9BA70@DB4PR06MB0621.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621;
x-forefront-prvs: 06098A2863
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(52604005)(479174004)(76104003)(40134004)(24454002)(252514010)(87936001)(83506001)(5001960100002)(2656002)(77156002)(19580405001)(92566002)(19580395003)(5001770100001)(19617315012)(40100003)(122556002)(86362001)(5002640100001)(36756003)(224303003)(106116001)(4001350100001)(189998001)(46102003)(16236675004)(76176999)(50986999)(77096005)(2950100001)(2900100001)(102836002)(66066001)(575784001)(554214002)(551934003)(54356999)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: multipart/alternative; boundary="_000_D1A5CF971E164pedroaarandatelefonicacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2015 11:11:46.0799 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: <http://mailarchive.ietf.org/arch/msg/ibnemo/o8bggVfoEcDA8d16DidpQ0MdAfo>
Cc: "sdn@irtf.org" <sdn@irtf.org>, "zhangyali (D)" <zhangyali369@huawei.com>, Dave Hood <dave.hood@ericsson.com>, Susan Hares <shares@ndzh.com>, "ibnemo@ietf.org" <ibnemo@ietf.org>
Subject: Re: [Ibnemo] 答复: 答复: [Sdn] Defining a Common Model for intent
X-BeenThere: ibnemo@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of Nemo, an intent-based North Bound \(NB\) interface consisting of an application protocol running over HTTP \(RESTful interfaces\) to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources \(networks, storage, CPU\)." <ibnemo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ibnemo/>
List-Help: <mailto:ibnemo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ibnemo>, <mailto:ibnemo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 11:12:07 -0000

Completely agree. I might be overusing the infrastructure example. But it’s just that: an example. I’m more interested in nailing down the different “dimensions” than things that are inside one of those dimensions. I use the term dimension, because IMHO the different sets (as Bert calls them) are orthogonal in that using something in one set doesn’t preclude anything for the other sets.

Best, /PA

PS: And yes, I’m interesting in the network-near set or dimension because there are a couple of nice characteristics there (recursion to mention one) which cold make our lives a lot easier.
De: DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>>
Fecha: martes, 16 de junio de 2015 12:24
Para: "Bert Wijnen (IETF)" <bwietf@bwijnen.net<mailto:bwietf@bwijnen.net>>
CC: PEDRO ANDRES ARANDA GUTIERREZ <pedroa.aranda@telefonica.com<mailto:pedroa.aranda@telefonica.com>>, "zhangyali (D)" <zhangyali369@huawei.com<mailto:zhangyali369@huawei.com>>, "sdn@irtf.org<mailto:sdn@irtf.org>" <sdn@irtf.org<mailto:sdn@irtf.org>>, Dave Hood <dave.hood@ericsson.com<mailto:dave.hood@ericsson.com>>, Sue Hares <shares@ndzh.com<mailto:shares@ndzh.com>>, "ibnemo@ietf.org<mailto:ibnemo@ietf.org>" <ibnemo@ietf.org<mailto:ibnemo@ietf.org>>
Asunto: Re: [Ibnemo] 答复: 答复: [Sdn] Defining a Common Model for intent

Hi,

Just let me remark we should not pre-define once and forever the views and roles for expressing intent, but define mechanisms for expressing those views and roles, and for combining them when a certain user happens to have several of them available. It would be interesting to have some predefined ones indeed, but hardwiring them would be a great mistake.

Be goode,

On 16 Jun 2015, at 10:58 , Bert Wijnen (IETF) <bwietf@bwijnen.net<mailto:bwietf@bwijnen.net>> wrote:

Inline

On 16/06/15 11:16, PEDRO ANDRES ARANDA GUTIERREZ wrote:
Answers inline...

---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler




El 16/06/15 10:51, "Bert Wijnen (IETF)" <bwietf@bwijnen.net<mailto:bwietf@bwijnen.net>> escribió:

Yali,
Let me try to restate/explain my views again.
As I said, it may be just me. Or maybe my background that I have in areas
of RBAC and such things.

Earlier in this thread I have stated:

   I see roles as:
   - user/end-user or customer
   - service provider
   - network achitect
   - network operator
   - maybe also trouble-shooter

I think you had stated that you sort of liked that list. Maybe I
misunderstood.
That is also my understanding
Good. we're in sync here then
So based on your role, you get access to the set of "intent expressions"
that belong to your role.
That access is based on a system that uses RBAC (I would think).
Yes, but that is just one of the dimensions of intent.

Then I also think there is a second dimension of intent that will simplify
many things and that is what I call infrastructure intent:

Based on the ‘a router is a router is a router’ principle, there are
invariants in network boxes (router, switch, etc.). And on top of this, we
can also identify network blocks that can be composed of network boxes.
And composing network blocks, we can create networks.

This infrastructure intent, will most probably bed used directly by
network architects and indirectly by other roles.
So are we saying the same but in different words?
When you say "dimensions of intent", do you think that matches (or is similar to) my
"sets of intent expressions"?
And then there is also a third dimension regarding security invariants.
Yes, there is a set of intention expressions aka:
- I want my link from A to B encrypted with the most recent/most secure encryption mechanisms".
A person in the "user" role might make such an expression:
- I want the link from A to B to be encrypted using security mechanism SHA-1
That might expressed by  an architect or operator.

But still, there will be some RBAC system that decides if an end user can or cannot
express an intent at the specific mechanism level (e.g. SHA-1) , and that role probably
should not be allowed to such a specific expression of intent (however this touches
on policy applied to the underlying system I guess).

Bert
"intent role" seems a weird concept to me. If you/others think that it
exists, then I am
probably still very much confused.

Bert

On 16/06/15 09:49, zhangyali (D) wrote:
Hi Bert,

Sorry for not expressing my meaning explicitly. According to my
understanding (have not confirmed with Diego), the relationship
between access roles and intent roles can be show below.

图片1.png

Access role restrict the scope of available objects and actions, and
according to different network abstraction views, access role
could express result/actions in high level. This high level part will
be our intent role.

That is just my understanding, please point it out if it is wrong.

Best,

Yali

-----邮件原件-----

发件人: Bert Wijnen (IETF) [mailto:bwietf@bwijnen.net]

发送时间: 2015年6月16日14:12

收件人: zhangyali (D); DIEGO LOPEZ GARCIA

抄送: sdn@irtf.org<mailto:sdn@irtf.org>; Dave Hood; Susan Hares; ibnemo@ietf.org<mailto:ibnemo@ietf.org>

主题: Re: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

Sorry, but I suspect I am getting confused again.

Roles are roles in my view. And based on your role, you get access to
ceratin things (types of intent expressions you can tell to
the system).

The access control to the various "intent expressions" will be based on
a role.

And so you have RBAC. Or am I still confused here?

Bert

On 16/06/15 04:40, zhangyali (D) wrote:

Hi, Diego,
Definitely agree with you. Ore-defining general roles is difficult and
unreasonable because of the diversity of systems and variability of
dividing perspective. However, pre-defining some typical roles that
consist with most network system will be helpful for us to analyze
intent common information model.

As you have explained the difference of functional roles and access
roles, I think they are two dimensions of roles, that is, access roles
defines the scope of functional roles. But I have a doubt is that
access roles just define scope of network abstraction who would not
express intent. In ICIM (Intent Common Information Model), user own one
or
more roles and express intent, so user is the combination of functional
roles, do you agree that?

Best,
Yali
*发件人:*DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com]
*发送时间:*2015年6月14日18:41
*收件人:*zhangyali (D)
*抄送:*Susan Hares; sdn@irtf.org<mailto:sdn@irtf.org>; Dave Hood; ibnemo@ietf.org<mailto:ibnemo@ietf.org>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Yali,
Defining some typical roles and their pre-defined views (in terms of
actions that are available to them) makes sense to me. What I'd like
to avoid is to freeze that set of predefined roles as the only ones
suitable
to be used from the functional point of view.

Be goode,
On 11 Jun 2015, at 04:28 , zhangyali (D) <zhangyali369@huawei.com<mailto:zhangyali369@huawei.com>
<mailto:zhangyali369@huawei.com>> wrote:

Hi Diego,
Agree with you. We do not need to predefine roles in a system because
of the diversity of systems and roles. And if a user could tie
multiply roles, it needs a rule to restrict the combination.

But when we consider a common intent model, maybe we can try to define
some typical roles in network system and analyze the real intent of
each role. For example, Pedro has provided some typical roles, such
as, end-user, service provider, network architecture, network operator,
etc.
Do you think this way make sense?

Best,
Yali
*发件人:*DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com]
*发送时间:*2015年6月11日0:49
*收件人:*zhangyali (D)
*抄送:*Susan Hares; sdn@irtf.org<mailto:sdn@irtf.org> <mailto:sdn@irtf.org>; Dave Hood;
ibnemo@ietf.org<mailto:ibnemo@ietf.org> <mailto:ibnemo@ietf.org>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Yali,
Nothing to excuse about. We are discussing here to understand one
another.

I don't think we should predefine the roles by any means, just provide
support in the language to define the, What I refer to when talking
about compositional semantics was about defining how the views
(available objects or invariants as Pedro says) or permissions
(operations allowed) for a user can be built by combining the
different roles a user can have. We'd need to define precedence rules
(or a
similar mechanism) to solve conflicts and avoid inconsistencies, which
may become a source of serious security breaches.

Be goode,
On 10 Jun 2015, at 04:17 , zhangyali (D) <zhangyali369@huawei.com<mailto:zhangyali369@huawei.com>
<mailto:zhangyali369@huawei.com>> wrote:

Hi Diego,
Sorry for mistake your idea, and thanks for giving me a clarification.
I do think these mapping of roles are important in designing intent
modeling.

For you said that “we should a clear role compositional semantics”, do
you have some consideration about what roles we should have or the
principle of classification?

Best,
Yali
*发件人:*DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com]
*发送时 间:*2015年6月10日5:33
*收件人:*zhangyali (D)
*抄送:*Susan Hares;sdn@irtf.org<mailto:sdn@irtf.org> <mailto:sdn@irtf.org>; Dave
Hood;ibnemo@ietf.org<mailto:ibnemo@ietf.org> <mailto:ibnemo@ietf.org>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Yali,
I'd not say there are two classifications of roles, but two mapping of
roles onto the intended modeling language. One related to the
abstraction available to each role, and the other in terms of a security
model
that identifies which operations a role can invoke.

And yes, roles define a different dimension than users. A role, for
sure, can be assigned to several users. And a user can have several
roles, though in that case we should a clear role compositional
semantics.

Be goode,
On 9 Jun 2015, at 04:03 , zhangyali (D) <zhangyali369@huawei.com<mailto:zhangyali369@huawei.com>
<mailto:zhangyali369@huawei.com>> wrote:

Hi Diego,
Thanks for your consideration about the concept of role. From my
understanding about your type of role (please point it out if my
understanding is not right), you think there are two classification
methods of roles overall. One method is distinguish roles depending
on their operation scope, which focus on which roles are restricted to
do some
specific operations. Another method for distinguish roles by network
abstraction model layer, and in any abstraction model, user
could express specific intent.

In my opinion, these two methods are important to understand the
meaning of roles. The constraint of intent content is related with
user’s roles. For example, database in the whole system could not be
deleted by non-administrators. So non-administrators’intent could
not express the intent of deleting system. So users’role will
constraint users’intent.

In one network abstraction view, users roles could express their
intent which depend on this abstraction view. While in some cases,
one user may contain several roles, so one user can express various view
of
intent. Do you have any comments about this?

Best,
Yali
*发件人:*DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com]
*发送时间:*2015年6月7日1:41
*收件人:*Susan Hares
*抄送:*sdn@irtf.org<mailto:sdn@irtf.org> <mailto:sdn@irtf.org>; Dave Hood;ibnemo@ietf.org<mailto:ibnemo@ietf.org>
<mailto:ibnemo@ietf.org>
*主题:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Sue,
I tend to agree with your idea of roles, though I'd say that in the
concept of role we are discussing here I see two aspects that could
(should?) be addressed separately.

On the one hand, we have the role as a security concept, defining what
a particular user is allowed to do or not do, and therefore RBAC would
become the natural solution for the security model to be applied to
intent expressions. The language should support mechanisms to define
such roles and to associate these roles to users and to intent
expressions by identifying the objects, results or conditions that can
be invoked in a expression by a certain role.

On the other, we have role as modeling element: depending on the role
they have, users would be able to see a different network model, and
to employ different intent expressions. This has to do with the
particular network abstraction being accessible to each role, and would
require the modeling language to support the definition of "abstraction
views" and associating them with roles.

I hope it is clear to all that in both cases the ability to make
specific expressions for a certain role is limited, though limitations
are enforced at different points in the processing of the
expressions, and they imply different requirements on the modeling
language and the
platform(s) supporting it. And, as far as I can tell, supporting both
would be highly desirable...

Be goode,
On 5 Jun 2015, at 19:41 , Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>
<mailto:shares@ndzh.com>> wrote:

Fengkai:
The key point about roles is where do they fit within the network-SQL
Diego talks about.  The basic concepts from
draft-xia-ibnemo-icim-00 make sense to me as part of the SQL
Usersà(have) intentà(expressed) in context
Intent (is made of) ==  object (constraint in node, connection, flow
), results (constraint in expect/avoid), operation (constraint, in
condition and action)
If Roles are a type of intent, then there must be a qualifier on our
intent definition above).

If role are constraints that impact object, result, and operation,
then we can model roles by simply indicating what constraint the role
plays.  In Nemo, we create a model that provides a model for network
objects (nodes, connection, and data flows/action.

If a role forms a grouping of constraints (or class), you can
translate roles to a set of pre-defined properties that can be
associated with a pre-defined type of objects (Node, link, and
dataflow/action), or results (Expect/Avoid p2pconnect or mp2mpconnect),
or
operations (Flows of 1 Gbps).

What does this mean for the user?  The network SQL sets up libraries
to define roles because it is simply constraints on the components of
intent.

What do you think of my idea of roles? I can give this as business
(non-network, or Provider business), or as a end-user role.

Sue
*From:*Lifengkai (Fengkai) [mailto:lifengkai@huawei.com]
*Sent:*Thursday, June 04, 2015 8:48 PM *To:*Susan Hares; 'Dave
Hood';sdn@irtf.org<mailto:sdn@irtf.org> <mailto:sdn@irtf.org> *Cc:*ibnemo@ietf.org<mailto:ibnemo@ietf.org>
<mailto:ibnemo@ietf.org>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
Sue and all,
Yes, they are concepts with roles taken into consideration.  Here a
little further explanation:

I think grouping of roles by level is just one way, but not should be,
and the key point here is roles. We are trying to define intent with
the role classifications (the other thread in this mail list).

For the accurate intent for each categories of different networks
users, theirs roles appears fundamentally important and are the basis
for the definition.

I think role identification and distinguishing should be the
potential work.

Sue, any thoughts about this potential work? And how about others?
Thanks.
Best Regards,
Fengkai
*From:*Susan Hares [mailto:shares@ndzh.com] *Sent:*Friday, June 05,
2015 2:35 AM *To:*Lifengkai (Fengkai); 'Dave Hood';sdn@irtf.org<mailto:sdn@irtf.org>
<mailto:sdn@irtf.org> *Cc:*ibnemo@ietf.org<mailto:ibnemo@ietf.org> <mailto:ibnemo@ietf.org>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
Fengkai and all:
I agree with Yali that context is often omitted.   Thank you for
filling in these business roles to the 2 site example.  In all of

these, I believe we have grouping of roles by level under the users
intent
HQ manager userànetwork manager(s)àindividual user(s)
It appears that at each level the intent is related, but at each level
the intent’s (object, result and constraint) is refined into a
different concept due to different roles.  Is this what it appears to
you?

Sue
*From:*Ibnemo [mailto:ibnemo-bounces@ietf.org]*On Behalf Of*Lifengkai
(Fengkai) *Sent:*Thursday, June 04, 2015 12:42 AM *To:*Susan Hares;
'Dave Hood';sdn@irtf.org<mailto:sdn@irtf.org> <mailto:sdn@irtf.org> *Cc:*ibnemo@ietf.org<mailto:ibnemo@ietf.org>
<mailto:ibnemo@ietf.org>
*Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Sue and all,
For the example, I see Yali has given one in her email, just copying
here:

“For example, an end-user wants to make the communication between two
sites is the minimum. For this intent, price is the context.

Though context is omitted usually, it is really an important factor
to affect the decision.”

I would like to add one more example for better understanding of the
concept, and I would like to elaborate it from the point of user’s
roles.

Enterprise A has one headquarter and three branches located
separately, and the product department within enterprise A has one
sub-department in headquarter and each branch.

Based on the product division, the product department manager wants:
1.sub-department in each branch can communicate with sub-department in
headquarter
2.sub-department in each branch cannot communicate with each other
3.product department want to enjoy better quality of experience with a
budget limit of $50,000
Then for the“User-intent-context”format,
ØUser, enterprise user with department manager role
ØIntent, sub-department connection between headquarter and braches
ØContext, better of quality of experience within the budget
For the network manager of the enterprise A, based on the product
department manager’s requirements, the network manager wants:

1.connects the product sub-departments via: a) full mesh topology with
ACLs for communication constraints between subnets; b)leased line
between subnets.

2.SLA parameters configuration for guarantee the quality of experience
Then for the“user-intent-context”format,
ØUser, enterprise user with network manager role
ØIntent, topology set up for communication connection between subnets
ØContext, SLA parameters for quality of experience guaranteeing
Here is the example that I proposed for the illustration, more
specially with roles involved.

Thanks.
Best Regards,
Fengkai
*From:*Susan Hares [mailto:shares@ndzh.com] *Sent:*Wednesday, June 03,
2015 7:09 AM *To:*Lifengkai (Fengkai); 'Dave Hood';sdn@irtf.org<mailto:sdn@irtf.org>
<mailto:sdn@irtf.org> *Cc:*ibnemo@ietf.org<mailto:ibnemo@ietf.org> <mailto:ibnemo@ietf.org>
*Subject:*RE: [Ibnemo] [Sdn] Defining a Common Model for intent
Fengkai:
In this you are talking about the difference between the IT and Non-IT
person’s context of an intent within a role.  I believe your examples
show that
Useràintentàcontext
is very important as
https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/states. I am
still struggling to understand how the

“fitting”works.  Can you provide additional examples?
Sue
*From:*Ibnemo [mailto:ibnemo-bounces@ietf.org]*On Behalf Of*Lifengkai
(Fengkai) *Sent:*Tuesday, June 02, 2015 3:47 AM *To:*Dave Hood; Susan
Hares;sdn@irtf.org<mailto:sdn@irtf.org> <mailto:sdn@irtf.org> *Cc:*ibnemo@ietf.org<mailto:ibnemo@ietf.org>
<mailto:ibnemo@ietf.org>
*Subject:*Re: [Ibnemo] [Sdn] Defining a Common Model for intent
Hi Dave and all,
Thanks for proposing the two valuable intent use cases.
For the use case 2, I agree that the IT employee needs to include the
details of ports/protocols into his/her intent descriptions, but those
may not be in the intent context scope of a non-IT employee. Have a
further consideration with this, different users of the network have
their own intent in a specific domain. Then the roles/actors of
network users, such as end users, application developers, tenant
IT/network
administrators, operator network administrators, are valuable to be
identified and distinguished, thus fitting the intent
requirements of the network users with different roles.

Any thoughts about this consideration?
Best Regards,
Fengkai
*From:*sdn [mailto:sdn-bounces@irtf.org]*On Behalf Of*Dave Hood
*Sent:*Tuesday, June 02, 2015 1:38 AM *To:*Susan Hares;sdn@irtf.org<mailto:sdn@irtf.org>
<mailto:sdn@irtf.org> *Cc:*Zhoutianran; Xiayinben;ibnemo@ietf.org<mailto:ibnemo@ietf.org>
<mailto:ibnemo@ietf.org>
*Subject:*Re: [Sdn] Defining a Common Model for intent
An excerpt from an email I sent on the ONF NBI list, which may
contain some useful thoughts:

I have always had trouble understanding what an intent really is, so
I am looking forward to making the concept more precise.

When I click a link on a web page, I express an intent to invoke
whatever that link offers. Completely below the surface is a layer
stack, on-demand session establishment, DNS look-ups, server load
balancers, and any number of other technological features that are of no
interest to me. Why not use that as an example of intent?

Better yet, we talk about negotiation and selection. Suppose I want to
buy a widget. I probably already have some idea whether I want to go
to Amazon or EBay or somewhere else. Suppose it’s Amazon. I search
Amazon’s catalog and receive an offer of several widgets, some new,
some used, some with a choice of colour or other pertinent features.
If I see nothing I like, I may open a new browser window and check out
Best
Buy or EBay (lots more hidden technology to make that happen!). Maybe I
come back to the Amazon page, having found nothing I liked
better somewhere else. Now I accept one of the offered widgets and go
through the checkout process.

Do we agree that this is a fairly pure expression of intent as
conceptualized in the paper? (If not, let’s talk about making a Skype
call.)
Ok, that’s my intent as an internet user. Let’s assume the network is
all SDN of one kind or another. I invoke my intent through a GUI onto
software local to my PC, but I don’t think we can call the PC an SDN
controller. It’s more an active mediator, a client to an SDN. As far
as the network is concerned, the client makes DNS queries and swaps
opaque TCP packets over a forwarding path that may already exist, or may
need to be learned and set up on demand. This is about right, because
the session content may well be encrypted end to end, and
rightly.

To the SDN controller, my intent is satisfied by directing DNS queries
to a known DNS server somewhere, and ensuring IP connectivity for the
subsequent session. Hmmm…what happened to our intent-based NBI? The
SDN offered my PC a packet interface with the properties of knowing
how to recognize and route DNS queries specially, and general IP
connectivity. My PC accepted the service offer implicitly by offering
traffic to
the data-plane interface. The network could be performing associated
auxiliary services such as usage-based billing (think
wireless roaming), so it’s more than just a dumb pipe.

If this is not a legitimate example of intent, it would be good to
write the white paper in such a way that clearly excludes such cases.
Use case 2: suppose I am a corporate IT employee, and suppose that my
intent is to have an E-Line between two of my campi. I necessarily
care about ports and protocols; talk about intent being portable and
protocol independent continues to confuse me completely. How can I
order an E-line without caring about such details? [Nor is this intent
portable.]
Obviously, an SDN controller is going to expose whatever actions and
elements of information are germane to the service it offers, and if
ports and protocols are germane to the service, so be it.

The SDN architecture, being recursive, models the north side of any
controller as exposing an instance of an information model, customized
for the intended client/customer/app/user. That being the case, how do
we distinguish an NBI API that conveys intent
(service: same thing?) from one that does not?
I have recently come to the view that granularity is the criterion by
which an intent or service invocation is distinguished.

Colloquially speaking, a service invocation is a single invocation
across the API: give me E-Line. Now of course this turns into
constraint negotiation, offer and acceptance, but what happens across
the API is effectively one transaction. In contrast, what we might
agree is **not** an intent or a service is the manipulation of a
granular
information model, the explicit visibility of multiple objects, how
they are interrelated, their attributes, and the like.

·Network as a single lump vs some non-trivial topology.
·Chauffeur vs driving a car. Legitimate reasons to choose one option
or the other, but the level of granularity is quite different. Shall
we agree that driving is too granular to be considered intent?

This idea of granularity and detailed operations on the components
(which of course may be complex entities themselves, virtualized into
simple-appearing lumps) seems to me to capture the essence of what
people are talking about when they say intent or service. I am not
comfortable with the way I am expressing it, so if this is a step in a
productive direction, or even if it’s not, I welcome suggestions to
clarify the concept.

Dave
*From:*sdn [mailto:sdn-bounces@irtf.org]*On Behalf Of*Susan Hares
*Sent:*Saturday, May 30, 2015 1:02 PM *To:*sdn@irtf.org<mailto:sdn@irtf.org>
<mailto:sdn@irtf.org> *Cc:*'Zhoutianran'; 'Xiayinben';ibnemo@ietf.org<mailto:ibnemo@ietf.org>
<mailto:ibnemo@ietf.org> *Subject:*[Sdn] Defining a Common Model for
intent
On this mail list, there has been a discussion of two types of
information for Intent and Nemo:

(http://www.ietf.org/mail-archive/web/sdn/current/msg00646.html) :
1)What information is needed to represent a service request,
2)How to represent and transport the information for a request.
In order to define what information is needed to represent a 1)
service request that signals Intent from an application to a
controller, it is important to define Intent, and provide a clear
model of Intent. Also, in describing real use-cases it is important that
one
uses the same definition and model for Intent in each use case.

In the current forums examining Intent (ODL NIC, ODL Nemo, OF NBI and
Keystone, OPNFV Movie, OpenStack) there is a realization that Intent
occurs at multiple layers.  The authors of draft-xia-ibnemo-icim have
created a definition for intent and a unified model for defining
intent which can handle 1 or multiple layers. The model suggest that:

1)A user has a intent that is expressed in a context.
2)Intent (usually) involves an object with a result, and optionally
includes operations toward that result.

3)Operations conditions perform actions within/modified by
constraints.

We believe this defines clearly what others are calling “pure
intent”(objects + results) versus “constrained intent”(objects +

operations + constraints).   The draft can be found at:
https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/. The authors are

looking for feedback on the concepts in the draft.
Sue Hares
_______________________________________________
Ibnemo mailing list
Ibnemo@ietf.org<mailto:Ibnemo@ietf.org> <mailto:Ibnemo@ietf.org>
https://www.ietf.org/mailman/listinfo/ibnemo
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail:diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
<mailto:diego.r.lopez@telefonica.com>

Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------
Este mensaje y sus adjuntos se dirigen exclusivamente a su
destinatario, puede contener información privilegiada o confidencial y
es para uso exclusivo de la persona o entidad de destino. Si no es
usted. el destinatario indicado, queda notificado de que la lectura,
utilización, divulgación y/o copia sin autorización puede estar
prohibida en virtud de la legislación vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and
confidential information intended only for the use of the individual
or entity named above. If the reader of this message is not the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this transmission in error, do not read it. Please
immediately reply to the sender that you have received
this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu
destinatário, pode conter informação privilegiada ou confidencial e é
para uso exclusivo da pessoa ou entidade de destino. Se não évossa
senhoria o destinatário indicado, fica notificado de que a leitura,
utilização, divulgação e/ou cópia sem autorização pode estar proibida
em virtude da legislação vigente. Se recebeu esta mensagem por erro,
rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail:diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
<mailto:diego.r.lopez@telefonica.com>

Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------
Este mensaje y sus adjuntos se dirigen exclusivamente a su
destinatario, puede contener información privilegiada o confidencial y
es para uso exclusivo de la persona o entidad de destino. Si no es
usted. el destinatario indicado, queda notificado de que la lectura,
utilización, divulgación y/o copia sin autorización puede estar
prohibida en virtud de la legislación vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and
confidential information intended only for the use of the individual
or entity named above. If the reader of this message is not the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this transmission in error, do not read it. Please
immediately reply to the sender that you have received
this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu
destinatário, pode conter informação privilegiada ou confidencial e é
para uso exclusivo da pessoa ou entidade de destino. Se não évossa
senhoria o destinatário indicado, fica notificado de que a leitura,
utilização, divulgação e/ou cópia sem autorização pode estar proibida
em virtude da legislação vigente. Se recebeu esta mensagem por erro,
rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail:diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
<mailto:diego.r.lopez@telefonica.com>

Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------
Este mensaje y sus adjuntos se dirigen exclusivamente a su
destinatario, puede contener información privilegiada o confidencial y
es para uso exclusivo de la persona o entidad de destino. Si no es
usted. el destinatario indicado, queda notificado de que la lectura,
utilización, divulgación y/o copia sin autorización puede estar
prohibida en virtud de la legislación vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and
confidential information intended only for the use of the individual
or entity named above. If the reader of this message is not the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this transmission in error, do not read it. Please
immediately reply to the sender that you have received
this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu
destinatário, pode conter informação privilegiada ou confidencial e é
para uso exclusivo da pessoa ou entidade de destino. Se não évossa
senhoria o destinatário indicado, fica notificado de que a leitura,
utilização, divulgação e/ou cópia sem autorização pode estar proibida
em virtude da legislação vigente. Se recebeu esta mensagem por erro,
rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/
e-mail: diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
<mailto:diego.r.lopez@telefonica.com>

Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------
----------------------------------------------------------------------
--------------------------------------------------------------
Este mensaje y sus adjuntos se dirigen exclusivamente a su
destinatario, puede contener información privilegiada o confidencial y
es para uso exclusivo de la persona o entidad de destino. Si no es
usted. el destinatario indicado, queda notificado de que la lectura,
utilización, divulgación y/o copia sin autorización puede estar
prohibida en virtud de la legislación vigente. Si ha recibido este
mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and
confidential information intended only for the use of the individual
or entity named above. If the reader of this message is not the
intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this transmission in error, do not read it. Please
immediately reply to the sender that you have received
this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu
destinatário, pode conter informação privilegiada ou confidencial e é
para uso exclusivo da pessoa ou entidade de destino. Se não évossa
senhoria o destinatário indicado, fica notificado de que a leitura,
utilização, divulgação e/ou cópia sem autorização pode estar proibida
em virtude da legislação vigente. Se recebeu esta mensagem por erro,
rogamos-lhe que nos o comunique imediatamente por esta mesma via e
proceda a sua destruição
_______________________________________________
Ibnemo mailing list
Ibnemo@ietf.org<mailto:Ibnemo@ietf.org>
https://www.ietf.org/mailman/listinfo/ibnemo
_______________________________________________
Ibnemo mailing list
Ibnemo@ietf.org<mailto:Ibnemo@ietf.org>
https://www.ietf.org/mailman/listinfo/ibnemo

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------




---
Dr. Pedro A. Aranda Gutiérrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telefónica, Investigación y Desarrollo
C/ D. Ramón de la Cruz,84
28006 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição