Subject: [Anima] Request for review of GRASP requirements

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Aug 2015 08:28:48 +1200

WG,

Please review the requirements section of draft-ietf-anima-grasp-00:
https://tools.ietf.org/html/draft-ietf-anima-grasp-00#section-2
The requirements are numbered 1..25. If you have comments, please mention
the requirement number, or propose a completely new requirement.

If we don't get comments by the end of August, the design team will
assume that the WG is happy with the existing set of requirements.

Regards
   Brian

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Mon, 31 Aug 2015 20:27:31 +0000

Hi Brian and all,

Having in mind your request concerning the draft on coordination, I set myself at this task (when back from summer break unfortunately for the time-line), willing to make sure the scenarios of coordination and of autonomic management we had in mind, would be supported by GDNP.

Actually, I'm stumbling over some prior elements which concern more some of the hypothesis and the scope of the protocol.
A first contextual question: Does this protocol use the ACP to convey its messages ?
A second one: What are the actors/roles using GDNP? Check list below
    1. ASA for sure (I've read it),
    2. "Autonomic devices" are written as well, (are those the autonomic nodes of the model, or could that be something else)?
    3. network management entities of the system (not really mentioned in the draft, but as you intend to convey technical objectives to the ASA, I would say this pertain to the management of ASA) (A bit of philosophy here: though autonomics intend to simplify the management it brings us in a shift in paradigm from managing equipments to managing functions that would in their turn manage the equipments)
    4. Any utility entity (that would achieve coordination e.g. or would this be considered as a specific ASA)?

This question is important as I would expect the kind of messages sent by entities depend on their role (in fact the requirements as well as far as this email is concerned).
An illustration of that point is: I would not expect an ASA to set technical objectives to another ASA (it could just intend to mislead the other ASA to win the competition).

We should also be careful of the roles in the inter ASA exchanges. I would easily imagine ASA sharing a similar objective to organize themselves into an autonomic function, then their negotiation would be quite different from the negotiation between competing ASAs.

Hence, is GDNP meant to achieve the communication between all these roles?

These early questionings expressed, I can then venture in some requirements, but the previous points do really condition these requirements, that is why I put them in short, let me know which you think in and out of scope, before I turn those in more appropriate text.

R1. If we consider a management message to ASA as technical objective, we should also consider the possibility to send a scope of work. (Meaning which equipments need to be managed by the ASA, this seems unneeded for networks composed of AN only, but when mixing with legacy equipments, that becomes mandatory).
R2. Allow for the ASA running its MAPE loop under the supervision of a coordination entity; fixing the rhythm, the right to run or not, the extent to which the MAPE loop is completed.
R3. A description of the ASA detailing which are the parameters modified, and which are the metrics monitored.
R4. Messages between ASA to share information (like monitored metrics, inferred trends or knowledge) (is it covered by req 15?).
R5. Messages between ASA after discovery in order to organize themselves as Autonomic functions (partially covered by req 7?).
R6. Management message to install a specific ASA on a designated host (AN a priori, but in non AN only networks that may be not that simple).

Which would conclude here my email.

BR and thanks for all,

Pierre

> -----Message d'origine-----
> De : Anima [mailto:[email-masked]] De la part de Brian E Carpenter
> Envoyé : dimanche 16 août 2015 22:29
> À : Anima WG
> Objet : [Anima] Request for review of GRASP requirements
>
> WG,
>
> The requirements are numbered 1..25. If you have comments, please mention the
> requirement number, or propose a completely new requirement.
>
> If we don't get comments by the end of August, the design team will assume
> that the WG is happy with the existing set of requirements.
>
> Regards
>    Brian
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Sep 2015 10:45:21 +1200

Pierre,

Thanks for your interesting questions. Speaking for myself alone:

> A first contextual question: Does this protocol use the ACP to convey its messages ?

The protocol is intended to work in any secure context, but the normal secure context
is indeed the ACP. However, we don't want to exclude using it between separate domains
in special cases (for example, where two ISPs have agreed to use an autonomic method
for a particular parameter). In such a case GRASP could run over TLS. (We haven't
mentioned using IPsec, but I can't see any reason why that should be forbidden.)

>     2. "Autonomic devices" are written as well, (are those the autonomic nodes of the model, or could that be something else)?

Hmm. We have a sort of implicit definition:
      Every autonomic device will be pre-loaded with various functions
      and ASAs and will be aware of its own capabilities, typically
      decided by the hardware, firmware or pre-installed software.
This suggests to me that we intend to refer to a device that contains
at least one ASA. I think we need to be precise about that.

>     3. network management entities of the system (not really mentioned in the draft, but as you intend to convey technical objectives to the ASA, I would say this pertain to the management of ASA)…

We have to accept co-existence with all traditional network management entities.
I could imagine an ASA function being added to a traditional network management
entitity, but we aren't trying to compete with NETCONF or SNMP for example.
If an entity manages a number of elements via NETCONF, and that entity has
an ASA as its autonomic interface, we would integrate the two worlds.

Certainly a goal is to move to intent-based management as much as possible, which
is indeed a matter of managing functions IMHO.

>     4. Any utility entity (that would achieve coordination e.g. or would this be considered as a specific ASA)?

I think we would model that as an ASA.

> This question is important as I would expect the kind of messages sent by entities depend on their role (in fact the requirements as well as far as this email is concerned).

Indeed, which is why I believe that we need considerable flexibility and
extensibility.

> An illustration of that point is: I would not expect an ASA to set technical objectives to another ASA (it could just intend to mislead the other ASA to win the competition).

Hang on - if there are several ASAs managing the same resource, they will negotiate
with each other. If it's a finite resource they will be negotiating within a
zero-sum game. Do we really need to worry about rogue ASAs? We are within a
single adminiistrative domain (except for the special inter-ISP case mentioned
above).

> We should also be careful of the roles in the inter ASA exchanges. I would easily imagine ASA sharing a similar objective to organize themselves into an autonomic function, then their negotiation w…

Yes, each objective may have different characteristics.

> Hence, is GDNP meant to achieve the communication between all these roles?

Yes, which is exactly why the protocol doesn't describe objectives or roles.

> R1. If we consider a management message to ASA as technical objective, we should also consider the possibility to send a scope of work. (Meaning which equipments need to be managed by the ASA, this…

That sounds like Intent to me. It's true that in a partly autonomic network, Intent
will need to express what is excluded from autonomy.

> R2. Allow for the ASA running its MAPE loop under the supervision of a coordination entity; fixing the rhythm, the right to run or not, the extent to which the MAPE loop is completed.

Yes, Laurent has brought up the question of coordination. The starting conditions
can be part of Intent. I can imagine that we might have to add some coordination
functions when we understand aspect this better.

> R3. A description of the ASA detailing which are the parameters modified, and which are the metrics monitored.

That is entirely specific to an ASA - how does it affect the protocol?

> R4. Messages between ASA to share information (like monitored metrics, inferred trends or knowledge) (is it covered by req 15?).

I believe so. Since the content part of a synchronization objective is completely
unspecified by the protocol, it can contain this information.

> R5. Messages between ASA after discovery in order to organize themselves as Autonomic functions (partially covered by req 7?).

I don't quite understand this one. The function is intrinsic to the ASA.

> R6. Management message to install a specific ASA on a designated host (AN a priori, but in non AN only networks that may be not that simple).

Hmm. I've been assuming that ASAs would be pre-installed; whether they activate or not
is another question. Again, I've been assuming that they will simply start discovery
after power-on. If there's no discovery response, they can go back to sleep.

    Brian