Subject: Re: [Anima] Questions on RFC7575

From: John Strassner <[email-masked]>
Date: Tue, 23 Jun 2015 20:57:31 -0700

Hi Michael,
thanks again for replying. I've answered inline (<jcs2/> ).

best regards,
John

*From:* John Strassner [mailto:[email-masked]]
*[…]*

Questions on RFC7575
Page 3
"Autonomic functions can be defined in two ways:
  o On a node level: Nodes interact with each other to form feedback
    loops.
  o On a system level: Feedback loops include central elements as
    well."
What is a "central element"? Does this mean that the feedback loop includes
centralized management mechanisms, or that there is additional logic
outside of just the nodes?

MB: A central element is a controller for example. The point of the section
is: You could define an “autonomic network” where every node has exactly
the same interfaces as today (primarily CLI, SNMP, NETCONF), and where a
controller is involved in all control loops. Our definition of “autonomic”
is further down in the network, where nodes interact directly with nodes.
Now we all understand this isn’t black and white, but the emphasis of the
work in the IETF should be node-to-node interactions.

<jcs> OK, got it. Just to ensure, is it fair to say that a "central
element" is one in which non-autonomic functions are used that may affect
the behavior of autonomic nodes? </jcs>

MB2: This is correct but not complete. Because also a normal node has
non-autonomic functions that may affect the behaviour of that node (or
others).

<jcs2> True, but I wouldn't think of a "normal node" as a "central
element". So perhaps the language needs to be widened? </jcs2>

Page 5, definition of intent
Why is intent scoped to a single autonomic domain?

MB: Intent isn’t a policy language like most other, where you can
essentially define a policy for every network element separately. The
fundamental idea is that there is one intent for the entire network. Thus
this definition.

My personal opinion: If we let Intent slip into the element management
scope, we’ve missed an opportunity. Intent is a policy on network scope.

<jcs> Here you lost me. ODL GBP and ODL NIC, OpenStack Congress, some
nascent work in the ONF, and TMF ZOOM would all disagree. Intent, for
better or worse, has been characterized as The New Policy (no offense
to Light Reading). But then at the end you say "Intent is a policy on
network scope", so maybe I'm reading you too literally? (see I haven't
changed since my Cisco days :-) ).

MB2: I know, lots of groups have by now picked up the “intent” word, and
since we never really defined it in detail, it now means anything to
anyone. (I think – hopefully I’m wrong). We should discuss this in Prague.

<jcs2> No, sadly, you are right. Do you mean “intent” as an “interface” or
set of “APIs”?

This appeals to me, because if there was such an intent “box” that allowed
declarative programmatic control, then policies could be an input to as
well as an output from this box. </jcs2>

Plus, do you really mean "for the entire network"? Isn't "for a given set
of administrative domains" good enough? </jcs>

 MB2: domain is the right term.

<jcs2> YAY! J </jcs2>

Page 5, definition of autonomic domain
Why is autonomic domain tied to intent as the only management paradigm? The
vast majority of work in autonomic networking does NOT use intent (what I
call declarative logic, I failed marketing :-) ). I completely agree with
using intent, and perhaps even emphasizing it, but I don't agree with
excluding other management paradigms.

MB: Probably a question of wording. In my reading you have 1) autonomic
default behaviour (could also call this “default intent”), 2) Intent, and
3) traditional management schemes, such as NETCONF, SNMP, CLI, etc…

So we don’t exclude other management paradigms, they are handles in section
3.2. Is that what you mean?

(You could also define an autonomic domain by the zone of trust of the
certificates.)

<jcs> Yes. Note that in SUPA, we derive intent and traditional (i.e., ECA)
from the same Policy info model. This has the nice property of letting
intent translate across actors and be used to fire ECA policies (and vice
versa). </jcs>

 MB2: Need to discuss this in more detail, in Prague ;-)

<jcs2> Happy to. I’ve used the Policy Continuum to represent the fact that
different actors speak and think about policies that need to cooperate and
communicate using different terms, syntax, and semantics. No one policy
language will ever address all actors (e.g., business people, product
people, application developers, administrators), just like Python or Ruby
will never eliminate Java, much less C. In SUPA (and in DEN-ng and in the
TMF ZOOM), we have defined a common foundation representing policy
concepts; from this we derive two different types of policies (four in
DEN-ng and ZOOM): ECA and declarative (i.e., intent). This enables a
declarative policy to call ECA policies in the process of translating it to
a form that is more amenable for communicating to a management entity or a
device. </jcs2>

Page 5, self-management
"They configure themselves, based on self-knowledge, discovery, and Intent."
The word "discovery" is confusing me. Suppose a node runs a utility
function to decide what its next configuration change should be. It is not
"discovering" something that existed - rather, it is computing new
knowledge. A machine learning function that infers new knowledge is an even
better example of something that is not "discovered". I'm probably missing
something, but why was this choice made?

The thing that really bothers me is that this assumes that all knowledge
can be discovered - that is, it is existing, like an apple on a tree, ready
to be plucked. In the autonomic systems that I've built, this is only
sometimes the case. It is vital for an autonomic system to be able to learn
new knowledge via computation and inference, as well as decide that
previous knowledge was incorrect. Neither of these are discovery functions.

MB: I think the confusion is the definition of “discovery” here. It’s not
only discovery in the sense of service discovery, but for example, finding
neighbors, negotiating parameters with them, etc.

The above phrase in other words: “I know my capabilities, I see what else
is there (and talk to it potentially), and I see what the boss wants to
happen (intent). Based on all of this I decide what I’m going to do”.

I think it’s a question of wording. We had this graphic (similar to figure
1), where there are the 3 input vectors (!) of information, on which you
base your decisions. The inference you mention is a consequence of those
inputs. In other words, the “brain” that actually makes the inference, is
in our model the autonomic service agent.

Does that make sense?

<jcs> I think so. I still think that my two examples are not discovery. I
had somehow concluded that discovery was all-inclusive, but when I look at
your answer, I realize that it isn't. Still, in the reference document, I
think we should point this out. I do agree that discovery is sometimes not
explicitly mentioned, which is a shame, since it is such a vital function.
It would therefore be OK imho to emphasize discovery as long as we leave
some wiggle room for dynamically creating and removing knowledge. </jcs>

MB2: It would help me if you could suggest where in the doc to make those
changes.

<jcs2> I’d be happy to. Let me finish sections 7.4-7.6, and then I’ll send
a review of the entire document (hopefully by this Friday) </jcs2>

Page 6, last paragraph above section 3.2
"...closed-loop control is an important aspect of self-managing systems.

This implies peer-to-peer dialogues between the parties that make up

the closed loop. Such dialogues require two-way "discussion" or
"negotiation"

between each pair or groups of peers involved in the loop,..."
First, by "peer", I assume you mean two (or more) equipotent entities that
make some portion of their resources available to others. Second, and more
importantly, a closed control loop does not require each entity in the
closed control loop to talk to negotiate with other entities. Now, in an
autonomic control loop, this could very well be the case, but it is unclear
to me why it MUST be the case. The obvious nightmare scenario is that the
negotiation fails. Then what - we have no control loop at all?

MB: I guess your point is that an autonomic process doesn’t HAVE to have a
control loop. I would argue that the typical autonomic function DOES have
node-to-node interactions. This is what autonomics is all about. Now, yes,
there will be cases where this fails, and where a node also needs to do
something sensible in case of complete isolation. But that’s an exception
state in my mind.

<jcs> No. Let me try again.

The text that bothers me is "[closed-loop] implies peer-to-peer dialogues
between the parties that make up the close loop". That isn't how
traditional control loops are typically built, and I'm personally not
familiar with any autonomic system that builds them in this way. Sure, it
would be nice to allow this when necessary - FOCALE had this feature
through a dedicated control interface that could adapt the function carried
out by a control loop element based on (for example) changing context - but
I disagree that it is a MANDATORY function.

MB2: We need to discuss this as well in Prague. I have the feeling we’re
not talking about the same thing.

<jcs2> OK. Feel free to start a thread, or wait till 7.4 is done. I’ll try
and sneak some text in there that better explains what I’m thinking without
making it a long dissertation. J </jcs2>

To your second point, I do (of course!) agree that autonomics is about
node-to-node interactions. But, it is also about system-wide interactions.
My point was that if you mandate negotiation in order to create a control
loop, and the negotiation fails, you're in trouble. And yes, that would be
an exception state in my mind, as it violates a basic principle in
autonomics - consensual behavior. </jcs>

Pages 7-8, Section 3.6
Most autonomic networking systems to date have NOT been built with an
intent (or declarative) style interface. FOCALE enables declarative and
prescriptive (e.g., ECA policy rules) to be used. Others just use ECA (or
an equivalent) paradigm. Hence, I'm wondering why intent is the ONLY
paradigm that is mentioned in this RFC that is suitable for autonomic
networking? Shouldn't we try and peacefully coexist, just as the nodes are
peacefully coexisting with non-autonomic directives?

MB: To me, ECA is encoded in an ASA or an autonomic function. The function
says what action you take in specific events, and under which condition.

Example: The “enrolment proxy ASA” has the following (hard coded) ESA:

-          Event: A new node is detected

-          Condition: it doesn’t have a domain cert yet

-          Action: I invite the node to join my network.

Now, Intent is in my mind a higher level concept which could now state “do
not enrol new nodes at this moment”.

How would you see that?

<jcs> Is the action a typo, and you really meant: "I do not invite the node
to join my network"?

MB2: No, this is the actual behaviour of a bootstrap proxy. If a node is
new and doesn’t have a domain cert yet, you invite it to join the domain
(controlled by the registrar of course). Anyway, that’s a detail I think.

As stated, I would say that the ECA policy would NOT fire because it
violates intent. However, to my earlier point above about intent and ECA
policies being able to call each other - ABSOLUTELY. </jcs>

 MB2: I think we’re actually on the same page here, and it’s a question of
wording.

<jcs2> If you are trying to illustrate a conflict in intent (which by the
way most people in other SDOs say does not exist, which I disagree with),
then I agree. Otherwise, my turn to ask you for a detailed discussion in
Prague. </jcs2>

Page 9, section 3.7
"However, in an Autonomic Network, reporting should happen on a
network-wide basis."

True, but shouldn't individual nodes and collections of nodes still report?
That isn't implied in the wording.

MB: Yes, they should. This is “traditional management methods”. In our
model, every node does the normal syslog, etc., and aggregated reporting is
the new thing that comes with AN.

<jcs> Got it, thanks. </jcs>

Furthermore, the last paragraph says: "Autonomic network events should
concern the Autonomic Network as a whole, not individual systems in
isolation." I agree that the goal is to report on the system as a whole,
but isn't such a report collected from individual nodes? Just like in your
example, the nodes need to be able to see that a problem has already been
reported in order to know not to issue the same problem.

MB: There are two parallel methods of reporting:

1)      the traditional every-node-to-controller method, where the
intelligence is central

2)      a distributed reporting function, where nodes aggregate, process,
summarise, correlate, …  information before handing it to the controller.
Here the intelligence is distributed.

Both will co-exist. The RFC focuses on the new method (and obviously isn’t
clear enough about it…)

<jcs> OK, got it. In FOCALE, we almost NEVER used node-to-controller (well,
FOCALE predates SDN controllers, but let's say controller == some
centralized manager) unless the majority (or more) of nodes failed. We did
use an umbrella management paradigm (similar to clusterheads in P2P
networks), where the clusterheads did collection, filtering, correlation,
and possibly other functions before passing the data (not necessarily up!).
I'm happy to focus on the new, just want to ensure we have some fallback
position for not just legacy integration, but more importantly, failure
modes. </jcs>

 MB2: Ack. (I think) J   And I start to understand where some of our
confusions are coming from. FOCALE does have a different model I think.
Needs more discussion.

Pages 12-13, section 5
Why is an Autonomic **User** Agent the interface to a control loop? I can
see an external entity wanting to configure and monitor the control loop,
but why wouldn't the User Agent talk to the Service Agent to do this? I do
note that this figure is under discussion and being revised in the
reference model.

MB: Yes, that’s confusing wording, and now that you mention it, yes we
should have probably looked for a better term. The idea is: The
“intelligence” of an autonomic function is in the ASA (middle of figure 1).
There are now horizontal feedback loops and northbound feedback loops. For
example, there is likely a function in the enrolment process, where a
message gets sent to the admin: “Here’s a new node, I don’t think it
belongs into our network, I’ve quarantined that node for now; would you
like me to 1) accept the node anyway, or 2) mark it as bad?”

I agree the term “user agent” is not good. We need to find a better one.
Suggestions?

<jcs> So does "user agent" mean "(autonomic) management agent"? Probably
NOT a user-facing agent, right? In the tradition of Calm Technology, the
best and most ubiquitous functions are those that don't demand attention,
but rather inform. </jcs>

 Mb2: Maybe that’s the right term. Need to think more…

Page 13, Figure 1
Where is the Autonomic Node in the Reference Model? I do note that this
figure is under discussion and being revised in the reference model.
However, even in Figure 2 of the reference model, it is still unclear what
the "node" is. But more on that later.

MB: The whole thing is the node. That’s why the figure is called “Reference
Model for an Autonomic Node”.

<jcs> But if it is a **node**, then why is it running its own internal
feedback loops? Note that "node" implies a single something. Clearly, the
single something can contain groups of other somethings, but why would a
feedback loop exist in the single something when we are emphasizing
inter-node communication and functionality?

MB2: Where do you see a feedback loop in the node?!? I don’t!  J

<jcs2> Figure 1 in RFC7575, Feedback Loops box is within the Node outer
line. </jcs2>

I think that this figure would be improved by showing interfaces to the
Autonomic Control Plane and to the OS; right now, they are inside of the
node, and that I don't understand. In FOCALE, as well as other
architectures, knowledge did not have to be embedded in the node, it could
be received from other places in the network. Hence, I think that showing
interfaces to where knowledge is obtained and where it is discovered is
more generic. Of course, more capable nodes could contain these functions,
but I'm not convinced that this is the norm. </jcs>

Thanks for all your input John! Let’s make sure that all these points get
addressed in the reference model.

<jcs> I hope it helps. I think I can now write my sections in a way that
will be more consistent. More feedback coming later. </jcs>

 MB2: Thanks for feedback. I think we should single out specific issues,
and create a specific mail thread on each, this one is starting to get
messy J

<jcs2> I was hoping that we had converged, but if something needs more
discussion, please don’t hesitate to start a new list. </jcs2>

Michael

Michael

best regards,

John

-- 

regards,

John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2015 13:46:30 +1200

On 24/06/2015 15:57, John Strassner wrote:

...
> element". So perhaps the language needs to be widened? </jcs2>

At an earlier stage in the protocol draft, we had strong emphasis on
hierarchical structure, and discovering one's hierarchical superior.
We have gradually reduced that in the text to the observation that
in an AN, discovering your "superior" is no different than discovering
other peers; it's just a source of information or shared resource
like any other. I think the same logic will apply to "central"
elements. They are nodes that some human has chosen to put a label
on saying "central" and they happen to receive resources and Intent
and maybe other information from humans, for wider distribution.
But the network is a mesh, not a tree, and these nodes are just
arbitrary points in the mesh (or the cloud, if you prefer a modern
buzzword).

    Brian

---

From: John Strassner <[email-masked]>
Date: Fri, 26 Jun 2015 19:11:07 -0700

Hi Brian,

thanks for the explanation.

I do agree with you that hierarchy, or a set, or other types of
relationships, are **just** relationships, and are only "special"
in a particular context (if at all). That being said, I think you
run the risk of confusing people by using "central", since that
has some unfortunate non-autonomic connotations.

Just my 2 cents.

regards,
John

On Fri, Jun 26, 2015 at 6:46 PM, Brian E Carpenter <
[email-masked]> wrote:

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

-- 
regards,
John