Subject: Re: [Anima] What we want to achieve - personal view.

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 1 Sep 2014 17:03:49 +0000

I agree. Could take a look if needed. Several aspects have been discussed on this that could help improving the initial/motivation part of the charter.

There is also a clarification to bring in the charter (also in this gap analysis doc)
" The task of autonomic networking is to build up individual autonomic
  decision processes that could properly combine to respond to every
  type of network event. "

There is a distinction to be made between "local" action and "individual" decision process. The latter should be avoided as we refer to cooperative decision process (among AN agents) translated locally into actions and their enforcement.

Thanks,
-dimitri.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, August 28, 2014 9:49 PM
> To: Toerless Eckert
> Cc: [email-masked]; Michael Behringer (mbehring)
> Subject: Re: [Anima] What we want to achieve - personal view.
> 
> On 28/08/2014 19:15, Toerless Eckert wrote:
> > Michael,
> >
> > This again looks like good analysis, but i wonder if we also need to
> > restate the operator visible problems that ultimately lead to these
> > conclusions better represented in the charter.
> 
> Agreed, that aspect of the problem statement is missing in the charter.
> I promised during the call yesterday to make the next update of the
> charter with this point and some others, and also to check back through
> the numerous emails to see if all the issues have been picked up.
> This will take a day or two
> 
> Regards
>    Brian
> 
> > The list of problems and target solutions or ANIMA the way i see it is
> > as follows: This could be separated into a list of problems and
> > another list of solution areas:
> >
> > - Manual labour intensive device/network bootstrap
> >   -> want secure zero touch bootstrap.
> >
> > - Fragile, config dependent, insecure NOC and/or SDN OAM connectivity
> >   -> want secure, zero touch, reliable OAM connectivity for NOC/SDN
> >
> > - High cost/risk in operating rich set of network services due to
> siloed,
> >   inconsistent re-implementation of common communications/security
> functions.
> >   -> want security, consistency though common functions
> >
> > - Expensive, per-device orchestration needed due to lack of
> >   network wide OAM interface to services (intent).
> >   -> want in-network services with network wide intent/reporting
> >      interface to NOC.
> >
> > - Lack of in-network control-loops for services outsources dynamic
> >   services adaptation to NOC - scale, performance, availability issues.
> >   -> Want common infrastructure components to self-orchestrate
> >      in network control loops. Want to build limited set of such
> >      self orchestrating services/agents.
> >
> > Cheers
> >     Toerless
> >
> >
> >
> >
> > On Sun, Aug 24, 2014 at 08:41:58PM +0000, Michael Behringer (mbehring)
> wrote:
> >> It is fairly clear that the charter isn't good enough yet, we had too
> many comments about this. Can we take a step back, look at the big
> picture, see whether we agree on that level, and THEN dive back down to
> writing something down?
> >>
> >> Here is how I would phrase it, informally. Train of thought:
> >>
> >> 1) Independent processes: Networks today have a number of processes
> that run distributed, and do things on their own. The admin monitors, and
> takes care of exceptions, but by and large these processes run on their
> own in the network. (I call that "autonomic", but the term itself has
> raised discussions, so let's leave that discussion for later, to stay
> focused). Examples are all the IGPs, VRRP, etc.
> >>
> >> 2) Lack of common infrastructure: All those processes run independently
> of each other. Each of them has its own way to communicate, manage policy
> (if applicable), secure itself, etc. This is where I am coming from: I
> used to work in infrastructure security, and the fact that you have to
> secure each protocol independently, each with its own key scheme,
> algorithms, etc is a major pain in operating networks today. This is the
> security angle, but other angles exist, for example monitoring, reporting,
> general policy, etc.
> >>
> >> The above to me is the problem statement. Why is that a problem that
> needs fixing? Because the operational cost of securing a network is a
> problem. And when opex is reduced, security suffers. Others may chime in
> with similar stories from their area of expertise, but I think it's a
> pretty generic issue.
> >>
> >> The goal then is:
> >>
> >> 3) Finding common infrastructure: Assume we accept for a moment that
> the lack of common functions across a network is an issue, can this be
> simplified? Can we define one, simple way to manage for example the key
> material for all the protocols, in one go? We tried to find a solution and
> came up with draft-pritikin-bootstrapping-keyinfrastructures; that draft
> describes how to securely bootstrap a key infrastructure, which can then
> be used to secure ALL protocols through the lifetime of the network (ie
> not one-off), largely without admin involvement. Again, this is the
> security angle; I think this is a use case in itself, but other cases
> exist.
> >>
> >> Now, if this work simplifies just a single aspect of networking (such
> as security), we'd have made progress, and IMO it would be worthwhile. If
> we can simplify several components of networking in this way, and if we do
> this in a coherent way, then we have the potential to really create a
> largely "self-managing" network. But frankly, I prefer the bottom up
> approach, let's tackle one function at a time, small steps. Of course,
> having an overall goal in mind.
> >>
> >> Now, does this train of thought make sense at all? Dimitri? Rene?
> Others?
> >>
> >> Michael
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/anima
> >
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 2 Sep 2014 01:32:37 +0000

>There is a distinction to be made between "local" action and "individual"
>decision process. The latter should be avoided as we refer to cooperative
>decision process (among AN agents) translated locally into actions and their
>enforcement.

Hi, Dimitri,

I think we share the same understanding. The difference came from the different understanding for the word "individual". When we wrote down "individual", we did mean distributed/local AND "individual" decision process. The word "individual" meant for different functions that may have separated decision processes, for example, routing management and mobility management, etc. If the word "individual" brings misunderstanding, we should work out another word, how about "separated", or "independent" or "specific"?

Best regards,

Sheng