Re: [Ibnemo] Defining a Common Model for intent

["Bert Wijnen (IETF)" <[e-mail]>]

It may be jsut me, but adding "pure" intent and "impure" intent and jetstreams etc, it does just become more vague for me.

See also inline

On 04/06/15 20:41, Susan Hares wrote:
>
> Tianran/ Terrence:
>
> Instinctively, I believe that role-based intent provides an ability to define and classify intent.  I know how to identify the 
> role relationships, and the actions between roles.  However, I still do not really understand classify the relationship between 
> intent and roles.
>
> My concern is that we are looking at general system theory where certain things are first order changes and other things are 
> second-order changes.   A first order change is like the wind blowing.  A second order change is when the upper atmosphere jet 
> stream changes causing a whole shift in weather patterns.
>
> If we classify intent by roles, will we find that roles are the “jet stream” that pushes a lot of intent.  Or will we find some 
> “pure” intent classes are the jet stream that pushes a lot of intent or “jet stream” ?
>
I cannot make heads or tails from that sentence. Again, it may be just me.

Bert
>
> Best wishes,
>
> Sue
>
> *From:*Zhoutianran [mailto:[e-mail]]
> *Sent:* Thursday, June 04, 2015 2:36 AM
> *To:* Natale, Bob; Susan Hares; zhangyali (D); 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* RE: [Ibnemo] Defining a Common Model for intent
>
> Hi Bob and Sue,
>
> The role based intent gives the methodology to define and classify intent. I think both Bob and me realize the identifying roles 
> is important. And yes, it’s on the top.
>
> Of course, intent need to be implemented. We can do this compilation layer by layer, i.e., like policy continuum, from goal to 
> fitness to ECA to …. By the way, it seems in policy continuum, everything is policy, and an intent can be compiled by policies all 
> the way to device instructions. Please correct me if it is not.
>
> My idea is:
>
> On one hand, I would like a flat intent expression with many ways for both pure intent and the constrained intent.
>
> On the other hand, I think the intent can be implemented by many existing layered functions like the figure I showed. And a cross 
> layer design will make the intent implementation more flexible.
>
> I am not going to create concepts but an operational solution. I think policy continuum is an option for intent implementation, 
> but it’s not mandatory cannot escape.
>
> Best Regards,
>
> Terence
>
> *From:*Natale, Bob [mailto:[e-mail]]
> *Sent:* Wednesday, June 03, 2015 10:45 PM
> *To:* Zhoutianran; Susan Hares; zhangyali (D); 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Subject:* RE: [Ibnemo] Defining a Common Model for intent
>
> Hi Terence,
>
> As Bert has noted on a related thread today, it is sensible to focus on intent expression at the “top” layer first.
>
> However, work on that should be cognizant of two things:
>
> - Who/what are the intended consumers of such expressions?
>
> - What is the “distance” from the top level intent expressions to executable actions that affect network behavior?
>
> Those two things are interrelated and captured in the policy continuum concept and construct … you can conceptualize them 
> differently, resulting in different constructs, and that is fine … but you cannot escape them. Any attempt to escape them will 
> result, at best, in a beautiful language that will never be spoken in an operational context.
>
> Avanti,
>
> BobN
>
> *From:*Ibnemo [mailto:[e-mail]] *On Behalf Of *Zhoutianran
> *Sent:* Wednesday, June 03, 2015 5:19 AM
> *To:* Natale, Bob; Susan Hares; zhangyali (D); 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [Ibnemo] Defining a Common Model for intent
>
> Hi Bob,
>
> I agree with you that the intent expression is the first important step. And that’s what we are going to do.
>
> I think in this discussion group we will focus on the top layer intent. As I posted in the email on the “role based intent”, there 
> will be only one intent layer and I do not think the “policy continuum” works or necessarily applied here. In contrast I would 
> like a flat intent expression with many ways for both pure intent and the constrained intent.
>
> Regards,
>
> Terence
>
> *From:*Ibnemo [mailto:[e-mail]] *On Behalf Of *Natale, Bob
> *Sent:* Wednesday, June 03, 2015 1:15 PM
> *To:* Susan Hares; zhangyali (D); 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Subject:* Re: [Ibnemo] RE: Defining a Common Model for intent
>
> Hi Sue,
>
> Yes, the Formal Model paper is a very good source, but should be augmented with a few others for a more complete understanding.
>
> And it is very important to note that the policy continuum is not _/my/_ model … it is (to the best of my knowledge) John 
> Strassner’s creation and I generally recommend Chap. 9, Examples of Using the Policy Continuum, in his book on /Policy-Based 
> Network Management: Solutions for the Next Generation/ (2004) as an essential source.
>
> [Apologies for possibly rambling a bit in what follows … I am not an active contributor and I hate to take up the time of those 
> who are just because I have a few minutes to post, but since Sue asked….]
>
> I would note that the specific layer labels used in the policy continuum literature should not be considered absolute … i.e., 
> other formulations (with more or (ideally) fewer layers) are possible, with different labels, denoting (e.g.) some domain-, 
> marketplace-, or business model-specificity.
>
> The key issue is the number and nature of the translations necessary from a statement of intent at the “top” layer to a set of 
> actions at the “bottom” layer that serve to realize the intent. In John’s policy continuum the top layer is the “Business” layer 
> and we might see policy expressions like “Optimize traffic flows for fairness to all active users” or “Optimize traffic flows for 
> priority based on user account type” (e.g., the proverbial Platinum, Gold, Silver, Bronze casting). Those are deliberately stark 
> examples … in reality, the Business layer promulgates enormous numbers of policies often overlapping and “frictional” … but take 
> either stark example and consider how many translations it would take to result in a conforming set of actions in large-scale 
> network of diverse devices, services, protocols, (and a very large)  etc. In current technology (and for the foreseeable future, 
> at my age at least!) at some point such statements of intent from the Business layer have to get translated to E-C-A type rules.
>
> I recognize an intent-based policy expression by its distance from a set of expression (usually “rules”) that execute actions that 
> realize the outcome stated in the intent-based expression. In that view, it’s not an absolute (i.e., the diverse views of the 
> Policy Continuum hold) and it’s also possible to envision cases where expressions of intent can be “directly” implemented by a 
> resource or set of resources. SDN is a step in the direction of (1) reducing the number of translations necessary for a large 
> class of intent-based policy expressions and (2) virtualizing the implementation actions from the perspective of the “upper” 
> layers of the policy continuum (or continua).
>
> So, SDN and the ecosystem of changes around it represent  a big opportunity to make progress on rationalizing policy management 
> across the layers of the policy continuum. A necessary first step is having useful standards for policy-expressions from the “top” 
> layer – and they typically talk in intent-based policy expressions there.
>
> Btw, I presume that IBNemo* contributors are also following John’s work in the SUPA area as well … very important that these 
> efforts are totally complementary and synergistic, IMHO.
>
> [* - Is it “IBNemo”, “ibnemo”, “IB-nemo” or something else? … I see it written all of those ways, and possibly more....]
>
> Avanti,
>
> BobN
>
> *From:*Susan Hares [mailto:[e-mail]]
> *Sent:* Tuesday, June 02, 2015 6:26 PM
> *To:* Natale, Bob; 'zhangyali (D)'; 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Subject:* RE: [Ibnemo] RE: Defining a Common Model for intent
>
> Bob:
>
> Thank you for The Policy Continuum – A Formal Model (Steven Davy , Brendan Jennings and John Strassner). Is this the one you 
> stated we should read?
>
> http://www.tssg.org/files/archives/2007_MACE_SDavy_Jennings_final.pdf
>
> Davy, Jenning and Strassner.  In this continuum it suggests there are descending levels at: business, system (device and 
> technology independent), administrator (device independent, technology dependent), device (device and technology specific), and 
> instance (specific MIB, PIB, and CLI).  The system level is what Yali and Yinben have talked about when they speak about a 
> connection from London to Beijing.  The administrator is a level of an L3VPN network with many devices.   I have suggested a few 
> more layers that related in a gap analysis for I2NSF.  These layer match what the IETF is doing in the yang modules.
>
> +--------------------------------------------+
>
> |Application Network Wide: Intent            |
>
> +--------------------------------------------+
>
> |Network-wide level: L3SM L3VPN service model|
>
> +--------------------------------------------+
>
> |Device level: Protocol Independent: I2RS    |
>
> | RIB, Topology, Filter-Based RIB            |
>
> +--------------------------------------------+
>
> |Device Level: Protocol Yang modules         |
>
> | (ISIS, OSPF, BGP, EVPN, L2VPN, L3VPN, etc.)|
>
> +--------------------------------------------+
>
> | Device level: IP and System: NETMOD Models |
>
> | (config and oper-state), tunnels           |
>
> +--------------------------------------------+
>
> Did I understand your policy continuum?
>
> The policy continuum paper states three axioms:
>
> “1) A policy may exist at any level of the continuum without the requirement of being associated to policies at other continuum 
> levels.
>
> 2) A policy may reference a set of lower level policies.
>
> 3) A policy may be associated to more than one higher level policy”
>
> Can you explain your comment:
>
> “the “need” for multiple intermediate E-C-A translations at multiple layers of the policy continuum has heretofore been a major 
> impediment to progress on policy-based management, IMHO.”
>
> Does this come out of the formal language in the paper?
>
> Sue
>
> *From:*Natale, Bob [mailto:[e-mail]]
> *Sent:* Tuesday, June 02, 2015 1:25 AM
> *To:* zhangyali (D); PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Subject:* RE: [Ibnemo]RE: Defining a Common Model for intent
>
> With all due respect:
>
> 1. I would recommend that anyone working on this topic, if he/she has not done so already, understand the “policy continuum” 
> construct … a web search for ‘"policy continuum" Strassner’ will identify a good set of sources to start from for the network 
> management domain.
>
> 2. Intents are statements of objectives or goals … they tend  to originate at the “higher” levels of the policy continuum … at 
> some point (at “lower” layers of the policy continuum) they are translated to E-C-A type rules (more deterministic than intents) 
>  for execution … much normally happens in between.
>
> 3. Designing solutions that minimize the number of translations between the statement of intent and the execution rules is 
> essential .. and _/possibly/_ enabled by contemporary technologies via which “higher” layer intents can be translated to “lower” 
> layer intents before hitting the ultimate E-C-A execution layer. This is a highly speculative statement on my part. But the “need” 
> for multiple intermediate E-C-A translations at multiple layers of the policy continuum has heretofore been a major impediment to 
> progress on policy-based management, IMHO.
>
> The “with all due respect” aspect refers to the fact that the work that the active contributors to this thread are doing is very 
> positive even if none of my comments are acted upon.
>
> Avanti,
>
> BobN
>
> *From:*Ibnemo [mailto:[e-mail]] *On Behalf Of *zhangyali (D)
> *Sent:* Monday, June 01, 2015 11:52 PM
> *To:* PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *Subject:* [Ibnemo] 答复: Defining a Common Model for intent
>
> Hi Pedro,
>
> Thanks for reviewing the draft and giving modification.
>
> The question you have mentioned is a very important point for the abstraction of intent model. Maybe we can propose the transport 
> market as a analogy.
>
> 1.A customer wants to transport his goods from A to B. So his intent is getting his goods from A to B without carrying about how 
> to do it. Then his intent is transferred to the transportation system.
>
> 2.This system analyzes customer’s requirement, and choose a suitable way to complete the requirement. For example, the system 
> choose truck as the means. So the intent of transportation system is transferring the goods with truck.
>
> 3.The driver of this truck analyze the path from A to B, and choose a most appropriate path to complete this order which will save 
> more time. So  the intent of driver may be transferring the goods with the least time. Then the driver will start the engine, step 
> on the gas, etc.
>
> From this analogy, the ultimate effect is the same, namely, transfer the goods from A to B. But the specific intent of different 
> roles has some differences which depends on user’ role, knowledge, responsibility, etc. For example, transportation system is 
> responsible for transporting goods, and he know the various ways. So he can form his intent by rendering the upper customer’s intent.
>
> Supposing we divide users into different layers according to the implementation series, users in upper layer expresses his intent 
> as /what/ he want without having the knowledge about /how/ to do it. Then the /how/ procedure will be transferred to /what /in the 
> lower layer according to knowledge and context. These transfer procedure lead to the completion of requirement. Same with the 
> example in draft. Although the ultimate effect is same, the focus is different which will bring out the differentiation of intent.
>
> This is just my immature opinion about intent. Do you think the differentiation of intent to complete the same thing is important 
> and reasonable?
>
> Best Regards,
>
> Yali
>
> *发件人**:*PEDRO ANDRES ARANDA GUTIERREZ [mailto:[e-mail]]
> *发送时间:* 2015年6月1日 17:15
> *收件人:* Susan Hares; [e-mail] <mailto:[e-mail]>
> *抄送:* [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> *主题:* Re: [Ibnemo] Defining a Common Model for intent
>
> Hi,
>
> A small clarification proposal for draft https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/.
>
> In section 2.4, I would leave the following as a paragraph
>
> For example, in the network area the intent of end-users could be
> safe connectivity between two sites which a technology independent
> and device independent requirement. For business-based network
> designers, the network connectivity can be selected which is device-
> independent but technology specific. An example of the business-based
> technology is the L3VPN.
> And change:
> For network administrators, intent can be
> specific operations on a set of devices such as configuring IP
> addresses on network servers in a data center.
>
> To
>
> For network administrators, intent can be <new>defining a network topology like a router connected to a firewall, connected to a load balancer and this to two L2 networks where WWW servers sit or specifying the</new> operations on a set of devices such as configuring IP addresses on network servers in a data center.
>   
> Rationale behind this is again, that intent should be anything that is invariant and that expresses/what/  a network operator/administrator may need to do, as opposed to/how/  he would do that, i.e. The router is a HW device from vendor X or a virtual machine running a specific routing daemon over a given data-path implementation.
> Best, /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
>
> ------------------------------------------------------------------------------------------------------------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la 
> lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
> recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and confidential information intended only for the use of the 
> individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any 
> dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in 
> error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a 
> leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta 
> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
>
>
>
> _______________________________________________
> Ibnemo mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ibnemo