Subject: Re: [Anima] Request for review of GRASP requirements

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 10 Sep 2015 17:11:29 +0200

Dear Brian, all,

Thanks for your reply.

Please see inline for further discussion/clarification.

Best regards, Pierre and Laurent.

On 01/09/2015 00:45, Brian E Carpenter wrote:

[snip]

> 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 ?
> 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.)
Ok.
Draft-ietf-anima-autonomic-control-plane-00 mentions the possible use of 
GRASP for the discovery function of the ACP.
Our question is thus: what is the typical protocol stack to support 
running GRASP (more largely an ANIMA network)? e.g. GRASP over ACP, 
GRASP over TLS, GRASP over XYZ...? and how these options 
inter-operate/interact.
One example is: if GRASP needs the ACP to run first (providing the 
secure context), and that the ACP is depending on GRASP to discover 
adjacent nodes... then how is this started consistently?
Beyond this naive example, we think it would be wise to document 
somewhere in the ANIMA drafts such typical scenarios/stacks, if the end 
goals is to provide protocol specifications and interoperable 
implementations (i.e. minimizing the interpretation errors and holes).

>
>> 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)?
> 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.
Making the definitions/assumptions explicit should indeed improve the 
specifications/clarity.
Even better, why not consider the different initial cases such as:
     -naked device (i.e. most general/minimal case).
     -pre-loaded device.
     -...
and describe the steps / sequence for each cases (with possible 
complementarity/overlap).

Related to the above point on the minimal stack to support in ANIMA, we 
could then envisage the following:
     -case 1: ACP established, then discover/fetch other 
protocols/functions (could include fetch/load GRASP).
     -case 2: ACP/GRASP established/running, then discover/fetch other 
protocols/functions  e.g. ASAs)
     -case 3: When device connects, just link-broadcast an ANIMA 
"Hello", then discover/fetch/start ACP, GRASP...

>
>>      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)
> 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.
Our point is that ASA/AF need a management for themselves, to take care 
of their lifecycle/phases: installation, deployment, operation, 
deletion... and the subsequent point would then be whether this ASA 
management could/should be supported by GRASP or as a separate protocol...

>>      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.
Ok... This is a key question as it pertains to the base/common 
functionalities provided by the ANIMA stack (e.g. bootstrap, discover, 
negotiate...) and how to decide which function is in or out..
Note that we could imagine a" multi-layer" ANIMA stack composed of:
     -ANIMA stack_layer_0: base functionalities
     -ANIMA stack_layer_1: layer_0 + coordination + xyz + ...
     -ANIMA stack_layer_n: optional / more sophisticated functions...
These stacks could also be dependent/loaded based on the context of 
deployment/use, i.e. more or less constrained or mission-critical 
network(s), operator's level of requirements on security, performance, 
availability, stability...

As an example, what if we deploy a current-base ANIMA network (i.e. 
without coordination) and the deployed ASAs conflict / generate 
instabilities or performance degradation...
Why not embed at least some default coordination primitives (GRASP could 
support it via its negotiation mechanism) to avoid uncontrolled 
behaviors and provide minimal means for the operators to keep control?

>> 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).
Agreed for the negotiation among ASAs sharing a same objective (as 
defined in GRASP), however when different (groups of) ASAs compete over 
multiple (disjoint or correlated) objectives, the system may not be 
stable / converging.
IMHO, ASA should be considered (first) as rogue/selfish (we could extend 
to initially unknown, insecure...) as the general case and make sure our 
protocols works fine in this context. If we are in a more friendly 
environment then "qui peut le plus, peut le moins" as we say in French).
ASA would most probably be software designed and coded by different 
vendors, with different purposes/objectives/performances, so in our 
particular standardization context we have to take care of such a situation.
A good example are the 3GPP SON functions, which are all nice 
individually, but evil when all active together.
More generally, this is similar to the assumption for security (secure 
bootstrap) (in our case we could call it "security of the operating 
phase"). If we consider an open and multi-vendor market, with no/limited 
quality testing, we should plan ahead for some level of control over the 
collective behaviors of ASAs.

>> 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.
> 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.
Ok, the objectives should be registered consistently otherwise it will 
diverge and there will be no two same objectives/roles (even for the 
same function/ASA).
Another approach would be to rely on a dynamically loaded 
"dictionary"... (with the well-known good/bad/difficult implications).

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

Ok. We will put that in a new draft describing Autonomic Functions 
management.

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

Ok. We will detail more in a new version of the coordination draft (how 
coordination and GRASP would work together) and in the Autonomic 
Function draft to explain the management of ASA, and their lifecycle.

>> 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.
Agreed, the synchronization objective seems generic enough to carry any 
type of information.
Having thought more about this point, it might not be desirable to 
"embed"/hook the information exchange / knowledge plane aspect directly 
onto GRASP.
Such exchanges between ASAs (or between ASAs and other entities) will 
have different characteristics (volume and frequency of information, 
mode of transmission/replication/storage, connectivity matrix...) and 
thus would require more sophisticated/advanced capabilities than GRASP 
provides (even beyond the model described in section 3.2).

>> 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.
What we meant is when group(s) of ASAs act together to realize the 
function, for instance over sub-areas of the network. These ASAs would 
work as a coordinated "team". Such behavior/configuration could be 
specified in/by the intent.

>> 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.
We think that the ANIMA-Intent could convey such pieces of information, 
and the ANode could deduce/define which ASAs to load in order to achieve 
the goals assigned to the autonomic device/node.

Overall, we thank you for the feedback and will write down some more 
precise requirements in the draft(s), hopefully converging towards more 
robust/complete ANIMA components.

>      Brian
>
>> 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,
>>>
>>> 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
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> 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: 
<mailto:[email-masked]>[email-masked]

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

address: Route de Villejust | 91620 Nozay | France

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Sep 2015 08:39:44 +1200

Hi there,

On 11/09/2015 03:11, Laurent Ciavaglia wrote:
>>> 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 ?

> Ok.
> Draft-ietf-anima-autonomic-control-plane-00 mentions the possible use of GRASP for the discovery function of the ACP.
> Our question is thus: what is the typical protocol stack to support running GRASP (more largely an ANIMA network)? e.g. GRASP
> over ACP, GRASP over TLS, GRASP over XYZ...? and how these options inter-operate/interact.
> One example is: if GRASP needs the ACP to run first (providing the secure context), and that the ACP is depending on GRASP to
> discover adjacent nodes... then how is this started consistently?

That is not entirely clear yet and is really part of the secure bootstrap
discussion. Personally I am pretty certain that there is inevitably a
brief insecure discovery phase before the first secure operation is
possible.

> Beyond this naive example, we think it would be wise to document somewhere in the ANIMA drafts such typical scenarios/stacks, if
> the end goals is to provide protocol specifications and interoperable implementations (i.e. minimizing the interpretation errors
> and holes).

Yes, there certainly needs to be a security analysis of the bootstrap and
ACP formation process.

> Making the definitions/assumptions explicit should indeed improve the specifications/clarity.

Sorry, I don't really understand that.

>     -pre-loaded device.
>     -...
> and describe the steps / sequence for each cases (with possible complementarity/overlap).
> 
> Related to the above point on the minimal stack to support in ANIMA, we could then envisage the following:
>     -case 1: ACP established, then discover/fetch other protocols/functions (could include fetch/load GRASP).

I will leave that for Michael Behringer, but I think his model is that ACP formation
will make use of GRASP discovery itself. So that is closer to your case 3.

>     -case 2: ACP/GRASP established/running, then discover/fetch other protocols/functions  e.g. ASAs)
>     -case 3: When device connects, just link-broadcast an ANIMA "Hello", then discover/fetch/start ACP, GRASP...
> 

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

> Our point is that ASA/AF need a management for themselves, to take care of their lifecycle/phases: installation, deployment,
> operation, deletion... and the subsequent point would then be whether this ASA management could/should be supported by GRASP or
> as a separate protocol...

I suggest trying to formulate this in the reference model. At the moment
I don't see clearly where it fits. It's certainly outside the initial scope
of GRASP as we conceived it.

> Ok... This is a key question as it pertains to the base/common functionalities provided by the ANIMA stack (e.g. bootstrap,
> discover, negotiate...) and how to decide which function is in or out..
> These stacks could also be dependent/loaded based on the context of deployment/use, i.e. more or less constrained or
> mission-critical network(s), operator's level of requirements on security, performance, availability, stability...
> 
> As an example, what if we deploy a current-base ANIMA network (i.e. without coordination) and the deployed ASAs conflict /
> generate instabilities or performance degradation...
> Why not embed at least some default coordination primitives (GRASP could support it via its negotiation mechanism) to avoid
> uncontrolled behaviors and provide minimal means for the operators to keep control?

That seems reasonable, but then it becomes a required feature for each ASA to
support those primitives. The question for you is whether the proposed message
types are adequate (basically Request/Negotiate/End).

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

One of the reasons that I personally am very attracted to the CBOR approach
is that it makes adding a new message type or option very easy.

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

> Agreed for the negotiation among ASAs sharing a same objective (as defined in GRASP), however when different (groups of) ASAs
> compete over multiple (disjoint or correlated) objectives, the system may not be stable / converging.
> IMHO, ASA should be considered (first) as rogue/selfish (we could extend to initially unknown, insecure...) as the general case
> and make sure our protocols works fine in this context. If we are in a more friendly environment then "qui peut le plus, peut le
> moins" as we say in French).
> ASA would most probably be software designed and coded by different vendors, with different purposes/objectives/performances, so
> in our particular standardization context we have to take care of such a situation.
> A good example are the 3GPP SON functions, which are all nice individually, but evil when all active together.
> More generally, this is similar to the assumption for security (secure bootstrap) (in our case we could call it "security of the
> operating phase"). If we consider an open and multi-vendor market, with no/limited quality testing, we should plan ahead for
> some level of control over the collective behaviors of ASAs.
> 
>>> 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.
> Ok, the objectives should be registered consistently otherwise it will diverge and there will be no two same objectives/roles
> (even for the same function/ASA).
> Another approach would be to rely on a dynamically loaded "dictionary"... (with the well-known good/bad/difficult implications).
> 
>>> 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).
> Ok. We will put that in a new draft describing Autonomic Functions management.
> 
>>
>>> 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.
> Ok. We will detail more in a new version of the coordination draft (how coordination and GRASP would work together) and in the
> Autonomic Function draft to explain the management of ASA, and their lifecycle.
> 
> Agreed, the synchronization objective seems generic enough to carry any type of information.
> Having thought more about this point, it might not be desirable to "embed"/hook the information exchange / knowledge plane
> aspect directly onto GRASP.
> Such exchanges between ASAs (or between ASAs and other entities) will have different characteristics (volume and frequency of
> information, mode of transmission/replication/storage, connectivity matrix...) and thus would require more
> sophisticated/advanced capabilities than GRASP provides (even beyond the model described in section 3.2).
> 
> 
> What we meant is when group(s) of ASAs act together to realize the function, for instance over sub-areas of the network. These
> ASAs would work as a coordinated "team". Such behavior/configuration could be specified in/by the intent.
> 
> We think that the ANIMA-Intent could convey such pieces of information, and the ANode could deduce/define which ASAs to load in
> order to achieve the goals assigned to the autonomic device/node.
> 
> Overall, we thank you for the feedback and will write down some more precise requirements in the draft(s), hopefully converging
> towards more robust/complete ANIMA components.

Thanks!
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 11 Sep 2015 15:08:44 +0000

[...]
> GRASP over TLS, GRASP over XYZ...? and how these options inter-
> operate/interact.
> discussion. Personally I am pretty certain that there is inevitably a brief
> insecure discovery phase before the first secure operation is possible.

Agree, I think this is unavoidable. My view was always there is a simple protocol running link local that keeps a data base of neighbors up to date, with unconfirmed, insecure data from those neighbors. In that DB there may be a few devices that claim to be from the same domain. And at this point it's just a claim. 

THEN we try to establish an ACP tunnel to all neighbors that CLAIM to be from the same domain. Part of that is mutual authentication with the domain certificate, from that point on it's secure. 

There is some discussion in the bootstrap team right now whether those should be really separate, but let's leave that discussion to the bootstrap list for now...
 
> > somewhere in the ANIMA drafts such typical scenarios/stacks, if the
> > end goals is to provide protocol specifications and interoperable
> Yes, there certainly needs to be a security analysis of the bootstrap and ACP
> formation process.

Indeed. 

> >>>      2. "Autonomic devices" are written as well, (are those the autonomic
> nodes of the model, or could that be something else)?
> 
> I will leave that for Michael Behringer, but I think his model is that ACP
> formation will make use of GRASP discovery itself. So that is closer to your
> case 3.

Frankly, I don't understand those cases completely. But I concur with Brian, my thinking sounds most like case 3.
 
> >>>      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)
> 
> >> 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.
> 
> > Our point is that ASA/AF need a management for themselves, to take
> > care of their lifecycle/phases: installation, deployment, operation,
> > deletion... 

Sure. In my view that's a higher level function than what we're discussing here. In other words, a domain will first bootstrap the ACP and other AN Infrastructure components. THEN it will go about installing / running / managing autonomic functions, using the ANI. 

> and the subsequent point would then be whether this ASA

Yes, definitely, GRASP has a role to play here. For example, an autonomic node may signal to another node "we need to run the energy optimisation function". Or sync state about a specific function, etc. 
 
> I suggest trying to formulate this in the reference model. At the moment I
> don't see clearly where it fits. It's certainly outside the initial scope of GRASP
> as we conceived it.

I don't think it is ;-)   GRASP allows for negotiation, synchronisation, etc. Also the installation of a function may need to be synchronised, for example. GRASP is one tool in the tool kit. (and a very important one)

[...]

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Sep 2015 08:17:29 +1200

A comment right at the end...

> I don't think it is ;-)   GRASP allows for negotiation, synchronisation, etc. Also the installation of a function may need to be synchronised, for example. GRASP is one tool in the tool kit. (and a…

Certainly dialogue of the kind you suggest could be modelled as state
synchronization or even a negotiation of sorts. But actually downloading
and installing a new functions sounds like a stretch to me. Aren't there
existing solutions for that?

    Brian

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 14 Sep 2015 07:01:13 +0000

Context: Discussion is about the management of autonomic functions themselves. 

> >> I suggest trying to formulate this in the reference model. At the
> >> moment I don't see clearly where it fits. It's certainly outside the
> >> initial scope of GRASP as we conceived it.
> >
> > I don't think it is ;-)   GRASP allows for negotiation, synchronisation, etc.
> Also the installation of a function may need to be synchronised, for example.
> GRASP is one tool in the tool kit. (and a very important one)
> 
> synchronization or even a negotiation of sorts. But actually downloading and
> installing a new functions sounds like a stretch to me. Aren't there existing
> solutions for that?

Well, any function has a number of components and interactions. One of the things a function may need to do is to negotiate / synchronise. Others are: Download a file; send an alert; trigger a non-autonomic box to do something; make coffee; etc; 

So GRASP is a *part* of the toolkit, but there will be other interactions. Applied to managing a function: There will be a part which is some negotiation/synchronization, and a part which is something else, ex: A download. 

I'd be really surprised if we weren't thinking the same way here? 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Sep 2015 08:01:09 +1200

> I'd be really surprised if we weren't thinking the same way here? 

I think we are. With my GRASP editor hat on, I am quite fussy about what
needs to be added to the GRASP spec though; I don't think I need to add
a "download a new ASA Python script" message type ;-).

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 15 Sep 2015 06:09:27 +0000

[...]
> >> synchronization or even a negotiation of sorts. But actually
> >> downloading and installing a new functions sounds like a stretch to
> >> me. Aren't there existing solutions for that?
> >
> > Well, any function has a number of components and interactions. One of
> > the things a function may need to do is to negotiate / synchronise.
> > Others are: Download a file; send an alert; trigger a non-autonomic
> > box to do something; make coffee; etc;
> >
> > So GRASP is a *part* of the toolkit, but there will be other interactions.
> Applied to managing a function: There will be a part which is some
> negotiation/synchronization, and a part which is something else, ex: A
> download.
> >
> needs to be added to the GRASP spec though; I don't think I need to add a
> "download a new ASA Python script" message type ;-).

Definitely not. GRASP is just one tool, there are others. GRASP doesn't need to solve all our problems on its own ;-) 

Michael