Re: [Anima] Some comments for draft-carpenter-anima-gdn-protocol

[John Strassner <[e-mail]>]

Hallo Michael,

inline as well...look for <jcs>..</jcs>

Hallo Michael,

it's been a long time. :-)



MB: Indeed – the world is small! J



I understand, and agree, with your first point.



Regarding the second point, I understand your point about fully autonomic
nodes. In addition, I think the WG should be commended for worrying about
legacy elements and processes from the outset.



First question: could I characterize your approach as having three types of
nodes: fully autonomic, autonomically-aware, and autonomically-unaware? An
autonomically-aware node is one that fully autonomic nodes can communicate
with, and which understands (perhaps after translation) what functions are
required of it and what functions it can offer. An autonomically-unaware
node is a dumb rock (e.g., a hub).


MB: Yes, we’re essentially thinking along the same lines, but phrase it
differently. We agree on “fully autonomic”, that’s the easy one.

Now, your “autonomically-aware” definition translates in our world to
“supports the Autonomic Networking Infrastructure”, which is exactly what
we’re defining right now in ANIMA. I think this definition has two
sub-flavours:

a)      the node supports the AN Infrastructure  and one or several
autonomic service agents (but is not fully autonomic)

b)      the node supports the AN Infrastructure, but may not be aware of
autonomic service agents that run on other nodes.

<jcs>

I'm with you so far...

</jcs>


Point a) is a subset of b). Example: topology is A----B----C. All nodes
support the AN infrastructure. A and C should be able to negotiate
parameters for an autonomic service agents, even if B doesn’t implement
that function.



<jcs>

By subset, do you subclass?

If "C" is a fully autonomic node, then I'm happy and understand. If not,
then I'm confused.

</jcs>


I think it’s pretty obvious. I just want to point out that in our thinking
there is infrastructure and autonomic service agents. An “autonomically
aware” node MUST have the AN infrastructure, and MAY have autonomic service
agents.


<jcs>

This makes perfect sense.

Agents are obvious - enough so that I forgot to mention them :-)

However, since you bring them up, are you assuming full FIPA compliant
agents, or something else? Not having decided yet is fine too.

</jcs>


BTW, an “autonomically unaware” node is not just a dumb rock like a hub.
Also traditional devices (e.g. routers) which do not support the AN
infrastructure fall into that category.


<jcs>

Agreed. I was giving the traditional router the benefit of the doubt :-)
but for this purpose, yes, it is a dumb rock.

</jcs>


Then, I could say that an autonomic function is either be supported
directly by a fully autonomic node, or built from a set of nodes (some of
which are not capable of performing autonomic functions).



MB: I think when you say “autonomic function” you mean a function across
various nodes, right? In our wording, a node runs an autonomic service
agent. A group of such nodes implement an autonomic function.


<jcs>

Yes, agreed

</jcs>


Second question: performing an autonomic function is a set of behaviors.
What's important is the end result, not the individual behaviors. So, as
long as each individual behavior can be rigorously defined (e.g., using a
software contract, where the behavior satisfies a set of pre- and
post-conditions as well as a set of invariants), then (in theory) they
should be able to be composited together.


What’s the question? ;-)   Yes, I agree. The Autonomic Control Plane is an
example of this. Each nodes carries out a few local actions (authenticating
neighbors, building tunnels to them, etc), and the net result is a
self-managing overlay network with some nice properties.


<jcs>

Oops, sorry. My caffeine/blood ratio must have been too low. :-)

My question was how the behaviors are composited. When I built similar
functionality, I used software contracts to manage the functions performed
by the agents. At the time, I didn't see many other examples of this, so I
was curious if ANIMA had thought about how to standardize the agent
behavior? With software contracts, this becomes easier, as the function is
characterized by the contract. Make sense?

</jcs>


Thanks for your input and validation of our work!

Michael



<jcs>

I now understand a lot more, thanks to you, Brian, and Sheng for your
answers and patience. I think the work is promising, and would like to
participate.

</jcs>


Thoughts?





best regards,

John


mfg,
John


On Thu, Mar 12, 2015 at 1:17 AM, Michael Behringer (mbehring) <
[e-mail]> wrote:

>  Inline….
>
>
>
> *From:* John Strassner [mailto:[e-mail]]
> *Sent:* 12 March 2015 02:23
> *To:* Michael Behringer (mbehring); John Strassner
> *Cc:* Brian E Carpenter; John Strassner; Liubing (Leo); Anima WG
> *Subject:* Re: [Anima] Some comments for
> draft-carpenter-anima-gdn-protocol
>
>
>
> Hallo Michael,
>
> it's been a long time. :-)
>
>
>
> MB: Indeed – the world is small! J
>
>
>
> I understand, and agree, with your first point.
>
>
>
> Regarding the second point, I understand your point about fully autonomic
> nodes. In addition, I think the WG should be commended for worrying about
> legacy elements and processes from the outset.
>
>
>
> First question: could I characterize your approach as having three types
> of nodes: fully autonomic, autonomically-aware, and
> autonomically-unaware? An autonomically-aware node is one that fully
> autonomic nodes can communicate with, and which understands (perhaps after
> translation) what functions are required of it and what functions it can
> offer. An autonomically-unaware node is a dumb rock (e.g., a hub).
>
>
>
> MB: Yes, we’re essentially thinking along the same lines, but phrase it
> differently. We agree on “fully autonomic”, that’s the easy one.
>
> Now, your “autonomically-aware” definition translates in our world to
> “supports the Autonomic Networking Infrastructure”, which is exactly what
> we’re defining right now in ANIMA. I think this definition has two
> sub-flavours:
>
> a)      the node supports the AN Infrastructure  and one or several
> autonomic service agents (but is not fully autonomic)
>
> b)      the node supports the AN Infrastructure, but may not be aware of
> autonomic service agents that run on other nodes.
>
> Point a) is a subset of b). Example: topology is A----B----C. All nodes
> support the AN infrastructure. A and C should be able to negotiate
> parameters for an autonomic service agents, even if B doesn’t implement
> that function.
>
> I think it’s pretty obvious. I just want to point out that in our thinking
> there is infrastructure and autonomic service agents. An “autonomically
> aware” node MUST have the AN infrastructure, and MAY have autonomic service
> agents.
>
>
>
> BTW, an “autonomically unaware” node is not just a dumb rock like a hub.
> Also traditional devices (e.g. routers) which do not support the AN
> infrastructure fall into that category.
>
>
>
> Then, I could say that an autonomic function is either be supported
> directly by a fully autonomic node, or built from a set of nodes (some of
> which are not capable of performing autonomic functions).
>
>
>
> MB: I think when you say “autonomic function” you mean a function across
> various nodes, right? In our wording, a node runs an autonomic service
> agent. A group of such nodes implement an autonomic function.
>
>
>
> Second question: performing an autonomic function is a set of behaviors.
> What's important is the end result, not the individual behaviors. So, as
> long as each individual behavior can be rigorously defined (e.g., using a
> software contract, where the behavior satisfies a set of pre- and
> post-conditions as well as a set of invariants), then (in theory) they
> should be able to be composited together.
>
>
>
> What’s the question? ;-)   Yes, I agree. The Autonomic Control Plane is an
> example of this. Each nodes carries out a few local actions (authenticating
> neighbors, building tunnels to them, etc), and the net result is a
> self-managing overlay network with some nice properties.
>
>
>
> Thanks for your input and validation of our work!
>
> Michael
>
>
>
>
>
> Thoughts?
>
>
>
>
>
> best regards,
>
> John
>
>
>
>
>
>
>
> On Wed, Mar 11, 2015 at 3:42 AM, Michael Behringer (mbehring) <
> [e-mail]> wrote:
>
> John,
>
> Adding to Brian/Sheng my view, there are two important points to note:
>
> 1) What you see now is just the start. In this first phase we're not
> actually standardising any autonomic service agents (as we call them), but
> we're preparing an infrastructure for such agents. Meaning, such agents can
> count on all the "mechanics" to talk to other agents: Addressing, routing,
> security, simple discovery, negotiation, etc. We call this the autonomic
> networking infrastructure, and our goal is to make this infrastructure
> "self-managing" itself, specifically, it should self-configure.
>
> This infrastructure is not complete, as you correctly point out. But all
> of the functions you mention (e.g., knowledge exchange) first of all
> require a solid communications infrastructure.
>
> In the WG charter you see the elements of the infrastructure, and a couple
> of use cases for autonomic service agents. In this first phase the
> intention is to validate the autonomic networking infrastructure with those
> use cases. See also the UCAN BoF notes, where more use cases were
> discussed. Again, we're looking at simple use cases to start with, and work
> bottom-up.
>
> 2) We are not trying to define fully autonomic nodes, but autonomic
> functions. In other words, we expect nodes to be partially managed in the
> traditional way, and some functions to be autonomic. In the future there
> may be cases of fully autonomic nodes.
>
> As we take on new use cases, we define their requirements, and address the
> delta in the autonomic networking infrastructure, bottom up. With the
> reference model we need to make sure that we're not going down a track that
> will make future use cases impossible or hard to support. This is of course
> the main challenge. Your input would be very valuable in this process.
>
> What are your thoughts?
>
> Michael
>
>
> > -----Original Message-----
> > From: Anima [mailto:[e-mail]] On Behalf Of Brian E
> > Carpenter
> > Sent: 10 March 2015 04:41
> > To: John Strassner
> > Cc: Liubing (Leo); Anima WG; [e-mail]
> > Subject: Re: [Anima] Some comments for draft-carpenter-anima-gdn-
> > protocol
> >
> > Hi John and everybody,
> >
> > Replying to some comments received privately, on the list with
> permission:
> > On 09/03/2015 22:55, Sheng Jiang wrote:
> > > Hi, authors of draft-carpenter-anima-gdn-protocol
> > >
> > > The below are some comments from my colleague, Dr. John Strassner.
> > Although I personally think your protocol designs have the ability to
> meet
> > his requirements for knowledge exchanging among autonomic nodes, it is
> > better you could discuss directly and maybe include some
> > modification/clarification in the future version. I also encourage you to
> > discuss this in ANIMA mail list openly.
> > >
> > > Best regards,
> > >
> > > Sheng
> > >
> > >> -----Original Message-----
> > >> From: John Strassner
> > >> Sent: Friday, March 06, 2015 6:43 AM
> > >> To: Sheng Jiang; John Strassner
> > >>
> > >> Dear Sheng,
> > >>
> > >> I read the charter and am starting on the drafts.
> > >>
> > >>>> autonomics require the ability to share and exchange knowledge in
> > >>>> an interoperable fashion. I fail to see how this is even discussed
> > >>>> in ANIMA.
> > >>>
> > >>> BTW, the ability to share and exchange knowledge in an interoperable
> > >>> fashion looks like GNDP (Generic Discovery and Negotiation Protocol)
> > >>> in ANIMA. This protocol is designed to support information discovery
> > >>> and bi-direction negotiation.
> > >>
> > >> It appears that GDNP covers some, but not all, of what I am talking
> about.
> >
> > Indeed, it isn't claiming to cover everything. The idea is that draft-
> > behringer-anima-reference-model will evolve to show how things fit
> > together, which will help us to identify holes.
> >
> > >> However, the following statement from the GDNP draft is misleading,
> > >> if not just plain wrong:
> > >>
> > >> "In order to fulfil autonomy, devices that embody autonomic service
> > >> agents need to be able to discover each other, to synchronize state
> > >> with each other, and to negotiate parameters and resources directly
> > >> with each other."
> > >>
> > >> First, autonomic networks are not necessarily autonomous. Autonomy,
> > >> in its most generic form, is the ability to have the power for an
> > >> entity to govern itself. If every network element governs itself
> > >> without regard to other, higher level principles, you don't even have
> > >> a network. :-)
> >
> > Sure. That is the role for what we call "intent" which is defined in
> draft-irtf-
> > nmrg-autonomic-network-definitions but is not yet in Anima scope.
> >
> > >> Second, the three concepts mentioned in the above excerpt
> > >> (discoverability, synchronization of state, and parameter
> > >> negotiation) are necessary but clearly not sufficient to have
> > >> autonomic operation. I was talking about the ability to exchange
> > >> knowledge (e.g., all or part of an information model) between
> > >> entities. It doesn't appear that this is covered in ANIMA yet, though
> I
> > haven't read all of the materials.
> >
> > My personal view is that this is going to be resolved topic by topic.
> > In GDNP-speak that means that it will be resolved by individual Objective
> > definitions, and GDNP will just act as a neutral carrier. (You can quite
> fairly
> > argue that this means we are ducking the problem for now.) Another way to
> > say this is that each type of autonomous service agent will solve this
> > problem for its own target parameters.
> >
> > Now, again IMHO, this is why we state in GDNP that the format of the
> value
> > of an objective "...might be inherited from an existing management or
> > configuration protocol, the objective option acting as a carrier for that
> > format.  The data structure might be defined in a formal language, but
> that
> > is a matter for the specifications of individual objectives.  There are
> many
> > candidates, according to the context, such as ABNF, RBNF, XML Schema,
> > possibly YANG, etc.  The GDNP protocol itself is agnostic on these
> > questions."
> >
> > My expectation is that some objectives will need a formal information
> > model and that others won't, and that there's no reason we couldn't
> inherit
> > existing IMs when they are relevant. But that whole question is also out
> of
> > charter scope for now. As you know better than most people, John,
> defining
> > an IM can become a very laborious business and for now we want to get
> > started on simple cases that don't need it.
> >
> > >> If you cannot exchange knowledge, you will never be autonomic in the
> > >> computer science sense.
> >
> > You will find very similar words in draft-irtf-nmrg-an-gap-analysis.
> >
> > <snip>
> >
> > Regards
> >     Brian
> >
> > >> regards,
> > >> John
> > >>
> > >> Dr. John Strassner, Ph.D.
> > >> CTO, Software Laboratory, CRD
> > >>
> > >>
> > >> Futurewei Technologies
> > >> US R&D Center
> > >> 2330 Central Expressway
> > >> Building A, office A2-2143
> > >> Santa Clara, California   95050
> > >>  Office:  +1.408.330.4923
> > >>  Email:   [e-mail]
> > >>
> > >>
> > >> Best regards,
> > >>
> > >> Sheng
> >
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
>
>
>
>
> --
>
> regards,
>
> John
>



-- 
regards,
John