Subject: [Anima] Questions during ANIMA II session

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 7 Apr 2016 22:51:20 +0200

Hello,

Thanks for your patience re. the issues faced for the remote presentations.
I hope you still managed to understand our messages ;)

There have been comments on the coordination and knowledge presentations.
Michael, Jéferson and Bing: could you repeat your comment on the list?
I caught the following:

Q. Michael: examples of coordination, what a (minimal) policy engine 
could look like? start small.

Q. Jeferson: implications on data models / measurement/monitoring... ?

Q. Bing: use GRASP or other mechanisms. Clarify requirements for GRASP.

Thanks, Laurent.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Apr 2016 21:11:37 +0000

Hi Laurent,

Thanks for the summary. You captured my point.
 I think the knowledge exchange is a valuable topic. When we wrote the distribution draft, we also expected the GRASP could not only distribute Intent, but as well as other valuable information. So I’m happy to see you call it out.
But I don’t know how sophisticate the knowledge exchange would be, so it will be great if you can sort out the specific requirements. Then let’s check whether it could be covered by the distribution function (probably with extensions to current design).

Best regards,
Bing

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: Thursday, April 07, 2016 5:51 PM
To: anima; Liubing (Leo); Jéferson Campos Nobre; Michael Behringer
Subject: Questions during ANIMA II session

Hello,

Q. Michael: examples of coordination, what a (minimal) policy engine could look like? start small.

Thanks, Laurent.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 8 Apr 2016 11:06:35 +0000

Hi Laurent,

Yes, indeed, that was my question. I understand the topic conceptually, it’s importance and all, but would like to see how it actually works. What the interfaces are. And a simple example.

Here is where I’m having a hard time: I guess the ASAs need to be aware of the coordination function, right? Means, when I write an ASA I need to expect messages from a coordination function.

Then there is the hook to the knowledge plane: The coordination function must know in the first place which ASA is manipulating which values, right?

At the moment I’m imagining this picture:

-          at bootup, ASA needs to “register” somewhere (hook to knowledge plane as I see it), and list the parameters it’s manipulating. Such that the coordination function gets to know who manipulates what on which device.

-          The coordination function essentially monitors whether any two (or more) ASAs are working on the same parameters. (Although I’m sure we’ll also have cases where conflicts arise even if the ASAs manipulate distinct parameters).

-          In such cases, the function monitors those parameters; if it detects oszillation, flapping, extreme values, etc, it tells one ASA to back off for time x. Or gives it constraints, like “no higher than x”, or “don’t modify for x sec”. Or...

See what I mean, that could become a pretty complex beast. Need to understand first the basic interfaces.

Michael

From: Laurent Ciavaglia [mailto:[email-masked]]
Sent: 07 April 2016 17:51
To: anima <[email-masked]>; Liubing (Leo) <[email-masked]>; Jéferson Campos Nobre <[email-masked]>; Michael Behringer (mbehring) <[email-masked]>
Subject: Questions during ANIMA II session

Hello,

Thanks, Laurent.

---

From: John Strassner <[email-masked]>
Date: Fri, 8 Apr 2016 15:45:37 -0700

Hi Bing,

> When we wrote the distribution draft, we also expected the GRASP could
> not only distribute Intent, but as well as other valuable information.

I think we need to be careful here. Just as Michael warned that we are
starting to
call everything intent (and shouldn't), I'm a bit scared that we are
starting to
view GRASP as a generic communications mechanism.

I also think we need to differentiate between intent (as an input to the
autonomic
network), traffic resulting from said intent, and other traffic that
gathers observations
and produces results. It is not clear to me that we want to use the same
network
these three types of information, as their associated data structures and
properties
are likely **very** different.

regards,
John

On Thu, Apr 7, 2016 at 2:11 PM, Liubing (Leo) <[email-masked]>
wrote:

>  I think the knowledge exchange is a valuable topic. When we wrote the
> distribution draft, we also expected the GRASP could not only distribute
> Intent, but as well as other valuable information. So I’m happy to see you
> call it out.
>
> But I don’t know how sophisticate the knowledge exchange would be, so it
> will be great if you can sort out the specific requirements. Then let’s
> check whether it could be covered by the distribution function (probably
> with extensions to current design).
>
>
>
> Best regards,
>
> Bing
>
>
>
> *From:* Laurent Ciavaglia [mailto:[email-masked]]
> *Sent:* Thursday, April 07, 2016 5:51 PM
> *To:* anima; Liubing (Leo); Jéferson Campos Nobre; Michael Behringer
> *Subject:* Questions during ANIMA II session
>
>
>
> Hello,
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Apr 2016 12:58:37 +1200

> I'm a bit scared that we are
> starting to

Agreed, but as a matter of principle, I don't want GRASP to be restrictive,
since it will be present in every autonomic node. But we've always said
that ASAs can use any communication method they want in addition, as
long as they do whatever we specify as the minimum with GRASP.

What I have noticed, however, is that because of the way we've defined
GRASP objectives, they do actually function as a generic PDU when used
in a GRASP negotiation session. That wasn't a goal, but it's emerged
as a feature.

Regards
   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 12 Apr 2016 09:33:30 +0000

Hi John,

Please see replies inline.

From: John Strassner [mailto:[email-masked]]
Sent: Saturday, April 09, 2016 6:46 AM
To: Liubing (Leo); John Strassner
Cc: Laurent Ciavaglia; anima; Jéferson Campos Nobre; Michael Behringer
Subject: Re: [Anima] Questions during ANIMA II session

Hi Bing,

> not only distribute Intent, but as well as other valuable information.

I think we need to be careful here. Just as Michael warned that we are starting to
call everything intent (and shouldn't),
[Bing] I agree we should NOT consider Intent as a generic container for various kinds of management information or command.

I'm a bit scared that we are starting to
view GRASP as a generic communications mechanism.
[Bing] This is a reasonable caution, thanks. We definitely should NOT abuse it.

On the other hand, in my mind GRASP naturally has some more or less “generic” communication capabilities by its definition. Here is some analysis:

-        AN domain flooding. Not only Intent, but anything that need to be flooded to the domain.

*leveraging GRASP-Flood

*built-in loop avoidance capability

-        Pulling a set of information from a specific AN node:

* leveraging GRASP-Sync

-        Multi-round point-to-point information exchange:
*implying there is context/state during the exchange, not purely transporting
*leveraging GRASP-Negotiation

However, there should be limitations on above mentioned communication:

-        either for flood or point-to-point communication, the conveyed information should be small enough to avoid transport-specific features such as fragmentation, streaming, re-transmitting etc.

-        For any “generic” communication, the ASAs need an “objective” definition to indicate what information they’re exchanging, and also formulizing the information data structure. The objective could be standard, or private among a set of ASAs.

I also think we need to differentiate between intent (as an input to the autonomic
network), traffic resulting from said intent, and other traffic that gathers observations
and produces results. It is not clear to me that we want to use the same network
these three types of information, as their associated data structures and properties
are likely **very** different.
[Bing] I agree the above said three types of information should be naturally distinct at the content level. But I guess all the three types of information doesn’t necessarily mean it all AN relevant communication?

Regarding to AN communication, as I understand, the scope is the communications between ASAs. ASA communication might not only include Intent. I think Laurent and Peloso’s  proposals (Coordination, ASA Life-Cycle management, Knowledge exchange) are giving some good clues for discussion.

Best regards,
Bing

regards,
John

On Thu, Apr 7, 2016 at 2:11 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Laurent,

Best regards,
Bing

From: Laurent Ciavaglia [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 07, 2016 5:51 PM
To: anima; Liubing (Leo); Jéferson Campos Nobre; Michael Behringer
Subject: Questions during ANIMA II session

Hello,

Thanks, Laurent.

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

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sun, 17 Apr 2016 21:57:23 -0700

Hi Bing,

sorry for the delay; snipped answers below (see <jcs>..</jcs>).

On the other hand, in my mind GRASP naturally has some more or less
“generic” communication capabilities by its definition. Here is some
analysis:
-        AN domain flooding. Not only Intent, but anything that need to be
flooded to the domain.

<jcs>
I understand that this is how GRASP has been designed. However, this
incurs a certain amount of risk, including a larger attack surface and the
danger of autonomic communications being swamped by other types of
communications.

I'm not saying that this is wrong, just that we need to be careful.
</jcs>

*built-in loop avoidance capability
<jcs>
For non-autonomic communications, cool. However, I'm not sure that
autonomic communications needs this.
</jcs>

-        Pulling a set of information from a specific AN node:
<jcs>
At some point, I'd really like to understand why this is preferred to a
more generic pub-sub mechanism. This seems counter-intuitive to
using a flooding approach, especially one that is non-constrained. I
guess I'm old-fashioned, but symmetry is usually a good thing...
</jcs>

-        either for flood or point-to-point communication, the conveyed
information should be small enough to avoid transport-specific features
such as fragmentation, streaming, re-transmitting etc.
<jcs>
Agreed. However, one of the prototypical communication types in
autonomic communication is the exchange of models, as well as
theories, hypotheses, and supporting information. These can be
quite large, which is why I think Michael originally suggested TFTP.
CoAP is fine for me as well - the point is that early on, as we build
up the reference model and related work (control loops, autonomic
functions, etc) we need to consider what to do to exchange such
types of information.
</jcs>

-        For any “generic” communication, the ASAs need an “objective”
definition to indicate what information they’re exchanging, and also
formulizing the information data structure. The objective could be
standard, or private among a set of ASAs.
<jcs>
We will need context and metadata for autonomics; I suggest that
these two would serve well here. I also think we should concentrate
on what you are calling "standard objectives".
</jcs>

autonomic

gathers observations

network

properties

> are likely **very** different.

[Bing] I agree the above said three types of information should be
naturally distinct at the content level. But I guess all the three types of
information doesn’t necessarily mean it all AN relevant communication?

<jcs>
Correct. I said **differentiate between** intent and the other 2 types.
</jcs>

regards,
John

On Tue, Apr 12, 2016 at 2:33 AM, Liubing (Leo) <[email-masked]>
wrote:

> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* Saturday, April 09, 2016 6:46 AM
> *To:* Liubing (Leo); John Strassner
> *Cc:* Laurent Ciavaglia; anima; Jéferson Campos Nobre; Michael Behringer
> *Subject:* Re: [Anima] Questions during ANIMA II session
>
>
>
> Hi Bing,
>
>
>
> [Bing] I agree we should NOT consider Intent as a generic container for
> various kinds of management information or command.
>
>
>
> On the other hand, in my mind GRASP naturally has some more or less
> “generic” communication capabilities by its definition. Here is some
> analysis:
>
> -        either for flood or point-to-point communication, the conveyed
> information should be small enough to avoid transport-specific features
> such as fragmentation, streaming, re-transmitting etc.
>
> -        For any “generic” communication, the ASAs need an “objective”
> definition to indicate what information they’re exchanging, and also
> formulizing the information data structure. The objective could be
> standard, or private among a set of ASAs.
>
>
>
>
>
> [Bing] I agree the above said three types of information should be
> naturally distinct at the content level. But I guess all the three types of
> information doesn’t necessarily mean it all AN relevant communication?
>
>
>
> Regarding to AN communication, as I understand, the scope is the
> communications between ASAs. ASA communication might not only include
> Intent. I think Laurent and Peloso’s  proposals (Coordination, ASA
> Life-Cycle management, Knowledge exchange) are giving some good clues for
> discussion.
>
>
>
> Best regards,
>
> Bing
>
>
>
> regards,
>
> John
>
>
>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Apr 2016 08:08:30 +1200

Comments in line...

> I'm not saying that this is wrong, just that we need to be careful.

This is why I keep banging on about LL multicast inside the ACP. When we
are not protected by the ACP, we are speaking & listening in public.

> autonomic communications needs this.

It has at least three aspects:

1. Backstop against discovery messages radiating out too far, in case
   there are any issues with the AN domain boundary.
2. Ditto for flood messages.
3. Backstop against incompetent ASA code with a non-terminating
   negotiation algorithm. This is important because we might see
   very large numbers of ASAs written by a large variety of
   people. These are the apps of AN.

> guess I'm old-fashioned, but symmetry is usually a good thing...

I think it's because we tend to see each ASA as an independent actor,
and potentially an independent source of information. I think we can
construct pub/sub on top of that if we want to, but indeed we don't have
a message bus or message hub. (Sorry, I was infected by MQ Series when I
worked for IBM :-)

> functions, etc) we need to consider what to do to exchange such

I'm not sure I agree with either of you on this yet. Simply put, there's
no reason that we can't use TCP between any two points in the ACP. So
I'm not sure why we need anything else when a message exceeds one packet.

> on what you are calling "standard objectives".

That's clearly what *we* (the Anima WG) should concentrate on. But again,
ASAs are apps, and if this stuff works at all, there will be all sorts
of privately defined objectives. (Which is why I care about the API and
about the ability to support GRASP in high-level languages.)

> Correct. I said **differentiate between** intent and the other 2 types.

Agreed. This is also why we've said that ASAs can use whatever communication
method they like, once they've established contact using GRASP.

Regards
   Brian