Subject: [Anima] Questions on RFC7575

From: John Strassner <[email-masked]>
Date: Sun, 21 Jun 2015 10:28:13 -0700

I started reviewing both the reference model as well as other pertinent
documents, so that when I write my sections for the reference model, they
are consistent. :-)

In doing so, I have a number of questions on RFC7575. Part of this may be
my academic nature, part may be because I have undoubtedly missed something
in past emails as I come up to speed, and partly because I'm likely
under-caffeinated. Hopefully, some of this will help improve the reference
model (and possibly other documents as well).

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?

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

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.

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.

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?

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?

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.
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.

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.

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.

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 22 Jun 2015 15:46:46 +0000

Hi John, let me take a stab at responding… And thanks for sharing your thoughts. A bit late to bring them into RFC7575, but a good timing for the reference model.

From: Anima [mailto:[email-masked]] On Behalf Of John Strassner
Sent: 21 June 2015 19:28
To: Anima WG
Subject: [Anima] Questions on RFC7575

I started reviewing both the reference model as well as other pertinent documents, so that when I write my sections for the reference model, they are consistent. :-)

In doing so, I have a number of questions on RFC7575. Part of this may be my academic nature, part may be because I have undoubtedly missed something in past emails as I come up to speed, and partly because I'm likely under-caffeinated. Hopefully, some of this will help improve the reference model (and possibly other documents as well).

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.

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.

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.)

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?

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.

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?

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.

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…)

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?

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”.

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

Michael
--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 22 Jun 2015 18:20:07 -0700

Thanks Michael for the response. My purpose was not to affect RFC7575, but
rather to ensure consistency as we move forward. Please see inline as well.

Questions on RFC7575
Page 3

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>

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 :-) ).

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

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>

Page 5, self-management

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>

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.

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

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.

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"? 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>

Page 9, section 3.7

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>

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>

Pages 12-13, section 5

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>

Page 13, Figure 1

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?

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>

Michael

best regards,
John

On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehring) <
[email-masked]> wrote:

>  Hi John, let me take a stab at responding… And thanks for sharing your
> thoughts. A bit late to bring them into RFC7575, but a good timing for the
> reference model.
>
>
>
> *From:* Anima [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* 21 June 2015 19:28
> *To:* Anima WG
> *Subject:* [Anima] Questions on RFC7575
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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
> 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…
>
> 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?
>
>
>
> 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.
>
>
>
> Pages 7-8, Section 3.6
> 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.
>
> 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.
>
>
>
> 2)      a distributed reporting function, where nodes aggregate, process,
> summarise, correlate, …  information before handing it to the controller.
> Here the intelligence is distributed.
>
> 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?”
>
>
>

-- 
regards,
John

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 23 Jun 2015 09:43:13 +0000

From: John Strassner [mailto:[email-masked]]
[…]
Questions on RFC7575
Page 3

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).
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.
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.
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 ;-)
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.

<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.

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.
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

-          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.
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.

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) ☺   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.

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!  ☺
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 ☺
Michael

Michael

best regards,
John

On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:
Hi John, let me take a stab at responding… And thanks for sharing your thoughts. A bit late to bring them into RFC7575, but a good timing for the reference model.

From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Strassner
Sent: 21 June 2015 19:28
To: Anima WG
Subject: [Anima] Questions on RFC7575

Questions on RFC7575
Page 3

Page 5, self-management

Pages 7-8, Section 3.6

Page 9, section 3.7

Pages 12-13, section 5

Page 13, Figure 1

Michael
--
regards,
John

--
regards,
John

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 23 Jun 2015 18:09:02 +0200

Dear John, Michael, All,

Please see below for my 2 cents...

Best regards, Laurent.

On 23/06/2015 03:20, John Strassner wrote:
> Thanks Michael for the response. My purpose was not to affect RFC7575, 
> but rather to ensure consistency as we move forward. Please see inline 
> as well.
>
> Questions on RFC7575
> Page 3
> includes centralized management mechanisms, or that there is 
> additional logic outside of just the nodes?
>
> 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.
>
> element" is one in which non-autonomic functions are used that may 
> affect the behavior of autonomic nodes? </jcs>
>
LC: Agreed, with the precision that the central element can also host 
autonomic functions, in addition to the non-autonomic functions, i.e. 
avoid the understanding that the central element is _only_ composed of 
non-autonomic functions.

> fundamental idea is that there is one intent for the entire network. 
> Thus this definition.
>
LC: I guess what Michael / RFC7575 mean by "one intent for the entire 
network" and not going into the "element management scope" is to 
voluntarily "stop" the intent at the network level and by doing this 
setting the system or network-wide goal.
For sure, this decision assumes that there are other / underlying 
mechanisms to translate / define the lower layers / levels / per element 
policies.
LC: I think ANIMA (or other initiatives) could bring new ideas / 
mechanisms on how to make sure that the whole system / network work well 
/ as planned by employing a netwrok-level intent (e.g. how autonomic 
elements knows to which domain(s) they belong, how they can understand / 
translate the intent correctly...).
>
>
> Plus, do you really mean "for the entire network"? Isn't "for a given 
> set of administrative domains" good enough? </jcs>
>
LC: I think "the entire network" means for "one network domain". Going 
by our (loose) definition (RFC7575) a set of domains can also apply. As 
for "adminstrative", this is still under discussion as to which criteria 
are used to define "domain" (cf discussion thread on the ANIMA mailing 
list).
> 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…
>
> <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>
>
LC: I don't know what 1) autonomic default behavior / default intent 
really means (i.e. what behavor(s) it will trigger. Also, for me, 2) and 
3) are not competing management schemes. They are different levels of 
abstraction and capability.
You can have A- the human operator / OSS injecting (managing) directly 
all the network elements solely via NETCONF, SNMP, CLI...
You can have B- the human operator / OSS injecting (managing) via a 
policy (imperative or declarative model) which are then translated into 
NETCONF, SNMP, CLI...
In A, the intent / policy is not explicitly defined, it is in the "mind" 
of the human operator who knows what the network and the network 
elements should do and then directly translate it into the NETCONF, 
SNMP, CLI parameters/values.
In B, the intent / policy is explicitly defined, and a 
mechanism/function is responsible for the translation into the 
appropriate output.
In parallel the priority between the different mode of operations needs 
to be specified (cf other discussion on the ANIMA mailing list).

> 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>
>
LC: Fully agree with John. If we follow a strict definition: you can 
only discover (pre-)existing knowledge. I think in ANIMA we aim also to 
address the case where the autonomic functions / the system as a whole 
creates new knowledge, this is opening  the realm of learning capable 
agents and several base mechanisms /functions could be subject to 
standardization in this area, providing a net functionality gain.
> 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.
>
> 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.
>
LC: I think the use of "require" might be too strong / misleading in the 
sense that it is not a MUST (in the requirements process meaning) We 
could/should clarify this in the reference model.
> 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>
>
LC: a work item for the reference model document could be to describe 
more clearly where those control loops are in the model/among which 
elements (i.e. instances of the same autonomic functions, between 
different autonomic functions, vertical vs. horizontal...)
> 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.
>
> -Event: A new node is detected
>
> -Condition: it doesn’t have a domain cert yet
>
> -Action: I invite the node to join my network.
>
> <jcs> Is the action a typo, and you really meant: "I do not invite the 
> node to join my network"? 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>
>
LC: I think Michael was illustrating the fact that the intent and the 
ECA policy could be defined at different levels and might contradict 
each other (something we should try to prevent by design/BCP in ANIMA) 
and then you need to handle this conflict (e;g. using the priorities or 
other techniques (knowing that policy conflict resolution is not a 
solved problem)).
> model, every node does the normal syslog, etc., and aggregated 
> reporting is the new thing that comes with AN.
>
> 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.
>
> 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.
>
> <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>
>
> 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.
>
> “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?”
>
> <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>
>
LC: We will certainly need to revise this part of the model, and start 
by defining who interfaces with it (e.g. the human operator / the OSS) 
and to do what with the system, once done I think the diagrams will be 
clearer and less equivoque.

> 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.
>
> 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?
>
>
> 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>
>
> <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>
>
> Michael
>
>
> best regards,
> John
>
>
>
> On Mon, Jun 22, 2015 at 8:46 AM, Michael Behringer (mbehring) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi John, let me take a stab at responding… And thanks for sharing
>     your thoughts. A bit late to bring them into RFC7575, but a good
>     timing for the reference model.
>
>     *From:*Anima [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *John Strassner
>     I started reviewing both the reference model as well as other
>     pertinent documents, so that when I write my sections for the
>     reference model, they are consistent. :-)
>
>     In doing so, I have a number of questions on RFC7575. Part of this
>     may be my academic nature, part may be because I have undoubtedly
>     missed something in past emails as I come up to speed, and partly
>     because I'm likely under-caffeinated. Hopefully, some of this will
>     help improve the reference model (and possibly other documents as
>     well).
>
>     Questions on RFC7575
>     Page 3
>     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
>     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.
>
>     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…
>
>     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?
>
>     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
>     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.
>
>     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.
>
>     -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?
>
>     Page 9, section 3.7
>     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.
>
>     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.
>
>     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.
>
>     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?”
>
>     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.
>
>     Thanks for all your input John! Let’s make sure that all these
>     points get addressed in the reference model.
>
>     Michael
>     -- 
>
>     regards,
>
>     John
>
>
>
>
> -- 
> regards,
> John
>
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France