Subject: Re: [Anima] GRASP, discovery, and roles

From: "jmh.direct" <[email-masked]>
Date: Thu, 07 Apr 2016 20:52:28 -0300

As I understand it, if an entity has at least one cached answer, it will send me that and stop propagating mybrequedt.  And it can't tell if the answer is insufficient.Yours,Joel

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Liubing (Leo)" <[email-masked]> Date: 4/7/2016  7:38 PM  (GMT-03:00) To: "Joel M. Halpern" <[email-masked]>, Anima WG <[email-masked]> Subject: RE: [Anima] GRASP, discovery, and roles 
> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, April 07, 2016 7:25 PM
> To: Liubing (Leo); Anima WG
> Subject: Re: [Anima] GRASP, discovery, and roles
> 
> If I could just ignore some responses, and be sure I would get the other
> responses, that would be a way to solve the problem.  But as far as I
> understand GRASP< that isn't what happens.  My discovery might prompt
> several answers, but along any given branch it stops when it hits any responder,
> even if they are just another participant.

[Bing] This is the "multiple responses" open issue we used to discuss. 
GRASP will not stop receiving other responses, (actually it just can't), according to discussion in last ietf, people tended to handle the multiple responses to ASA, who will decide to use which discovered result. I think we'll need to clearly specify the behavior in the API document.

B.R.
Bing

> 
> Yours,
> Joel
> 
> On 4/7/16 6:16 PM, Liubing (Leo) wrote:
> >> -----Original Message-----
> >> From: Joel M. Halpern [mailto:[email-masked]]
> >> Sent: Thursday, April 07, 2016 6:57 PM
> >> To: Liubing (Leo); Anima WG
> >> Cc: Brian E Carpenter
> >> Subject: Re: [Anima] GRASP, discovery, and roles
> >>
> >> Given that I register in order to participate in teh discovery, it
> >> seems that I could just as easily end up "discovering" another
> >> participant when what I need is the coordinator.
> >
> > [Bing] In terms of GRASP terminology, what you need is the "coordination
> function/service", and the one who response you, implies it is a "coordinator"
> or whatever role which could provide identical coordination function/service as
> the "coordinator". So, just don't worry about the one who response you is
> "another" guy who is not qualified to serve you.
> >
> > Did I capture your concern correctly?
> >
> > B.R.
> > Bing
> >
> >> Am I mis-reading it?
> >>
> >> Yours,
> >> Joel
> >>
> >> On 4/7/16 5:48 PM, Liubing (L

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2016 13:40:48 +1200

On 08/04/2016 11:52, jmh.direct wrote:
> As I understand it, if an entity has at least one cached answer, it will send me that and stop propagating mybrequedt.

Actually I don't think that's how I coded it but that hardly matters; we can
review the spec to be unambiguous on that point.

But there's another point here which may need to be made a formal requirement
with some better terminology.

You can discover an objective without supporting it yourself. For example,
we want exactly one node to support the AN_Registrar objective but any other
node may need to discover it. That was kind of intuitive when coding my
prototype but we need to make it explicit.

    Brian

> And it can't tell if the answer is insufficient.Yours,Joel
> 
> 
>>>> _______________________________________________
>>>> Anima mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/anima

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 8 Apr 2016 10:28:30 +0200

Hello,

I think it should be explicit in the specification of the ASA life-cycle 
what it does when it boots (and in other phases as well):
     e.g. discover / register to (entities playing) special roles such 
as registrar, coordination, intent, knowledge index...

This set of "roles" and life-cycle must be fixed and specified by the 
standard, not left open to ASA developers' creativity because these are 
special roles/objectives that must be supported / understood by all ASAs 
/ or ANodes (proxy) agents.

What seems not fully defined yet is precisely a complete ASA life-cycle 
(cf discussion and drafts on the topic) and the minimal set of roles to 
deploy and have an autonomic networks ready for operation / operating.

Shall we upgrade the reference model document section on theory of 
operations with these aspects or should it be another doc?

FYI, draft-peloso-anima-autonomic-function attempts to describe such a 
life-cycle.

Best regards, Laurent.

-- 

Laurent Ciavaglia

Senior Research Manager

Bell Labs, Nokia

+33 160 402 636

Route de Villejust | 91620 Nozay | France

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 8 Apr 2016 07:42:59 -0400

Yes, I think the issue here is that folks assume "but of course you can 
do that", and it is even natural to implement, but not the conclusion 
that I got reading the spec.  So yes, a lot of what I am asking for 
probably is just more clarity in the spec.

Yours,
Joel

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Fri, 8 Apr 2016 12:45:10 +0000

Forblifecycle, i would like to see us define the "lame" model of "magically present on device" (classic router model of big blob software with everything you maybe need), and "good" where asa is an independent app that autonomic functions can download and install when and where needed.

One interesting question is how portable we would like good ASA to be.

Sent from my Samsung Captivate Glide on AT&T

Laurent Ciavaglia <[email-masked]> wrote:
Hello,

I think it should be explicit in the specification of the ASA life-cycle what it does when it boots (and in other phases as well):
    e.g. discover / register to (entities playing) special roles such as registrar, coordination, intent, knowledge index...

This set of "roles" and life-cycle must be fixed and specified by the standard, not left open to ASA developers' creativity because these are special roles/objectives that must be supported / understood by all ASAs / or ANodes (proxy) agents.

What seems not fully defined yet is precisely a complete ASA life-cycle (cf discussion and drafts on the topic) and the minimal set of roles to deploy and have an autonomic networks ready for operation / operating.

Shall we upgrade the reference model document section on theory of operations with these aspects or should it be another doc?

FYI, draft-peloso-anima-autonomic-function attempts to describe such a life-cycle.

Best regards, Laurent.

    Brian

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Liubing (Leo)" <[email-masked]><mailto:[email-masked]> Date: 4/7/2016  7:38 PM  (GMT-03:00) To: "Joel M. Halpern" <[email-masked]><mailto:[email-masked]>, Anima WG <[email-masked]><mailto:[email-masked]> Subject: RE: [Anima] GRASP, discovery, and roles

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, April 07, 2016 7:25 PM
To: Liubing (Leo); Anima WG
Subject: Re: [Anima] GRASP, discovery, and roles

B.R.
Bing

Yours,
Joel

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, April 07, 2016 6:57 PM
To: Liubing (Leo); Anima WG
Cc: Brian E Carpenter
Subject: Re: [Anima] GRASP, discovery, and roles

B.R.
Bing

Am I mis-reading it?

Yours,
Joel

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

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

--
Laurent Ciavaglia
Senior Research Manager
Bell Labs, Nokia

+33 160 402 636
Route de Villejust | 91620 Nozay | France
LinkedIn: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Apr 2016 08:34:49 +1200

Firstly I fully agree with Laurent; we need a lifecycle model to understand how
an ASA fits into the ecosystem. I think we aren't ready to write down the details
yet, though. (For example, it's obvious we need an ASA registration of some sort,
but I'm not yet convinced that all ASAs need to present a manifest.)

> Forblifecycle, i would like to see us define the "lame" model of "magically present on device" (classic router model of big blob software with everything you maybe need), and "good" where asa is an…

Yes, I think both cases are needed.

> One interesting question is how portable we would like good ASA to be.

Good question, indeed. I assume we want the infrastructure ASAs (the ones
that are really part of the ANI) to be fully portable. But for example
can the draft-ietf-anima-prefix-management ASA be identical on routers
from different vendors? And surely there will be some that really are
vendor-specific.

   Brian

---

From: John Strassner <[email-masked]>
Date: Tue, 12 Apr 2016 16:45:52 -0700

Hi Laurent,

> I think it should be explicit in the specification of the ASA
> life-cycle what it does...
>
> This set of "roles" and life-cycle must be fixed and specified
> by the standard...because these are special roles/objectives
> that must be supported / understood by all ASAs / or ANodes...

Agreed!

> What seems not fully defined yet is precisely a complete ASA
> life-cycle (cf discussion and drafts on the topic) and the
> minimal set of roles to deploy and have an autonomic networks
> ready for operation / operating.

I think that we need at least two things here:

   1) specification of the lifecycle of Autonomic Functions, and
   2) specification of the management of those Autonomic Functions

> Shall we upgrade the reference model document section on theory
> of operations with these aspects or should it be another doc?
>
life-cycle.

I think that the reference model needs updating; once that is updated, then
I think that the
above draft (day in the life) needs to update and expand on the that.

I'd like to help in both.

However, there is another additional issue. Draft-peloso talks about the
power of installing
autonomic functions beyond a simple known set that are "pre-installed".
This makes me think
of emergent behavior. It is one thing to support desired known behavior
that is pre-defined;
it is quite another to support new services that were not known when the
autonomic network
was originally installed. The latter is much more difficult, and perhaps
beyond our current
scope, but it would be nice if we could at least anticipate and start to
understand its needs
so that we do not box ourselves into a corner

regards,
John

On Fri, Apr 8, 2016 at 1:28 AM, Laurent Ciavaglia <
[email-masked]> wrote:

>     e.g. discover / register to (entities playing) special roles such as
> registrar, coordination, intent, knowledge index...
>
> special roles/objectives that must be supported / understood by all ASAs /
> or ANodes (proxy) agents.
>
> Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone-------- Original message --------From: "Liubing (Leo)" <[email-masked]> <[email-masked]> Date: 4/7/2016  7:38 PM  (GMT-03:00) To: "Joel M. Halpern" <[email-masked]> <[email-masked]>, Anima WG <[email-masked]> <[email-masked]> Subject: RE: [Anima] GRASP, discovery, and roles
>
> From: Joel M. Halpern [mailto:[email-masked] <[email-masked]>]
> From: Joel M. Halpern [mailto:[email-masked] <[email-masked]>]
> Anima mailing [email-masked]://www.ietf.org/mailman/listinfo/anima
>
> Anima mailing [email-masked]://www.ietf.org/mailman/listinfo/anima
>
>
> --
>
> Laurent Ciavaglia
>
> Senior Research Manager
>
> Bell Labs, Nokia
>
>
>
> +33 160 402 636
>

-- 
regards,
John

---

From: "Peloso, Pierre (Nokia - FR)" <[email-masked]>
Date: Thu, 14 Apr 2016 19:44:59 +0000

Hi John,

I share your views on the actions to be taken and the directions to follow.
We’ll set ourselves at work on these items pretty soon with the intention to take into account the feed-back we had during the meeting and the comments on the mailing list.
Your support will be much appreciated then...

Cheers,

Pierre

PS: Agreed on the approach of future behaviors (or future type of autonomic functions which reach farther than a pure ANI). We need at least to set a solution that would not be blocking us when we’ll want to extend it to those.

De : Anima [mailto:[email-masked]] De la part de John Strassner
Envoyé : mercredi 13 avril 2016 01:46
À : Ciavaglia, Laurent (Nokia - FR); John Strassner
Cc : jmh.direct; Anima WG; Joel M. Halpern; Liubing (Leo)
Objet : Re: [Anima] GRASP, discovery, and roles

Hi Laurent,

Agreed!

> FYI, draft-peloso-anima-autonomic-function attempts to describe such a life-cycle.

I think that the reference model needs updating; once that is updated, then I think that the
above draft (day in the life) needs to update and expand on the that.

However, there is another additional issue. Draft-peloso talks about the power of installing
autonomic functions beyond a simple known set that are "pre-installed". This makes me think
of emergent behavior. It is one thing to support desired known behavior that is pre-defined;
it is quite another to support new services that were not known when the autonomic network
was originally installed. The latter is much more difficult, and perhaps beyond our current
scope, but it would be nice if we could at least anticipate and start to understand its needs
so that we do not box ourselves into a corner

regards,
John

On Fri, Apr 8, 2016 at 1:28 AM, Laurent Ciavaglia <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Best regards, Laurent.

    Brian

-----Original Message-----

B.R.

Bing

Yours,

Joel

-----Original Message-----

Cc: Brian E Carpenter

B.R.

Bing

Am I mis-reading it?

Yours,

Joel

Anima mailing list

Anima mailing list

--
Laurent Ciavaglia
Senior Research Manager
Bell Labs, Nokia

+33 160 402 636

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Fri, 15 Apr 2016 21:55:36 -0700

Hi Pierre,

thanks for your note; you can count on my support.

best regards,
John

On Thu, Apr 14, 2016 at 12:44 PM, Peloso, Pierre (Nokia - FR) <
[email-masked]> wrote:

> We’ll set ourselves at work on these items pretty soon with the intention
> to take into account the feed-back we had during the meeting and the
> comments on the mailing list.
>
> PS: Agreed on the approach of future behaviors (or future type of
> autonomic functions which reach farther than a pure ANI). We need at least
> to set a solution that would not be blocking us when we’ll want to extend
> it to those.
>
>
>
> *De :* Anima [mailto:[email-masked]] *De la part de* John
> Strassner
> *Envoyé :* mercredi 13 avril 2016 01:46
> *À :* Ciavaglia, Laurent (Nokia - FR); John Strassner
> *Cc :* jmh.direct; Anima WG; Joel M. Halpern; Liubing (Leo)
> *Objet :* Re: [Anima] GRASP, discovery, and roles
>
>
>
> Hi Laurent,
>
>
>

-- 
regards,
John