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

From: Dave Hood <[email-masked]>
Date: Mon, 1 Jun 2015 17:37:59 +0000

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:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: [email-masked]
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]
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

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 1 Jun 2015 17:11:32 -0400

Dave:

Thank you for the write-up with so many interesting thoughts.  Your messages
helps bringh up two interesting cases. 

On Case 1: 

In all of these, the user who has "pure intent" exists within a context.  In
the web page, it is the web pages context for the user that can be Best Buy
or Amazon.   The document
<https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/>
draft-xia-ibnemo-icim-00
(https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/) points this out. 

On your Case 2: with E-Line between two campi.  Your intent is E-line
connect.  Actually the intent is a connection of between two campi that
carries flows of data   The context is E-line and whatever that means.  

To be practical L3VPN, L2VPN, EVPN are simply contexts for specific types of
network-wide connections.  The IETF L3SM is creating a model for such
network-wide services. 

Sue Hares 

From: sdn [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Monday, June 01, 2015 1:38 PM
To: Susan Hares; [email-masked]
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]
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

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) :

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:

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

---

From: "Lifengkai (Fengkai)" <[email-masked]>
Date: Tue, 2 Jun 2015 07:46:55 +0000

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:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: Re: [Sdn] Defining a Common Model for intent

Dave

From: sdn [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, May 30, 2015 1:02 PM
To: [email-masked]<mailto:[email-masked]>
Cc: 'Zhoutianran'; 'Xiayinben'; [email-masked]<mailto:[email-masked]>
Subject: [Sdn] Defining a Common Model for intent

Sue Hares

---

From: Dave Hood <[email-masked]>
Date: Tue, 2 Jun 2015 13:26:13 +0000

I agree that the context matters, Fengkai (and Susan in earlier response). What the I-D appears to be saying is that any interaction across an NBI is intent: otherwise the app/tenant/customer wouldn't do it. That's the root of my question from the beginning: how would we know what is *not* intent?

If I ask for some particular microscopically detailed configuration (a "how"), it's because I care, for some reason, about that level of detail. It is in fact part of my intent.

In my IT example, I argue that intent need not be independent of protocols and ports, and that it need not be portable. Your response about context appears to agree.

So as best I can tell, we can say precisely what an intent is, and we can't say what an intent is not. If intent is just the latest buzzword, which it certainly appears to be, can we just say so and leave it to the marketing people?

Dave

From: Lifengkai (Fengkai) [mailto:[email-masked]]
Sent: Tuesday, June 02, 2015 12:47 AM
To: Dave Hood; Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: RE: [Sdn] Defining a Common Model for intent

Hi Dave and all,

Best Regards,
Fengkai

From: sdn [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 1:38 AM
To: Susan Hares; [email-masked]<mailto:[email-masked]>
Cc: Zhoutianran; Xiayinben; [email-masked]<mailto:[email-masked]>
Subject: Re: [Sdn] Defining a Common Model for intent

Dave

Sue Hares

---

From: STUART VENTERS <[email-masked]>
Date: Tue, 2 Jun 2015 16:06:11 +0000

I have 2 cents to contribute for this fuzzy intent word and resulting data model.
Perhaps 'intent'  is just a relatively high level service request.
The problem with this definition is what is that 'relatively high level' appears to depend on your point of view.

To help think about it, here's a long chain of command for the same action.
It is long for fun and so that anybody can find part of it that they recognize.

Chain of command:

Investor says: make money
CEO says: make the network work
CIO says: give me bandwidths between sites A, B, and C
Net engineer says: I need these evc's to these endpoints
Purchasing agent: Says use this product from this vendor
Sales Person says: Here is the price and priority
Partitioner: divides the end to end circuit among administrative domains
Planner: picks the necessary resources to use, makes the truck rolls happen
Allocator: allocates the necessary bandwidth
Provisioner: decides what provisioning is necessary in each part of the path
Adaptor: tailors the provisioning to a specific box
Driver: pushes the provisioning into the forwarding tables
Forwarding engine: forwards according to the tables

The Investor's statement at the top is clearly what and not how.
The forwarding engine's operations have a lot of how, but maybe little global view of what we are doing overall.

If we say that the top is intent and the bottom is a is service request,
  who's to say where intent stops and service requests start?

Perhaps  'intent' means a service request coming from a higher layer for refinement.

That said, the data model for intent might/should be different at each level.
Since each level is processing the same request at different levels of detail, it might be similar at each level.
Perhaps the data model starts simple on top and gathers more and more detail as it gets lower ?
Maybe like a tree with the root at the top and leaves at the forwarding engines, except distributed.

Perhaps a simple starting point near the top is a combination of entities, endpoints, and connections.

Regards,

Stuart Venters

From: sdn [mailto:[email-masked]] On Behalf Of Dave Hood
Sent: Tuesday, June 02, 2015 8:26 AM
To: Lifengkai (Fengkai); Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: Re: [Sdn] Defining a Common Model for intent

Dave

Hi Dave and all,

Best Regards,
Fengkai

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.

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

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 19:09:02 -0400

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:[email-masked]] On Behalf Of Lifengkai
(Fengkai)
Sent: Tuesday, June 02, 2015 3:47 AM
To: Dave Hood; Susan Hares; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Dave and all,

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.

 

Best Regards,

Fengkai

EBay or somewhere else. Suppose it’s Amazon. I search Amazon’s catalog and

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.

·         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?

it’s not, I welcome suggestions to clarify the concept.

Dave

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 19:22:34 -0400

Dave:

Thank you for restating your excellent question.  "How do we know
[something] is not intent?"  

Let me start an assertion that Intent is declarative policy applied to a
context.  If you accept this assertion, 

Then:

1)      You can tell if the policy is prescriptive rather than
declarative/intent, 

2)      You can tell whether a declarative policy is presented with a
context. 

An example of declarative policy is, connect London and New York with 1 Gbps
data flow between.  How, when, where and why with what - is left up to the
fulfillment of the intent.  The context is networking and business offices.

Do you think I'm on the right track? 

Sue 

From: Dave Hood [mailto:[email-masked]] 
Sent: Tuesday, June 02, 2015 9:26 AM
To: Lifengkai (Fengkai); Susan Hares; [email-masked]
Cc: Zhoutianran; Xiayinben; [email-masked]
Subject: RE: [Sdn] Defining a Common Model for intent

I agree that the context matters, Fengkai (and Susan in earlier response).
What the I-D appears to be saying is that any interaction across an NBI is
intent: otherwise the app/tenant/customer wouldn't do it. That's the root of
my question from the beginning: how would we know what is *not* intent?

If I ask for some particular microscopically detailed configuration (a
"how"), it's because I care, for some reason, about that level of detail. It
is in fact part of my intent. 

In my IT example, I argue that intent need not be independent of protocols
and ports, and that it need not be portable. Your response about context
appears to agree.

So as best I can tell, we can say precisely what an intent is, and we can't
say what an intent is not. If intent is just the latest buzzword, which it
certainly appears to be, can we just say so and leave it to the marketing
people?

Dave

Hi Dave and all,

 

Best Regards,

Fengkai

Dave

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Jun 2015 19:34:58 -0400

Stuart: 

In some ways, the policy continuum (Davy, Jenning, Strassner) suggest the
layer of models (as ISO did) of business, system, administrator,  device,
and instance. 

I agree with you theoretically that "data model for intent might/should be
different at each level".  There is code-evidence that backs up your point.
The flexibility the Nemo early proof-of-concept demo is enhanced by the
ability to allow a data model to be pass to the controller.  The user really
just needs to signal "intent" and the model passes the context.   Nemo uses
a simple combination of entities, endpoints and connections. 

If we expanded this from the top-down, then the data model would have the
simple context of the user.  As it goes down, the model would get augment
with the context of each layer.  Much like the tree with roots at the top.  

This is a fascinating part of the discussion - can you add more details to
your comments? 

Sue 
-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Tuesday, June 02, 2015 12:06 PM
To: [email-masked]
Cc: 'Dave Hood'; [email-masked]; Lifengkai (Fengkai); Zhoutianran;
Xiayinben; Susan Hares

I have 2 cents to contribute for this fuzzy intent word and resulting data
model.
Perhaps 'intent'  is just a relatively high level service request.
The problem with this definition is what is that 'relatively high level'
appears to depend on your point of view.

To help think about it, here's a long chain of command for the same action.
It is long for fun and so that anybody can find part of it that they
recognize.

Chain of command:

Investor says: make money
CEO says: make the network work
CIO says: give me bandwidths between sites A, B, and C Net engineer says: I
need these evc's to these endpoints Purchasing agent: Says use this product
from this vendor Sales Person says: Here is the price and priority
Partitioner: divides the end to end circuit among administrative domains
Planner: picks the necessary resources to use, makes the truck rolls happen
Allocator: allocates the necessary bandwidth
Provisioner: decides what provisioning is necessary in each part of the path
Adaptor: tailors the provisioning to a specific box
Driver: pushes the provisioning into the forwarding tables Forwarding
engine: forwards according to the tables

The Investor's statement at the top is clearly what and not how.
The forwarding engine's operations have a lot of how, but maybe little
global view of what we are doing overall.

Perhaps  'intent' means a service request coming from a higher layer for
refinement.

That said, the data model for intent might/should be different at each
level.
Since each level is processing the same request at different levels of
detail, it might be similar at each level.
Perhaps the data model starts simple on top and gathers more and more detail
as it gets lower ?
Maybe like a tree with the root at the top and leaves at the forwarding
engines, except distributed.

Perhaps a simple starting point near the top is a combination of entities,
endpoints, and connections.

Regards,

Stuart Venters

Dave

Hi Dave and all,

Best Regards,
Fengkai

Dave

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 

_______________________________________________
sdn mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/sdn

---

From: Zhoutianran <[email-masked]>
Date: Wed, 3 Jun 2015 09:44:10 +0000

Hi Stuart,

Thanks for this deep thinking with a set of examples. It's really important to clarify this fuzzy intent.
I think all the concern and uncertainty is because of the layered thinking. We think intent is a relatively higher level nested.
What if we think about intent with differnet roles? Just like a relative detailed description in my "role based intent" email.
I think the essential of the role based intent is that there is only one intent layer which is always on the top. Intent is dedicated for corresponding roles. One role will not call other roles interfaces. 
Then we can try to find way to express intent for various roles.

Regards,
Terence

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Wednesday, June 03, 2015 12:06 AM
To: [email-masked]
Cc: 'Dave Hood'; [email-masked]; Lifengkai (Fengkai); Zhoutianran; Xiayinben; Susan Hares
Subject: Re: [Sdn] Defining a Common Model for intent

Chain of command:

Investor says: make money
CEO says: make the network work
CIO says: give me bandwidths between sites A, B, and C Net engineer says: I need these evc's to these endpoints Purchasing agent: Says use this product from this vendor Sales Person says: Here is the price and priority
Partitioner: divides the end to end circuit among administrative domains
Planner: picks the necessary resources to use, makes the truck rolls happen
Allocator: allocates the necessary bandwidth
Provisioner: decides what provisioning is necessary in each part of the path
Adaptor: tailors the provisioning to a specific box
Driver: pushes the provisioning into the forwarding tables Forwarding engine: forwards according to the tables

Regards,

Stuart Venters

Dave

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: "Lifengkai (Fengkai)" <[email-masked]>
Date: Wed, 3 Jun 2015 09:39:25 +0000

Hi Dave,

I think I got the point that you concern. Continuing the consideration in my last email, the intent is specific to the network users with different roles.
With the network user roles in mind, I think we can properly define what is the intent or what is not intent for the specified users. But we cannot generally defining what is or is not intent, unless the user role, from the user perspective is taken into account.

Best Regards,
Fengkai

Sent: Tuesday, June 02, 2015 9:26 PM

Dave

To: Dave Hood; Susan Hares; [email-masked]<mailto:[email-masked]>

Hi Dave and all,

Best Regards,
Fengkai

Dave

Sue Hares

---

From: Zhoutianran <[email-masked]>
Date: Thu, 4 Jun 2015 12:26:32 +0000

Hi Bert,

Thanks for you comments. 
I agree with you that we'd better just focus on the top layer.
But I am sorry, what do you mean in the last sentence?
"A role -based intent model? I guess it would just boil down in different types of intent that fit with the specific role, right?"
Could you give more information on this?

Best,
Terence

________________________________________
发件人: Bert Wijnen (IETF) [[email-masked]]
发送时间: 2015年6月3日 21:08
收件人: Zhoutianran; STUART VENTERS; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi all,

I like the idea of (at least for now) stick to the problem of "intent" for one layer (the top layer).
Let us not boil the ocean and try to do everything that comes up. If we are successful in doing
a model for IBNEMO for the top layer, we can then see if we want to go at more layers.

A role -based intent model? I guess it would just boil down in different types of intent that
fit with the specific role, right?

Bert

On 03/06/15 11:44, Zhoutianran wrote:
> Ibnemo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ibnemo
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2015 11:13:09 -0400

Bert and Tianran: 

If you link intent to role, I believe your diagram is: 

User --> intent --> role --> context 

I think role takes on an aspect of context.   What do you think? 

Sue 

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Thursday, June 04, 2015 8:27 AM
To: Bert Wijnen (IETF); STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

Hi Bert,

Thanks for you comments. 
I agree with you that we'd better just focus on the top layer.
But I am sorry, what do you mean in the last sentence?
"A role -based intent model? I guess it would just boil down in different
types of intent that fit with the specific role, right?"
Could you give more information on this?

Best,
Terence

Hi all,

I like the idea of (at least for now) stick to the problem of "intent" for
one layer (the top layer).
Let us not boil the ocean and try to do everything that comes up. If we are
successful in doing a model for IBNEMO for the top layer, we can then see if
we want to go at more layers.

A role -based intent model? I guess it would just boil down in different
types of intent that fit with the specific role, right?

Bert

On 03/06/15 11:44, Zhoutianran wrote:
> I think all the concern and uncertainty is because of the layered
thinking. We think intent is a relatively higher level nested.
> What if we think about intent with differnet roles? Just like a relative
detailed description in my "role based intent" email.
> I think the essential of the role based intent is that there is only one
intent layer which is always on the top. Intent is dedicated for
corresponding roles. One role will not call other roles interfaces.
model.
recognize.
> CIO says: give me bandwidths between sites A, B, and C Net engineer 
> says: I need these evc's to these endpoints Purchasing agent: Says use 
> this product from this vendor Sales Person says: Here is the price and 
> priority
refinement.
level.
>
> So as best I can tell, we can say precisely what an intent is, and we
can't say what an intent is not. If intent is just the latest buzzword,
which it certainly appears to be, can we just say so and leave it to the
marketing people?
>
> 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.
>
> 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.]
>
>
> 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.
>
> 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.
for Intent and Nemo:
constraints.

---

From: PEDRO ANDRES ARANDA GUTIERREZ <[email-masked]>
Date: Fri, 5 Jun 2015 06:02:51 +0000

Hi Sue,

Going back to the BGP-4 example and staying at the role level, does this
chain really stand? I mean, there are things a user will never be able to
do depending on (her|his) role. So, will s?he ever be able to express an
intent for something s?he cannot control?

Just a bit of philosophy I fear :-)

/PA

---
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 04/06/15 17:13, "Susan Hares" <[email-masked]> escribió:

>are

________________________________

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

---

From: Zhoutianran <[email-masked]>
Date: Fri, 5 Jun 2015 06:41:52 +0000

Thanks Bert for your clarification.

That's another good description on the role based intent I think.

Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 11:35 PM
To: Zhoutianran; STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

> Could you give more information on this?

Sorry for not being clear,

my thinking here is that
- intent model is basically the same for anyone.
- but based on your role, you express your intent with different (role specific)
    statements. That possibly means you use similar language (IDL) but you use
    different objects (data) to express it

So a customer/end-user says
   I want a link between location A and B, i.e. my intent is to use a connection between A & B
   and I want 1GB with low delay
The service provider who needs to implement this says things like
   Create  a physical link between A&B
   or create a logical link between A&B with guaranteed 1GB capacity

So the customer/end-user does not care about physical or logical or whatever.
Maybe he/she does not even want to know.

But the service provider of course needs to express intent about physical or logical

Does that help?

Bert

> Let us not boil the ocean and try to do everything that comes up. If 
> we are successful in doing a model for IBNEMO for the top layer, we can then see if we want to go at more layers.
>
> A role -based intent model? I guess it would just boil down in 
> different types of intent that fit with the specific role, right?
>
> Bert
>
>
>> says: I need these evc's to these endpoints Purchasing agent: Says 
>> use this product from this vendor Sales Person says: Here is the 
>> price and priority
>> order an E-line without caring about such details? [Nor is this 
>> intent portable.]
>>

---

From: Xiayinben <[email-masked]>
Date: Fri, 5 Jun 2015 13:17:18 +0000

Bert,

That is exactly same as what I understand.
I hope we could give a common intent information model for general intent components and their relationship.
Then we could define a set of intent content based on some roles as you mentioned in last mail.

Yinben

-----邮件原件-----
发件人: Ibnemo [mailto:[email-masked]] 代表 Bert Wijnen (IETF)
发送时间: 2015年6月4日 23:35
收件人: Zhoutianran; STUART VENTERS; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

my thinking here is that

Does that help?

Bert

---

From: Xiayinben <[email-masked]>
Date: Fri, 5 Jun 2015 13:10:47 +0000

In my understanding:
User expresses/owns a set of specific intent instances;
Role decides intent scope and content which is cared by the role;
User can have one or more roles.
Do you think this make sense?

Yinben

-----邮件原件-----
发件人: Ibnemo [mailto:[email-masked]] 代表 Bert Wijnen (IETF)
发送时间: 2015年6月4日 23:32
收件人: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

> User --> intent --> role --> context

Could be, but is "user" not a role.
I see roles as:
- user/end-user or customer
- service provider
- network achitect
- network operator
- maybe also trouble-shooter

Is that not the idea/

Bert
p.s. why is this copied to 2 mailing lists, sdn and ibnemo?
I thought that the intent-modelling work is in ibnemo, if so, then SDN RG people who are interested should come overthere.
Now if we were talking SDN specific intent modelling, then maybe it is OK, But I thought we are discussing generic intent modelling, no?

Bert
> "A role -based intent model? I guess it would just boil down in 
> different types of intent that fit with the specific role, right?"
> we are successful in doing a model for IBNEMO for the top layer, we 
> can then see if we want to go at more layers.
>
> intent: otherwise the app/tenant/customer wouldn't do it. That's the 
> root of my question from the beginning: how would we know what is *not* intent?
> "how"), it's because I care, for some reason, about that level of 
> detail. It is in fact part of my intent.
> and ports, and that it need not be portable. Your response about 
> context appears to agree.
> can't say what an intent is not. If intent is just the latest 
> buzzword, which it certainly appears to be, can we just say so and 
> leave it to the marketing people?
>> Dave
>>
> 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.
>> An excerpt from an email I sent on the ONF NBI list, which may 
>> contain
> some useful thoughts:
> 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?
> 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.
> 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.
> 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.
> elements of information are germane to the service it offers, and if 
> ports and protocols are germane to the service, so be it.
> 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?
> 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.
> option or the other, but the level of granularity is quite different. 
> Shall we agree that driving is too granular to be considered intent?
> 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
>>
> 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.
> 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:

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:08:01 -0400

Pedro: 

I think you are right and I am wrong in this chain.  After your posts I think that role is really a constraint of intent.    

Intent ==: object (constraint), result (constraint), constraint (constraint). 

 Where the role's constraint actually impacts what possible objects, results or constraints an intent has. 

Sue 

-----Original Message-----
From: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[email-masked]] 
Sent: Friday, June 05, 2015 2:03 AM
To: Susan Hares; 'Zhoutianran'; 'Bert Wijnen (IETF)'; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Sue,

Going back to the BGP-4 example and staying at the role level, does this chain really stand? I mean, there are things a user will never be able to do depending on (her|his) role. So, will s?he ever be able to express an intent for something s?he cannot control?

/PA

---

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

El 04/06/15 17:13, "Susan Hares" <[email-masked]> escribió:

>Let us not boil the ocean and try to do everything that comes up. If we 
>are successful in doing a model for IBNEMO for the top layer, we can 
>then see if we want to go at more layers.
>
>which it certainly appears to be, can we just say so and leave it to 
>the marketing people?
>>
>> Dave
>>
>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.
>>
>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 
>software local to my PC, but I don't think we can call the PC an SDN controller.
>It's
>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.
>>
>SDN offered my PC a packet interface with the properties of knowing how 
>to recognize and route DNS queries specially, and general IP 
>manipulation of a granular information model, the explicit visibility 
>of multiple objects, how they are interrelated, their attributes, and 
>the like.
>>
>Shall
>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.
>>
>created a definition for intent and a unified model for defining intent 
>which can handle 1 or multiple layers. The model suggest that:

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:50:45 -0400

Bert and Tianran:

I believe that you are stating regarding the definition: 

Intent == (defines)  object, result, constraint 

An IDL (intent description Langague) would be a common way to express the
object, result, and constraints.  If you use roles, I suggest that roles
provide a grouping of objects, results, and constraints.   Do you agree? 

Sue 
-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Friday, June 05, 2015 2:42 AM
To: Bert Wijnen (IETF); STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]]
Sent: Thursday, June 04, 2015 11:35 PM
To: Zhoutianran; STUART VENTERS; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

my thinking here is that
- intent model is basically the same for anyone.
- but based on your role, you express your intent with different (role
specific)
    statements. That possibly means you use similar language (IDL) but you
use
    different objects (data) to express it

   I want a link between location A and B, i.e. my intent is to use a
connection between A & B

So the customer/end-user does not care about physical or logical or
whatever.
Maybe he/she does not even want to know.

But the service provider of course needs to express intent about physical or
logical

Does that help?

Bert

> we are successful in doing a model for IBNEMO for the top layer, we can
recognize.
refinement.
level.
>> I agree that the context matters, Fengkai (and Susan in earlier
response). What the I-D appears to be saying is that any interaction across
an NBI is intent: otherwise the app/tenant/customer wouldn't do it. That's
the root of my question from the beginning: how would we know what is *not*
intent?
>>
>> In my IT example, I argue that intent need not be independent of
protocols and ports, and that it need not be portable. Your response about
context appears to agree.
>>
>> 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.
>> On this mail list, there has been a discussion of two types of
information for Intent and Nemo:
constraints.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 15:54:06 -0400

Yinben: 

Hopefully, my previous post will indicate +1 on your opinion.  Role decides
the scope/constraints and content.  It will make intent easier to implement.
A DataBase application will have a scope/constraint for its intent, and a
common language (Intent Data Language) to express it. 

Sue 

-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Xiayinben
Sent: Friday, June 05, 2015 9:11 AM
To: Bert Wijnen (IETF); Susan Hares; Zhoutianran; 'STUART VENTERS';
[email-masked]
Cc: [email-masked]
Subject: [Ibnemo] 答复: [Sdn] Defining a Common Model for intent

In my understanding:
User expresses/owns a set of specific intent instances; Role decides intent
scope and content which is cared by the role; User can have one or more
roles.
Do you think this make sense?

Yinben

-----邮件原件-----
发件人: Ibnemo [mailto:[email-masked]] 代表 Bert Wijnen (IETF)
发送时间: 2015年6月4日 23:32
收件人: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
抄送: [email-masked]
主题: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Is that not the idea/

Bert
p.s. why is this copied to 2 mailing lists, sdn and ibnemo?
I thought that the intent-modelling work is in ibnemo, if so, then SDN RG
people who are interested should come overthere.
Now if we were talking SDN specific intent modelling, then maybe it is OK,
But I thought we are discussing generic intent modelling, no?

Bert
> Could you give more information on this?
response).
>> protocols
are

---

From: Zhoutianran <[email-masked]>
Date: Mon, 8 Jun 2015 09:46:15 +0000

Hi Bert,

You raised a very interesting topic on the user and role.
I think the role groups a set of intent. And the user is the exact one to use the intent. One user could take several roles.
A quick example in real world, one person(just like me) could be a father(one role) and a programmer(another role).

Best,
Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]] 
Sent: Thursday, June 04, 2015 11:32 PM
To: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

Is that not the idea/

Bert

Bert

---

From: STUART VENTERS <[email-masked]>
Date: Mon, 8 Jun 2015 14:21:57 +0000

All,

Over the weekend I figured out what is bugging me about the word intent.

Thinking about the interface (role?) between the customer and service provider.
To provision a service, the provider needs to know the following:
   WHO the customer is. (the billing and technical contact info, perhaps a PO number, and if the customer is a residence or business)
   WHAT sort of service.  (the speeds and feeds, what packet headers the network is aware of, addressing, special things like nat or firewall,  etc)
   WHERE the service should appear. (physical location of the endpoints, maybe logical circuit ID's)
   WHEN the service should work. (Install date, maybe the 100Gig for backups only works at night?)

Conspicuously missing is the following  question:
   WHY the customer wants the service. (Perhaps the provider could provide a better service if he knew this?)

To me, the word 'intent' focuses one to think about WHY.
Saying that the service is provisioned based on intent, implys that the service provider can figure out what to do from mostly the WHY question.
This seems misleading.

That said, to figure out how to specify a service, there are all sorts of interesting questions in the who, what, where, when area.
I wonder if this is where this intent stuff should head?

-Stuart

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 8 Jun 2015 19:25:26 -0400

Tianran/Terence and Bert; 

The use of role-based to allow one entity (human or silicon) to take on
multiple roles is RBAC.   These roles are only some of the roles - but they
are abstract roles.  Another role is a Service provider who is provider's
provider as I've used in my example.   Another might be a EVPN provider
(services). 

- network architect

Sue 
-----Original Message-----
From: Ibnemo [mailto:[email-masked]] On Behalf Of Zhoutianran
Sent: Monday, June 08, 2015 5:46 AM
To: Bert Wijnen (IETF); Susan Hares; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Ibnemo] [Sdn] Defining a Common Model for intent

Hi Bert,

You raised a very interesting topic on the user and role.
I think the role groups a set of intent. And the user is the exact one to
use the intent. One user could take several roles.
A quick example in real world, one person(just like me) could be a
father(one role) and a programmer(another role).

Best,
Terence

-----Original Message-----
From: Bert Wijnen (IETF) [mailto:[email-masked]]
Sent: Thursday, June 04, 2015 11:32 PM
To: Susan Hares; Zhoutianran; 'STUART VENTERS'; [email-masked]
Cc: [email-masked]
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

Is that not the idea/

Bert

Bert
response).
are

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 8 Jun 2015 19:31:44 -0400

Stuart: 

High What and high level Why are  intent issues.  The rest (who, what,
where, when) is the context.  The question is how do we tease a part the
"pure" intent versus the context and constraint.  Can you look at this
example: 

Intent: [What] Connect my remote offices to my corporate headquarters [why]
to get Big Data input from remote offices, and results back to offices. 

Why seems to be the constraint in this description.   Is this what you were
thinking about? 

Sue 

-----Original Message-----
From: sdn [mailto:[email-masked]] On Behalf Of STUART VENTERS
Sent: Monday, June 08, 2015 10:22 AM
To: [email-masked]
Cc: 'Zhoutianran'; [email-masked]; Susan Hares; Bert Wijnen (IETF)
Subject: Re: [Sdn] [Ibnemo] Defining a Common Model for intent

All,

Thinking about the interface (role?) between the customer and service
provider.
To provision a service, the provider needs to know the following:
   WHO the customer is. (the billing and technical contact info, perhaps a
PO number, and if the customer is a residence or business)
   WHAT sort of service.  (the speeds and feeds, what packet headers the
network is aware of, addressing, special things like nat or firewall,  etc)
   WHERE the service should appear. (physical location of the endpoints,
maybe logical circuit ID's)
   WHEN the service should work. (Install date, maybe the 100Gig for backups
only works at night?)

Conspicuously missing is the following  question:
   WHY the customer wants the service. (Perhaps the provider could provide a
better service if he knew this?)

To me, the word 'intent' focuses one to think about WHY.
Saying that the service is provisioned based on intent, implys that the
service provider can figure out what to do from mostly the WHY question.
This seems misleading.

That said, to figure out how to specify a service, there are all sorts of
interesting questions in the who, what, where, when area.
I wonder if this is where this intent stuff should head?

-Stuart