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

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, June 04, 2015 8:48 PM
To: Susan Hares; 'Dave Hood'; [e-mail]
Cc: [e-mail]
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:[e-mail]] 
Sent: Friday, June 05, 2015 2:35 AM
To: Lifengkai (Fengkai); 'Dave Hood'; [e-mail]
Cc: [e-mail]
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:[e-mail]] On Behalf Of Lifengkai
(Fengkai)
Sent: Thursday, June 04, 2015 12:42 AM
To: Susan Hares; 'Dave Hood'; [e-mail]
Cc: [e-mail]
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:[e-mail]] 
Sent: Wednesday, June 03, 2015 7:09 AM
To: Lifengkai (Fengkai); 'Dave Hood'; [e-mail]
Cc: [e-mail]
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:[e-mail]] On Behalf Of Lifengkai
(Fengkai)
Sent: Tuesday, June 02, 2015 3:47 AM
To: Dave Hood; Susan Hares; [e-mail]
Cc: [e-mail]
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:[e-mail]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; [e-mail]
Cc: Zhoutianran; Xiayinben; [e-mail]
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:[e-mail]] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: [e-mail]
Cc: 'Zhoutianran'; 'Xiayinben'; [e-mail]
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