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

["Michael Behringer (mbehring)" <[e-mail]>]

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! ☺

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]<mailto:[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]<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]<mailto:[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]<mailto:[e-mail]>
> >>
> >>
> >> Best regards,
> >>
> >> Sheng
>
> _______________________________________________
> Anima mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/anima



--
regards,
John