Re: [Ibnemo] Clearing up some misconceptions, part 1: Technical Questions

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

John:

 

A few questions:

 

1.       On roles:  In the discussion, Diego suggested that there were three
types of roles: security, infrastructure, and customer intent.   These roles
are  objects that are “responsibilities”. The question under discussion was
– is there any hierarchy in object these roles suggest? 

 

Why is the hierarchy of these roles practically important?  The operators
are hoping that the objects bound within the role of a customer will give
input to the business logic systems that guide the creation infrastructure.
The operational needs suggest that roles regarding infrastructure and
security also guide this business logic. 

 

2.       Intent linked to roles 

You consider that it is very hard to have “Intent being expressed by
different Roles (Actors)” .   You suggest that the policy for a router and a
firewall are different because you do not know which verb to utilize
(forward/drop or accept/reject).   

 

The key role to start with is the customer’s role.  

 

The customer role is constrained by the business logic that influences by
the objects contained in the infrastructure role and the security role.
Therefore, does the dialog language provide a grammar that can clearly state
these constraints? 

 

You state: “The policy continuum defines the contexts for different roles in
the system. If you don't want to use roles, the policy continuum defines
context for all policies, whether they are intent-based or not”.  If this is
true, please try to provide the policy continuum’s context for three simple
use cases: 

 

a)      The Virtual network case – (London and Beijing office, wants a flow
at X)  

b)      The DC case (describing data center processing), 

c)       the home network case (home network with parental controls). 

 

 

3.       On context versus Intent:
<https://datatracker.ietf.org/doc/draft-xia-ibnemo-icim/>
draft-xia-ibnemo-icim-00 is trying to separate the concepts of user, intent,
and context. 

 

You state “Context can influence intent, but only if the system allows it.”
This is beauty of the Nemo language.   It states network intent (node,
connection, flow) and context in the model and the policy.  

 

John- you are right that that userà intentà role à context if examined as a
linear logical train – is not sensible.    However, it is important to
understand how: users exists with role, intent, and context.  Your example
of: 

 

                Role: customer 

                My intent: access by code server 

                Business rule: only  allow code access through intranet
connection 

               Context: Authenticated in L3VPN 

               My result: denied 

   

         Includes:  a user with a role, intent, context, and a business
rule. 

 

What is your business rule?  Is it constraint? If so, how is it an input to
intent?  Let us rename your business rule to an organizational rule –
because all organizations have rules regarding what roles can do.  T

 

4.        Intent – relationship of object, result  or object, operation 

 

We do not have a precise definition of intent linguistically in the
draft-xia-ibnemo-icm-00.txt.   If your datalog syntax provide a “purely
declarative and mathematically formal” language, can it provide an example
of how to signal intent for:

 

d)      The Virtual network case – (London and Beijing office, wants a flow
at X)  

e)      The DC case (describing data center processing), 

f)       the home network case (home network with parental controls). 

 

        I would appreciate you sending your NOMS 2006 proposal. 

 

 

5.       I agree that growing formalism would help this work. 

 

Sue Hares 

 

 

 

From: Ibnemo [mailto:[e-mail]] On Behalf Of John Strassner
Sent: Thursday, June 18, 2015 8:23 PM
To: [e-mail]
Subject: [Ibnemo] Clearing up some misconceptions, part 1: Technical
Questions

 

Hi all,

 

I was asked to look at this thread. So I spent the last three days reading
every message in the archive between 22/01/2015 and 16/06/2015 (197
messages). Rather than issue 100 or so replies, I thought I would condense
my feedback into a series of emails that had specific groups of topics. This
is email #1.

 

There are a number of serious misconceptions that, when fixed, will
hopefully allow faster progress to be made. The short summary of these is as
follows:

 

1. Roles.

Roles have been formally designed since at least 1997 (Dirk Bäumer, Dirk
Riehle, Wolf Siberski, and Martina Wulf, "The Role Object Pattern", PLoP).

Roles are succinctly defined as objects that represent one or more
responsibilities of another entity. Period. They do not "select" things,
grant special powers, or cook lunch. They simply represent the
responsibilities of one or more actors or objects. (As an aside, this is why
the NIST RBAC standard defines users, roles, permissions, operations, and
objects as five different types of entities).

 

Still don't believe me? From INCITS 359, the NIST RBAC standard:

   "Role - A role is a job function within the context of an 

    organization with some associated semantics regarding

    the authority and responsibility conferred on the user

    assigned to the role."

 

This list talks of the roles played by an actor, such as a Customer vs. a
NetworkAdmin. The "role" did not grant the NetworkAdmin the power to
reconfigure a router interface. The role simply identified this as a
responsibility of a person or group playing this role; it is up to that
entity and the management system to implement and enforce the
reconfiguration.

 

There are a number of software design patterns that use roles for great
value. The policy servers that I have built in the last 15 years have all
used the role-object pattern; in fact, I have invented some new role-based
patterns. The advantage of roles are many, but a role has nothing to do with
intent (see 4 below).

 

Some people have said that "one role will not call other roles". This is
incorrect. The literature (and especially NIST) talks about hierarchical
roles (that is level 2 of the NIST RBAC spec, by the way). Of course roles
can interact with other roles - that is why they are full-fledged objects.

 

Finally, some people have talked about layers of roles. I agree with Bert,
intent should be at the "top layer". Roles do not have a relationship with a
layer. 

 

2. Context.

Context is a set of information and data that MAY affect the outcome of an
event, but more importantly, is a definition of the environment in which
something is happening, has happened, or will happen. Context is used to
understand what is, has, or will happen. Therefore, context can NOT be
intent. Context can influence intent, but only if the system allows it.

 

For example, my intent is to cross the road. The context is that cars are
driving at 60 miles per hours on the road. Context is NOT a parameter to my
intent in this example; if I am foolish enough to play Frogger with real
cars, I deserve what I get. However, the context COULD influence me to wait
for a better chance to cross the road, or take a taxi, or do any number of
things. My intent has not changed because of context; however, my intent
could be influenced by context if I choose to let it.

 

This applies at lower levels as well. My intent is to have Gold service. My
context is that I am directly connected through a switch with one hardware
queue. In this case, Gold == Silver == Bronze, because with one hardware
queue, it doesn't matter what I **want**, I am only going to get what the
hardware is capable of delivering.

 

I would encourage you all to read some of the DEN-ng papers on context-aware
policies (also available in TMF ZOOM). In this approach:

    context selects a working-set of policy rules

    the working set of policy rules collectively define the behavior of the
system being managed

    feedback from system state and monitored data may change the context, 

     which then changes the working-set of policy rules, so the system 

     adapts in a closed-loop manner

 

3. "Equations".

Something of the form A -> B is NOT an equation. Formally, an equation is a
statement that the values of two mathematical expressions are equal. I have
no idea how to interpret '->'; I have seen some people use this to mean
implies (material implication), but typically in logic, one would use the
unicode U+21D2 to represent this. Please use "formula" instead of
"equation", and please define the symbology that you are using.

 

4. Intent "Equations"

The following is wrong:  User -> intent -> context

 

Context is NEVER determined by intent; that is in fact exactly backwards!

 

A more correct version is:

    A user, playing a particular Role in a given context, expresses intent.

   The intent is independent of the role and context.

   However, both may affect how the management system implements this.

 

By the way, the equation user -> intent-> role -> context is WORSE! What
does a role have to do with context? My Customer Role doesn't care if it is
WiFi or Intranet or cellular, or what time of the day it is. However,
context can affect what can be accomplished:

 

   My intent: access my code server

   Business rule: only allow code access through an intranet connection

   Context: authenticated in an L3VPN

   My result:  DENIED

 

Why? Because my particular context violated a business rule. My intent did
NOT change. My role did NOT change. The same result would have happened for
different roles and contexts.

 

5. Intent and Role

Some people have said that intent should be classified by a user's role or
set or roles. This doesn't make sense to me. 

 

Roles do not "classify" anything. Roles separate one object with multiple
responsibilities into a set of objects, where each Role object defines a
particular responsibility. This provides system adaptability. For example, a
customer that withdraws and deposits money should be separated into two
roles (e.g., what if the customer is a bank employee? :-) ). The customer
DID NOT CHANGE in this example. If you don't use roles and still want to
obey separation of duty, then artificially splitting the same customer into
two objects creates a long list of problems (e.g., separate objects imply
separate identities) and still didn't solve the original problem.

 

Some people have talked about "role-based intent". This doesn't make sense
to me. 

In the previous paragraphs, I already argued that role and intent MUST be
orthogonal. In particular, the following drawing does not make sense to me:

 

http://www.ietf.org/mail-archive/web/ibnemo/current/jpgeskUTBKFLr.jpg

 

First, if the roles actually did map to these functions in this way, you
would have a very difficult role-engineering problem. Second, the collection
of roles in a particular layer serves no purpose other than to categorize
those roles. I would hope that intent doesn't care about categorization.

 

The only case that I can think of where this MAY make some sense is talking
about a specific set of Roles (e.g., EndUser vs. NetworkAdmin) and how the
intent of the former is conveyed to the latter, so that the latter can act
on it. But this is conflating roles (which are about responsibility) with
intent (which is about being determines to do something, and focusing on
doing that something).

 

6. Intent and Constraints.

Some people have said that the components of an intent are objects, results,
and constraints. I disagree.

 

Constraints are inputs to an intent. The actor issuing the intent can choose
to ignore the constraints (my Frogger or code server download examples) at
their own risk - the ultimate mediator is the management system.

 

Object is too broad a term - it could be an input and/or an output.

 

I also don't understand why a result is part of an intent. An intent is
expressing a focused desire to do something independent of whether that
results in anything. Perhaps this is just linguistic confusion, but if you
want to build a quality language and a quality information model, then
formalisms are your friend.

 

7. Intent: pure, impure, and other variations.

This just cannot work; that's what we concluded when writing the ONF NBI
white paper. If you go down this path, then  everything is intent (pure +
impure = 1), and that is not useful. People like to use IP addresses and
port numbers and router IDs and ... get over it! Please! These are all
elements of prescription. Look at Dave Lenrow's slides (similar slides also
appeared at OpenStack in Vancouver last month). There is absolutely no
difference between specifying a port number or IP Address for a flow as
there is in specifying "Ibuprofen" to solve a headache (when perhaps the
headache was caused by something very different than Ibuprofen won't fix).

 

Constraints are an important part of policy-based management. Constraints do
not have to be included, but most real-world examples are filled with
constraints, so the ability to represent them is critical. 

 

Intent should always have the ability to have constraints and context added
to it. While both are independent of intent, both MAY restrict the results
obtained from the intent request.

 

8. Intent and Declarative Interfaces.

Intent (or goal-driven) policy interfaces are NOT NEW. Jeff Kephart and I
gave a tutorial at NOMS 2006 on policy management, and covered goal-based
policies (and how they are different from other types of policies). This
built on about a decade of previous work. This is one of the reasons why
OpenStack Congress uses Datalog (well technically, we've extended the
Datalog syntax a bit), because it is purely declarative, and mathematically
formal. This latter gives very nice properties (order of Datalog statements
do NOT matter, I can guarantee that ANY query is computable if it follows
some simple rules, ...). 

 

9. Policy Continuum.

I do not understand how people can say that the Policy Continuum has
anything to do with layers. If you don't believe Bob, then please listen to
me as the inventor of the concept:

   a) the paper cited (there are many more) does NOT EVEN MENTION the word
Layer

   b) if it was a layered system, I would have called it LAYERED Policies or
Policy LAYERS.

   c) the definition of a continuum is a **continuous sequence** in which
adjacent elements are not noticeably different from each other, but the
extremes of the continuum are very different from each other. It has NOTHING
to do with layers.

 

The Policy Continuum was invented because policy has many different actors
that want to use it. Defining SLAs is defining policy. Defining when the
drop probability of a packet in a particular queue should be increased or
decreased is policy. Many things between these extrema are policy. More
importantly, different actors need to work together to implement E2E policy.
However, each actor speaks their own language, and has their own set of
concepts and terminologies. Trying to get this to change is a waste of time.
Hence, the policy continuum embraced this diversity, and said (as Bob did)
that the real problem is the nature and number of translations that are
required.

 

The policy continuum defines the contexts for different roles in the system.
If you don't want to use roles, the policy continuum defines context for all
policies, whether they are intent-based or not. The key point of the policy
continuum is that it defines different actors for different policies, and
mandates a translation between these continuum levels. This is the exact
problem that provides difficulty for people dealing with intent - they don't
know how to translate a high-level, technology-independent description of
intent into anything specific.

 

10. REST.

REST is NOT a protocol, please stop calling it a protocol.

 

11. Intent being expressed by different Roles (Actors).

This gets VERY hard. I've graduated three Ph.D. students who did work on
policy management (all used the policy continuum, all used an information
model, 2 used DSLs). Unless you have a very RICH information model, this is
impossible to do. You likely also need an ontology to formally define the
semantics and meaning of different information model objects.

 

Example: A Router says "forward" and "drop", a firewall says "accept" and
"reject". How does the machine know which verb to use when traffic goes
through both? This is a trivial problem compared to different actors that
can use the same language with different data objects. I would strongly
suggest that you first focus on one Role.

 

Note that this is compounded by your very lightweight model. For example, a
node can be anything from a sub-network to a port on a device. I don't see
how that is helpful, especially in constructing a DSL. But that is a longer
discussion.

 

12. Formalisms.

This project confuses me - there seems to be a tendency to avoid the use of
formalisms, even though two very specific formalisms (info model and DSL)
are being proposed. I think that part of the confusion over the 100+ email
discussions on intent derives from this lack of formalism. For example, you
need to define what intent is, and what it isn't, precisely. Having "impure"
intent, or intent with this set of conditions vs. that set of conditions, or
intent on a Sunday, is the path to madness. Impure intent is, by definition,
not formally expressible (unless you count intensional definitions as a type
of formalism).

 

 

 

regards,

John

 

John Strassner, Ph.D.

CTO, Software Laboratory, CRD


logo.gif

 

Futurewei Technologies

US R&D Center

2330 Central Expressway
Building A, office A2-2143

Santa Clara, California   95050

  Office:  +1.408.330.4923

  Email:   [e-mail]