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

[Dave Hood <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, June 02, 2015 12:47 AM
To: Dave Hood; Susan Hares; [e-mail]
Cc: Zhoutianran; Xiayinben; [e-mail]
Subject: RE: [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]<mailto:[e-mail]>
Cc: Zhoutianran; Xiayinben; [e-mail]<mailto:[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]<mailto:[e-mail]>
Cc: 'Zhoutianran'; 'Xiayinben'; [e-mail]<mailto:[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