Re: [Ibnemo] Defining a Common Model for intent

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

Bob: 

 

Glad we are both +1 on the need for both sides of Tianran/Terrence’s diagram.   On the right side debate,  I agree we should begin with the following consumers: 

 

1)      Who: Business entities, end-user customer entities, or non-profit organizations 

2)      What distance model from executable

In order to know where to place: 

3)      Yang/informational model 

 

I agree that the left side “intent-engine”, controller” and “run-time system” show distance.  However, one thing that the top-level language (e.g. Nemo) can provide to bridge the distance is the casting of the context at the top-level model into lower level definitions for components of intent (object, results, constraints).

 

An example may help.  Business intent says “connect all Rite-Start corporate offices together”.  The business SLAs and corproate translate this intent into a model of 5 Rite-Start corporate offices, p2p connections, with a data flow rate of 5 Gbps.  Or in intent terms: 

 

Intent (objects: 5 Rite-start offices, 5 p2p links, constraint), 

            results (5 Gps Data Flows, constraint), 

            constraint (SLA, cost).

Roles/classes of intent provide general constraints for objects, results, constraints which can be amended by specific constraints. 

 

We can borrow these concepts of roles/classes from the SQL environment that created a general way to model DBs which could then be tailored. 

 

What do you think? 

 

Sue 

 

From: Natale, Bob [mailto:[e-mail]] 
Sent: Friday, June 05, 2015 12:23 AM
To: Susan Hares; 'Zhoutianran'; [e-mail]
Cc: [e-mail]
Subject: RE: [Ibnemo] Defining a Common Model for intent

 

Agreed (on the need to understand both sides). 

 

As I noted earlier, successful development of the standards needed for the right side diagram must 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?

 

In the left side diagram, the intended consumer of intent expressions from the right side is the “Intent Engine” and the “Controller”, “Intent Engine”, “Run-time System”, and the network elements are all components of the “distance” from top-level intent expressions to network behavior.

 

Now, if we were producing the right side outputs for a single “Intent Engine” or a collection of them that operate identically, life would be simpler and my two constraints would be much easier to satisfy. But producing for a single consumer is only viable where there is a predominant de jure or de facto solution out there … no such thing exists for “Intent Engine” at this time … indeed, you should remove the “Open Source” label from the diagram, IMHO … we don’t want to exclude COTS products or private tools (do we?)

 

So, like Diego’s “Network SQL” analogy, we need to design a solution that (1) meets the requirements we set for IBNEMO as a means of expressing intents in the networking domain and (2) is compelling (effective and efficient) enough for wide adoption among (at a minimum) developers of “Intent Engines”.

 

Avanti,

BobN

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Thursday, June 04, 2015 2:56 PM
To: 'Zhoutianran'; Natale, Bob; [e-mail]
Cc: [e-mail]
Subject: RE: [Ibnemo] Defining a Common Model for intent

 

Tianran/Terrence: 

 

We should consider both.  By considering the models, we will begin to understand the limits of our working system and how it fits best into the IETF set of systems of configuration, policy, and security.    I wish my email responses could include a sound button for cheers.  You deserve one for this one. 

 

Sue 

 

From: Ibnemo [mailto:[e-mail]] On Behalf Of Zhoutianran
Sent: Thursday, June 04, 2015 5:04 AM
To: Natale, Bob; Susan Hares; [e-mail]
Cc: [e-mail]
Subject: Re: [Ibnemo] Defining a Common Model for intent

 

Hi Bob and Sue,

 

I think our discussion falls into two categories: one is the intent modeling and intent expression, and the other is how to translate the intent into real implementations. And Bob shared opinion on the later, right?

The following figure I posted before shows my point on how to work with the two parts.

Do you think we should consider both of the two topics here?

 

 

Terence

 

intent network arch.gif

 

From: Natale, Bob [mailto:[e-mail]] 
Sent: Thursday, June 04, 2015 10:58 AM
To: Susan Hares; Zhoutianran; zhangyali (D); 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [Ibnemo] Defining a Common Model for intent

 

Hi Sue,

 

You said: “I also need to start at the top since I think I know what intent is there.  I’m not sure what it looks like going downward….”

 

That is a perceptive comment. The closer you get to the instance level – i.e., where network behavior can actually be controlled – the more applicable are E-C-A type expressions relative to Intent type expressions.

 

Highly advanced components move that pattern closer and closer to the instance execution context (e.g., via custom firmware, intelligent agents)  and that capability might become way more common in the future – when, among other things, standards support for interoperable Intent expressions exists :-) --  but for now “rule” expressions, rather than “goal” expression, come into play fairly high up in the continuum … and bear in mind that, for now, Intent (“goal”) expressions at the topmost layer(s) are often _manually_ converted to E-C-A rulesets for consumption at some lower layer(s) … a source of much cost and operational inefficiency.

 

Avanti,

BobN

 

From: Susan Hares [mailto:[e-mail]] 
Sent: Wednesday, June 03, 2015 10:18 PM
To: 'Zhoutianran'; Natale, Bob; 'zhangyali (D)'; 'PEDRO ANDRES ARANDA GUTIERREZ'; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [Ibnemo] Defining a Common Model for intent

 

Tianran: 

 

Are you sure the two are distinct? I like your concept to focus on the top layer – because I think I know what happens there.  However, your intent at the top sitting on the top of several roles made me wonder if you and John are expressing an inherent general system property of the intent and policy systems. 

 

Groups of roles will request different functions.  This roles form hierarchical trees rooted in the intent.  Is John’s general architecture really the classing of roles and functions at different level?  Is  he understand what constitutes the intent roles at the top.  

 

I also need to start at the top since I think I know what intent is there.  I’m not sure what it looks like going downward (unless it is a reply of the ISO layer models).  

 

Did this help refine your idea at all?  Or am I just musing on the comparison between your ideas and John’s policy continuum. 

 

Sue 

 

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]
Cc: [e-mail]; [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]
Cc: [e-mail]; [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