Subject: Re: [Anima] I-D Action: draft-peloso-anima-autonomic-function-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Oct 2015 16:34:17 +1300

Hi,

This is interesting to read. At the moment I'm mainly interested in whether
it presents any new challenges for the GRASP design. Mostly, I think it doesn't;
the manifests and mandates are essentially declarative data structures that can
be transmitted by GRASP in its "synchronization" mode. They might also be candidates
for selective distribution, like Intent.

However, you have two imperatives: up and down (or start and stop, if you prefer).
In fact we already have 'stop' listed elsewhere, as an emergency button for
the human operator.

GRASP doesn't contain any feature currently for sending an unpredicted 'stop'
or 'start' message. Do we need to think about adding that? Or should we consider
it out-of-band as far as GRASP is concerned?

Regards
   Brian

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Thu, 29 Oct 2015 16:04:59 +0000

Hi Brian,

Thanks for your comments.

Alike you, I'm really interested in making sure these new challenges align with the toolkit provided by ANIMA (in general [ANI]) and GRASP (in particular).
As the proposed signaling protocol between ANIMA entities, GRASP is a first-hand candidate for that.

Laurent and I have worked on a tentative mapping with GRASP messages (to be presented in Yokohama), summarized below:

1. As you have well identified, one of the key-feature is to send imperative
commands:
   - start and stop
   - plus a few variants (fine control of MAPE/OODA loops) as listed in draft-ciavaglia-anima-coordination

2. Indeed ASA Manifest could be transported over GRASP, however a few questions appear:
   - IMHO Manifest pertains more to GRASP discovery than synchronization
   - An open point to resolve is that Manifest advertizes both parameters (read/write) and metrics (read only)
         - currently technical objective is for parameters only (as far as I understand)

3. ASA Mandate could be a form of Intent and thus would benefit from Intent extensions of GRASP.

4. The previous points highlight the need of identifying the different roles of "GRASP clients" (e.g. ASAs, AF Management Function, Coordination Function...)  

We're eager to discuss this prior to the session to clarify open issues.

Best regards,

Pierre Peloso

> -----Message d'origine-----
> De : Anima [mailto:[email-masked]] De la part de Brian E Carpenter
> Envoyé : mardi 27 octobre 2015 04:34
> À : Anima WG
> Objet : Re: [Anima] I-D Action: draft-peloso-anima-autonomic-function-00.txt
> 
> Hi,
> 
> it presents any new challenges for the GRASP design. Mostly, I think it
> doesn't; the manifests and mandates are essentially declarative data
> structures that can be transmitted by GRASP in its "synchronization" mode.
> They might also be candidates for selective distribution, like Intent.
> 
> or 'start' message. Do we need to think about adding that? Or should we
> consider it out-of-band as far as GRASP is concerned?
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Oct 2015 11:11:49 +1300

Bonjour Pierre,

>    - plus a few variants (fine control of MAPE/OODA loops) as listed in draft-ciavaglia-anima-coordination

In any case, we need to decide whether to make the imperatives part of GRASP.
Or would we then be duplicating NETCONF?

>    - IMHO Manifest pertains more to GRASP discovery than synchronization

Well, at the moment discovery is limited - it doesn't discover any properties.

The word "synchronisation" entered our vocabulary because of the discussion
over DNCP, to be honest. It may be that we should change the word (especially
seeing the requirements in draft-liu-anima-grasp-distribution).

>          - currently technical objective is for parameters only (as far as I understand)

Well, the word "parameter" is fairly general. Certainly in a negotiation it implies
read/write, but there's nothing in the definition of an objective that prevents
it being read-only. Actually in synchronization/distribution it is read-only.

> 3. ASA Mandate could be a form of Intent and thus would benefit from Intent extensions of GRASP.

Yes, I think so. And again - if we use the GRASP objective format, that says
nothing about the semantics of the content. It is not for nothing that the
CDDL definition of an objective shows the value as "any". The designer of
an objective has complete freedom.

(Incidentally, that's why I really like the change to CBOR. This 'any'
concept is very easy to handle in a language like Python, too: instantiate
a variable of class objective and assign whatever data structure you
want to objective.value.)

> 4. The previous points highlight the need of identifying the different roles of "GRASP clients" (e.g. ASAs, AF Management Function, Coordination Function...)

Right. But GRASP as a protocol doesn't care about that; it's just a carrier.

> We're eager to discuss this prior to the session to clarify open issues.

Unfortunately I won't be in Yokohama, but Bing will be there.

    Brian

> .

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 30 Oct 2015 19:06:36 +0000

Hi Brian and Anima Folks,

Here are comments to some of the points in-line. 

> De : Brian E Carpenter [mailto:[email-masked]]
> Envoyé : jeudi 29 octobre 2015 23:12
> À : PELOSO, PIERRE (PIERRE); Anima WG
> Cc : CIAVAGLIA, LAURENT (LAURENT)
> > Alike you, I'm really interested in making sure these new challenges align
> with the toolkit provided by ANIMA (in general [ANI]) and GRASP (in
> particular).
> > Laurent and I have worked on a tentative mapping with GRASP messages (to be
> presented in Yokohama), summarized below:
> >
[PP]
Agree with that statement.

> Or would we then be duplicating NETCONF?
[PP]
I am not worried about that because there is a main difference.
As I understand NETCONF, this one is to set configuration into Resources, Equipments.
e.g. ASAs may use NETCONF to perform their duties on the equipments (like changing link metrics) (Using NetConf is a pretty valid option among other and imho let free to the ASA coder).
In the case of the start-stop commands above, we set commands to autonomic functions more precisely to ASA, these functionalities does not pertain to the management of equipments (NETCONF in my understanding) but pertain to the management of autonomic functions (which manage equipments in their turn, then I would let it to ANI protocols - then GRASP??).

> Well, the word "parameter" is fairly general. Certainly in a negotiation it
> implies read/write, but there's nothing in the definition of an objective
> that prevents it being read-only. Actually in synchronization/distribution it
> is read-only.
[PP]
To avoid confusion I'll take all this part in a separated thread of email.

> CDDL definition of an objective shows the value as "any". The designer of an
> objective has complete freedom.
[PP]
As long that it is aligned with Intent...

> concept is very easy to handle in a language like Python, too: instantiate a
> variable of class objective and assign whatever data structure you want to
> objective.value.)
> 
> > 4. The previous points highlight the need of identifying the different
> > roles of "GRASP clients" (e.g. ASAs, AF Management Function,
> > Coordination Function...)
> 
> >> De : Anima [mailto:[email-masked]] De la part de Brian E
> >> Carpenter Envoyé : mardi 27 octobre 2015 04:34 À : Anima WG Objet :
> >> Re: [Anima] I-D Action: draft-peloso-anima-autonomic-function-00.txt
> >>
> >> Hi,
> >>
> >> This is interesting to read. At the moment I'm mainly interested in
> >> whether it presents any new challenges for the GRASP design. Mostly,
> >> I think it doesn't; the manifests and mandates are essentially
> >> declarative data structures that can be transmitted by GRASP in its
> "synchronization" mode.
> >> In fact we already have 'stop' listed elsewhere, as an emergency
> >> button for the human operator.
> >>
> >> or 'start' message. Do we need to think about adding that? Or should
> >> we consider it out-of-band as far as GRASP is concerned?
> >>
> >> Regards
> >>    Brian
> >>

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 30 Oct 2015 21:26:57 +0000

As said in my previous answer I dedicate a specific thread to the discussion around transporting ASA Manifest over GRASP, as I think that deserves it.

> seeing the requirements in draft-liu-anima-grasp-distribution).
From process point of view what I understand of GRASP:
 - discovery is: When an ASA bootstraps, it tries to discover if other ASA are sharing technical objectives with it.
For that purpose this ASA send a discovery message with a technical objective in it. (the option format of the objective specifies the use of the objective-name (for identification purpose) but specifies that no any field should be provided as the any is meant to carry the objective value - page 29 of grasp draft).
 - negotiation is : When the ASA intends to modify the objective value (let's say by sending a command to the equipment) he before needs to agree with other ASA which share this objective. In that case the option format contains both the objective-name (for identification purpose) and the proposed value (for negotiation purpose) in the ?any field.
 - synchronization is: When the ASA needs to share with other GRASP user that the value of a given objective is X, then this ASA sends.

Hence in my understanding Discovery happens mainly during bootstrapping, while negotiation and synchronization happen roughly each time the ASA executes its control loop (and decides to modify a value).

If the above is correct, I would then guess that a technical objective would resemble in a discovery message issued by a load balancing ASA:
Objective-name: Metric of interface [email-masked]
Objective-flag: N
Loop-count: ?
Any: void (hence not even present)

While when issued by the same ASA during negotiation:
Objective-name: Metric of interface [email-masked]
Objective-flag: N
Loop-count: ?
Any: 1000 (proposed value)

If my understanding of GRASP is still correct at that point and hoping I understand well the mind of draft-peloso authors :-), then:
- From a life-cycle point of view (see pages 15-16) when an ASA concludes its instantiation (bootstrapping in the simplest cases) it discloses what are the parameters handled by its control loop, that is the Manifest. It is meant to say to Coordination and the AF Management Functions, which are the parameters manipulated by the control loop.
E.g. the Manifest of the load balancing ASA used above would have in its Manifest an entry in its Possible Actions that would be : Metric of interface [email-masked]

Hence, if I was given the mission to use GRASP to create an implementation of draft-peloso, I would use the discovery message to disclose the Manifest or more exactly each of the entries of the Manifest. To which I see two advantages:
  1. that would work without any modification to GRASP
  2. that would respect the logics of GRASP in using discovery at bootstrap time

> that prevents it being read-only. Actually in synchronization/distribution it

That is perfect then, the Manifest discloses in discovery messages both :
  - the parameters with the objective-flags set to N (valid for discovery and negotiation),
  - the metrics with the objective-flags set to S (valid for discovery and synchronization)
 
That fits perfectly well, as the Manifest discloses the ASA capacities at bootstrap time:
  - the parameters to have Coordination informed of which parameters will be modified, then coordination can compute ASA interactions to pre-determine conflicts and then avoid them (hence to have a sort of negotiation)
  - the metrics to have other ASA informed that this metric is available for them to use as an input in their control loop.

Then later-on at run-time of the ASA:
  - the coordination can make sure the parameters enforced value will not collapse the network by witnessing and possibly negotiating these values,  
  - the information distribution can handle the sharing of metrics value between ASAs (that would then be collaborating ones using the synchronization messages).

At least that is how I perceive the philosophy of ANI at the service of ASA.

BR,

Pierre

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Oct 2015 15:05:16 +1300

>  - discovery is: When an ASA bootstraps, it tries to discover if other ASA are sharing technical objectives with it.

Yes, although in fact discovery can be repeated at any time (and probably should be,
since we would expect the discovery cache to be finite and subject to LRU logic).

Also there is another thing an ASA will need to do at boot time: register with
its local GRASP engine that it supports certain objectives.

> For that purpose this ASA send a discovery message with a technical objective in it. (the option format of the objective specifies the use of the objective-name (for identification purpose) but spe…

There's an exception which is the so-called rapid mode, but logically that can be decomposed
into discovery immediately followed by a request.

>  - negotiation is : When the ASA intends to modify the objective value (let's say by sending a command to the equipment) he before needs to agree with other ASA which share this objective. In that…

Right. And typically we assume that there is a dependency of some kind involved - for
example, a finite resource pool that the ASAs share, or the action of one ASA
might counteract the action of another.

>  - synchronization is: When the ASA needs to share with other GRASP user that the value of a given objective is X, then this ASA sends.

Yes, but either in request/response mode or unsoclicited mode.

> Hence in my understanding Discovery happens mainly during bootstrapping, while negotiation and synchronization happen roughly each time the ASA executes its control loop (and decides to modify a va…

If that value might in some affect a peer ASA, which might not always be the case.
Again, for a finite resource, if an ASA has enough of the resource, it could
do its job without any negotiation, until it runs out of resource. But if it's
doing path optimisation, it might want to resynch with its peers at fairly
high frequency.

> Any: 1000 (proposed value)

Yes. (I think I would make the interface address part of the value
of the objective, but that's a design detail.) This is quite easy
to represent. The CBOR diagnostic format of the messages for a simple
case (the money negotiation I showed a couple of meetings ago) is
something like this:

discovery   [1, 6075274, ["money", 0, 6]]
response    [2, 6075274, [h'2406e007617d000128ccdc4c97036781']]
request     [3, 5320019, ["money", 1, 6, 100]]
negotiate   [4, 5320019, ["money", 1, 5, 75]]
negotiate   [4, 5320019, ["money", 1, 4, 50]]
end(accept) [5, 5320019, [101]]

(The flag is 0 for discovery, 1 for negotiate. The loop count
starts at 6 which is the proposed default.)

so yours would start, for example,

discovery   [1, 2718185, ["metric", 0, 6]]
response    [2, 2718185, [h'2406e007617d000128ccdc4c97036781']]
request     [3, 6417312, ["metric", 1, 6, [h'0a010203', 1000]]

> E.g. the Manifest of the load balancing ASA used above would have in its Manifest an entry in its Possible Actions that would be : Metric of interface [email-masked]

Yes. But it seems likely that the ASA will be coded to handle the metric of
any interface that it discovers, which is why I suggest it should be a
part of the objective value. However, I can see that it also needs to
be mentioned in the manifest.

So this all seems to work.

   Brian