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

[PEDRO ANDRES ARANDA GUTIERREZ <[e-mail]>]

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" <[e-mail]> escribió:

>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:[e-mail]] On Behalf Of Zhoutianran
>Sent: Thursday, June 04, 2015 8:27 AM
>To: Bert Wijnen (IETF); STUART VENTERS; [e-mail]
>Cc: [e-mail]
>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
>
>________________________________________
>发件人: Bert Wijnen (IETF) [[e-mail]]
>发送时间: 2015年6月3日 21:08
>收件人: Zhoutianran; STUART VENTERS; [e-mail]
>抄送: [e-mail]
>主题: 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:
>> 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:[e-mail]] On Behalf Of STUART VENTERS
>> Sent: Wednesday, June 03, 2015 12:06 AM
>> To: [e-mail]
>> Cc: 'Dave Hood'; [e-mail]; Lifengkai (Fengkai); Zhoutianran;
>> Xiayinben; Susan Hares
>> Subject: Re: [Sdn] Defining a Common Model for intent
>>
>>
>>
>> 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:[e-mail]] On Behalf Of Dave Hood
>> Sent: Tuesday, June 02, 2015 8:26 AM
>> To: Lifengkai (Fengkai); Susan Hares; [e-mail]
>> Cc: Zhoutianran; Xiayinben; [e-mail]
>> 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
>>
>> 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]
>> 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
>>
>> _______________________________________________
>> sdn mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/sdn
>>
>> _______________________________________________
>> Ibnemo mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ibnemo
>>
>_______________________________________________
>sdn mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/sdn
>
>_______________________________________________
>Ibnemo mailing list
>[e-mail]
>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