Subject: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Jul 2014 14:34:41 -0400

Dear all,

- Make it clear that the definition means a logical OR

    Autonomic: Self-managing (self-configuring, self-protecting, self-
    healing and self-optimizing); however, allowing high-level guidance
    by a central entity, through intent.

-

    Intent: An abstract, high level policy used to operate the network
    autonomically.  Its scope is an autonomic domain, such as an
    enterprise network._It does not contain configuration or information
    for a specific node._  It may contain information pertaining to nodes
    with a specific role.

Well in the end, configuration or information for a specific node will be involved.
I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node, dealing with the intent you want to have from the network.

-  When I read "It requires no configuration" in ...

    Autonomic Function: A feature or function which requires no
    configuration, and can derive all required information either through
    self-knowledge, discovery or through intent.

    OR

    Fully Autonomic Node: A node which employs exclusively autonomic
    functions.  It requires no configuration.

... I wondered about an initial configuration before a device is shipped. Autonomic or not?
Coincidently, this was just discussed at the time of typing these lines, by Brian, presenting in NMRG.
I understand that this is automatic, right?
And I see a extra definition in draft-irtf-nmrg-an-gap-analysis-00

   o  Automatic: A process that occurs without human intervention, with
       step-by-step execution of rules.  However it relies on humans
       defining the sequence of rules, so is not Autonomic in the full
       sense.  For example, a start-up script is automatic but not
       autonomic.

draft-irtf-nmrg-autonomic-network-definitions would benefit from this definition in my opinion, and a few words on the difference between autonomic and automatic

-
Northbound interface. These days, with the SDN/controller story, this is a confusing term.
I would rephrase the section and the text inside
OLD:
3.4.  Simplification of the Northbound Interfaces
OLD:
3.4.  Simplification of the Autonomic Node Northbound Interfaces

-
3.7 Modularity
Section 3 intro says:

    This section explains the high level goals of Autonomic Networking,
    independent of any specific solutions.

Is this an Autonomic Networking design goal to be modular? Not really
I see this more like a good deployment practice, i.e. if you think about an autonomic protocol, please think of deployment, i.e. modularity

Regards, Benoit

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jul 2014 10:03:31 +1200

Thanks Benoit. Michael has the editing pen so I will only
comment on one point right now:

> I guess you want to rephrase that the intent is a general policy above configuration or information for a specific node,

I think it can also be for a specific role, where a bunch of nodes
can all fill that role (e.g. an intent that applies to all
CE routers, or all AFTRs,...).

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 21 Jul 2014 22:45:43 +0000

Let me expand a bit about intent versus configuration. 

For now, I stick to what is written in the document: 

1. Intent does NOT contain configuration. (note: "contain")
2. An autonomic function does not REQUIRE configuration. This does not mean that there couldn't be a function that runs in a default mode using only intent, but could be locally also use some configuration. 

So, to me, intent and configuration will co-exist, but configuration is not part of the autonomic part (which is why I think the doc is actually correct). 

There is a need for conflict resolution. And this works something like this: 

prio 0: default behaviour (without intent)
prio 1: intent
prio 2: other (netconf, SNMP, i2rs, CLI, ...)

In other words, a more specific guidance takes priority over a less specific one. Following this, an intent guidance will be overruled by CLI.  (how the various options in my "prio 2" are sorted is outside scope for this discussion, and I guess someone has worked this out already?) 

For you Benoit, this leads to two questions: 
1. does the above explanation make sense, or am I missing your point? 
2. if it does, should this explanation in some form go into the definitions draft? 

Regarding:
--
3.7 Modularity
Section 3 intro says:

--

I wonder whether we should just delete that section? You are right, this is not specific to AN. 

The other comments are clear, and I'll take care of them. 

Michael

> -----Original Message-----
> From: nmrg [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: 21 July 2014 18:04
> To: Benoit Claise (bclaise)
> Cc: [email-masked]
> Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01
> feedback
> 
> Thanks Benoit. Michael has the editing pen so I will only comment on one
> point right now:
> 
> > I guess you want to rephrase that the intent is a general policy above
> > configuration or information for a specific node,
> 
> I think it can also be for a specific role, where a bunch of nodes can all fill
> that role (e.g. an intent that applies to all CE routers, or all AFTRs,...).
> 
> Regards
>    Brian
> 
> _______________________________________________
> nmrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nmrg

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 22 Jul 2014 01:03:00 +0200

Dear Michael, all,

I generally agree with your explanation (difference and co-existence 
between intent and configuration). This makes sense to me.

However, I have a question/comment on: "a more specific guidance takes 
priority over a less specific one", why / how have we ended up that CLI 
shall/should take priority over an intent?
I would say that in the general case, again this makes sense and is 
perfectly applciable. However, taking the analogy of aviation, there are 
rules/principles(/laws), when a plane is operating in auto-pilot, that 
forbid a human pilot to take an action/command that will "harm" the 
plane/flight (i.e. the human could make mistakes, not be sane...).
So why should a CLI overrides an intent? or stated differently, we 
should insert some principles/laws to drive the priority among the 
different configuration/intent/other interactions. (see also reference 
text below for more detail)

What do you think?

Best regards, Laurent.

/--- (extracted from a technical report of EU FP7 UniverS//e//lf 
project) ---//
//[...]/

The most important thing is to demonstrate the operator that an 
autonomic management does not come along with incalculable risks such as 
network outages and the like. Intuitively, human beings always have a 
tendency to distrust features that are not under their full control. 
However, in other domains, such as in aviation, automated systems have 
already taken a substantial part of the control over a system with much 
higher security requirements (i.e. the safety of aircraft passengers) 
than those in the telecom area. Even beyond, an article of the IEEE 
Spectrum Magazine [39]highlight the remaining challenges and obstacles 
but also the close opportunity that unmanned or pilotless airplane 
become a daily reality. A good example is the autopilot of a commercial 
aircraft that relieves the actual pilot from routine actions. But not 
only that, the autopilot is also able to control complex manoeuvres and 
supports the safe landing of the aircraft. With this in mind it should 
not be too hard to assure a network operator that a trustworthy 
deployment of self-* features is possible.

In the following we will transfer some key principles from aviation to 
the self-* domain. The basis for this is a flight crew training manual 
for the Airbus 330/340[1] <#_ftn1>. We will cite relevant sentences / 
paragraphs from this manual in italics and explain how this principle 
can be applied to autonomic management of a telecom network (instead of 
an aircraft). The idea behind this exercise is to apply security 
principles that have already proven to work.

The autopilot is designed to fly the aircraft within the normal flight 
envelope**

The management of the network is autonomic unless there are severe problems

The autopilot automatically disengages if the aircraft flies 
significantly outside the normal flight envelope limits**

The automatic management of the network is automatically disengaged if 
the key performance indicators significantly differ from normal (good) 
values

With one engine inoperative, the AP can be used throughout the entire 
flight envelope without any restriction, including autoland**

There are self-healing features. For instance, if there are outages of 
network equipment, the network management system is able to recover 
without manual intervention

The relationship between sidestick input and the aircraft response is 
called the flight control law. Depending upon the status of the 
fly-by-wire system, three sets of control laws are provided, i.e. Normal 
Law, Alternate Law and Direct Law**

Depending on the status / situation of the network, there are different 
levels of how much control the autonomic management has with respect to 
the human being in charge

Under most circumstances, the aircraft is operated in Normal Law**

Usually the autonomic management has full control

Normal Law provides five different protections [e.g. high angle of 
attack protection or high speed protection].The protections are 
complementary and together work to maintain the aircraft in the safe 
flight envelope**

There is the concept of protection during "normal law" which does not 
let the pilot / human operator make any dangerous moves. For example, 
during take-off of an aircraft, the pilot usually cannot let the tail 
touch the ground -- without protection that would be possible with all 
its dangerous consequences. Likewise, during "normal law" the network 
operator should not be allowed to leave certain parameter limits that 
are known to have negative or nonlinear effects

In some cases of double failure, e.g. double hydraulic failure, the 
integrity and redundancy of the computers and other required systems are 
not sufficient to achieve normal law with its protections. In this case, 
Alternate Law is triggered**

In case of multiple problems that cannot be accommodated automatically, 
the human operator gains more (yet not full) control

If the aircraft is operated outside the normal flight envelope, the 
pilot must take appropriate corrective action to avoid losing control 
and/or to avoid high speed excursions, since the normal law protection 
features may not be available**

In case of "alternate law" there are fewer protections. This allows 
human operators to do moves that would be dangerous in normal 
situations, but necessary in exceptional situations

In most cases of triple failure [...] direct law is triggered. Autopilot 
and auto-trim are not available**

In some pathological cases, the human operator is in full control and no 
autonomic functionality is active. This is clearly the worst case and 
should be considered an extremely rare event

Cautions and warnings**

An interesting aspect of the flight manual is the differentiation 
between "cautions", which are solely prudent forethought to minimize 
risks, and "warnings". Please note that this differentiation would allow 
the human network operator to prioritize information that he/she gets 
from the autonomic system. What looks like a minor detail at first sight 
is in fact a major security feature (as information overflow can cause 
delays or failures on the human reaction side) that deserves attention

Computer replication / backup**

Obviously, a network management system must not be a single point of failure

*Conclusion:*

Concerning trust in autonomics, we can learn and apply a number of 
principles from an autonomic system that is yet more security-critical 
than a telecom network, namely the autopilot of an aircraft:

-The partition of control between autonomic management system and the 
human network operator should be changeable to different discrete 
control levels. A first example of these control levels in the context 
of the UMF and NEM is the change of state of a particular NEM from under 
trial to operational (and vice-versa) depending on its trust index 
estimations (see Section 3, and section 3.4 in particular).

-Depending on the control level, the human network operator should be 
protected from dangerous changes of parameters. In the context of UMF, 
these "boundaries" can be defined and applied via the use of policies 
and policy based management principles.

-The information the human network operator receives from the network 
management system should be on clearly defined hierarchical levels so 
that information can be easily filtered depending on the current needs. 
In the context of the UMF and NEM, this information may take the form of 
a Call for Governance

------------------------------------------------------------------------

[1] <#_ftnref1>A330 & A340 Flight Crew Training Manual, FCTM Presentation

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

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

address: Route de Villejust | 91620 NOZAY | France

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Mon, 21 Jul 2014 20:02:20 -0400

Hi Laurent,

> I generally agree with your explanation (difference and co-existence between intent and configuration). This makes sense to me.
> 
> However, I have a question/comment on: "a more specific guidance takes priority over a less specific one", why / how have we ended up that CLI shall/should take priority over an intent?
> I would say that in the general case, again this makes sense and is perfectly applciable. However, taking the analogy of aviation, there are rules/principles(/laws), when a plane is operating in auto-pilot, that forbid a human pilot to take an action/command that will "harm" the plane/flight (i.e. the human could make mistakes, not be sane...).

Interesting. Say an autonomic function was measuring two links under LACP or ECMP, and could determine that manually 
disabling one of the links would cause utilisation of the other link to exceed or come very close to 100%, are you 
saying the administrator should be prevented from disabling that link?

> So why should a CLI overrides an intent? or stated differently, we should insert some principles/laws to drive the priority among the different configuration/intent/other interactions. (see also reference text below for more detail)

I think possibly the difference is that SNMP/CLI etc.. are possibly intended as temporary overrides for maintenance 
purposes? and intent represents the default state of the autonomic function, bent to the operator's idea of what the
network should look like? Also seeking clarification from Michael.

> The autopilot is designed to fly the aircraft within the normal flight envelope
> 

> The autopilot automatically disengages if the aircraft flies significantly outside the normal flight envelope limits
> 
> The automatic management of the network is automatically disengaged if the key performance indicators significantly differ from normal (good) values

The cases where this would be useful are likely to be small.

From a security standpoint, being able to force the network to apply different controls by triggering overload
or manipulating performance metrics is undesirable.

Disabling ECMP like functions, loop prevention, route distribution, link aggregation, multicast propagation/group
control etc... Would also likely have a negative impact on network performance.

There's more use in determining why the gauge is now showing an abnormal value than disabling autonomic control and 
hoping the network behaves in a sane way.

-Arran

---

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Jul 2014 20:52:53 -0400

Hi Michael,
> 1. Intent does NOT contain configuration. (note: "contain")
Ok.
> 1. does the above explanation make sense,
Ok
> or am I missing your point?
No clear view on that one.
> Regarding:
Happy to delete.

Regards, Benoit
> .

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 22 Jul 2014 05:45:01 +0200

Arran,

Please see in-line, marked [LC].

Kind regards, Laurent.

> saying the administrator should be prevented from disabling that link?

[LC]: yes, or at least the administrator should be warned that such 
change would impact/has impacted the performance negatively.

> network should look like? Also seeking clarification from Michael.

[LC]: we have tried to develop this aspect with Michael f2f after I 
raised the point. the "temporary overrides" / "default state" you 
mention are key. if the network is performing as planned/expected, then 
there should not be reasons to override the intent except for 
temporary/minority fixes/tuning.
[LC]: the manual mode shall(/should?) always be possible and take 
priority over the automatic/autonomic one, however the system may raise 
warnings if the manual changes impact negatively (or in too large 
proportion) the network behaviors (wrt. the intent).
[LC]: one example (from Michael): imagine you secure an entire area with 
encryption (intent), except one link to a traffic analyzer you wish to 
keep w/o encryption. this manual override is ok. but if you end up 
in-securing 20-30% of the links by manual changes, then the system 
should be able to warn the administrator that the state of the network 
is not anymore "close"/in accordance with the (initial) intent; even if 
there might have been good reasons to do these manual changes.

> or manipulating performance metrics is undesirable.

[LC]: true. however, I think this is equally valid for an autonomic 
network entity or a human operator... right?
[LC]: the key point resides in how to make/ensure the system is/remains 
robust, stable, predictable when confronted to adverse/tough conditions 
(could be attacks, overloads, loss of/no access to information/sensing...).

> hoping the network behaves in a sane way.

[LC]: my understanding is the disabling of the automatic mode is 
triggered under the assumption that, in the particular situation faced 
by the system, a more capable entity (e.g. the human 
pilot/administrator) would take over and avoid the crash.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jul 2014 23:29:36 +1200

Excuse front posting, but I would like to note that operators need
(and will I think insist on) an emergency override for a situation
where autonomic mechanisms go wrong and make mistakes. So in that
sense CLI will *always* have the ultimate power, and for any autonomic
node the most powerful CLI command might be 'disable autonomic'.

But even if CLI overrides everything else, it should certainly
be treated as the last resort.

Regards
   Brian

On 22/07/2014 15:45, Laurent Ciavaglia wrote:
>>> However, I have a question/comment on: "a more specific guidance
>>> takes priority over a less specific one", why / how have we ended up
>>> that CLI shall/should take priority over an intent?
>>> perfectly applciable. However, taking the analogy of aviation, there
>>> are rules/principles(/laws), when a plane is operating in auto-pilot,
>>> that forbid a human pilot to take an action/command that will "harm"
>>> the plane/flight (i.e. the human could make mistakes, not be sane...).
>> Interesting. Say an autonomic function was measuring two links under
>> LACP or ECMP, and could determine that manually
>> disabling one of the links would cause utilisation of the other link
>> to exceed or come very close to 100%, are you
>>> different configuration/intent/other interactions. (see also
>>> reference text below for more detail)
>> I think possibly the difference is that SNMP/CLI etc.. are possibly
>> intended as temporary overrides for maintenance
>> purposes? and intent represents the default state of the autonomic
>> function, bent to the operator's idea of what the
>>> significantly outside the normal flight envelope limits
>>>
>>> The automatic management of the network is automatically disengaged
>>> if the key performance indicators significantly differ from normal
>>> (good) values
>>  From a security standpoint, being able to force the network to apply
>> different controls by triggering overload
>> Disabling ECMP like functions, loop prevention, route distribution,
>> link aggregation, multicast propagation/group
>> There's more use in determining why the gauge is now showing an
>> abnormal value than disabling autonomic control and

---

From: Olivier Festor <[email-masked]>
Date: Wed, 23 Jul 2014 17:19:31 +0200

Dear benoît and colleagues,

I would like to comment on your point #1: Logical OR between the functions.

If one considers Autonomic as defined in the original paper, and how it is experienced on various use cases, the functions must be all there to have a real « autonomic » system. 
I recommend the reading of work we did a couple of years ago on network renumbering with R. Droms and how the different self-* features when combined, lead to a real autonomic system.
The paper which was published in IEEE Communications Magazine can be found at in a draft version: hal.inria.fr/inria-00531215/PDF/

Best Regards,

/Olivier Festor

Le 21 juil. 2014 à 20:34, Benoit Claise <[email-masked]> a écrit :

>    enterprise network.  It does not contain configuration or information
>    for a specific node.  It may contain information pertaining to nodes
>    with a specific role.
>

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 23 Jul 2014 16:18:01 +0000

Hi, Olivier,

In the definition draft, we have defined the terms of autonomic network (which probably should be changed into the "partial autonomic network") and the "full autonomic network". What you mentioned is refering to "full autonomic network".

Sheng
________________________________________
From: nmrg [[email-masked]] on behalf of Olivier Festor [[email-masked]]
Sent: 23 July 2014 23:19
To: [email-masked]
Cc: <[email-masked]> Festor
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback

Best Regards,

/Olivier Festor

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 23 Jul 2014 16:37:59 +0000

Agree with Sheng, this affects only the definition of "fully autonomic node" (the network definition is based on that one). 

Unless you feel strongly, Olivier, if we could leave it as is, because 

1) the list of self-* properties is actually not limited, and other than the usual self-CHOP do pop up. And
2) we might get into silly discussions where some node doesn't implement self-optimisation, and you could then argue that strictly speaking it's not autonomic. I don't think this type of discussion would help us to progress.

Thoughts? 
Michael

> From: nmrg [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: 23 July 2014 12:18
> To: Olivier Festor; [email-masked]
> In the definition draft, we have defined the terms of autonomic network
> (which probably should be changed into the "partial autonomic network")
> and the "full autonomic network". What you mentioned is refering to "full
> autonomic network".
> 
> Sheng
> If one considers Autonomic as defined in the original paper, and how it is
> experienced on various use cases, the functions must be all there to have a
> real « autonomic » system.
> I recommend the reading of work we did a couple of years ago on network
> renumbering with R. Droms and how the different self-* features when
> combined, lead to a real autonomic system.
> The paper which was published in IEEE Communications Magazine can be
> found at in a draft version: hal.inria.fr/inria-00531215/PDF/
> 
> 
> Best Regards,
> 
> /Olivier Festor
> 
> 
> 
> configuration or information for a specific node, dealing with the intent you
> want to have from the network.
> >
> > draft-irtf-nmrg-autonomic-network-definitions would benefit from this
> > definition in my opinion, and a few words on the difference between
> > autonomic and automatic
> >
> > -
> > I see this more like a good deployment practice, i.e. if you think
> > about an autonomic protocol, please think of deployment, i.e.
> > modularity
> >
> > Regards, Benoit
> >

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 23 Jul 2014 17:56:14 +0000

Actually, I agree with Olivier here.  IMHO it really should be "and", not "or".  If it's "or", the concept of autonomic becomes almost meaningless, as the label can then be applied widely to anything displaying some self-* property.  

The question is which boundaries you draw around a component/system/network that you are branding as autonomic.  This also gets to the other aspect of "partial" vs "fully" autonomic raised by Sheng, which is a distinction which I do not find helpful - either an entity is autonomic, or it is not.  To me, an entity that is "partially" autonomic is not autonomic at all, however, it is an indication that it could be decomposed into several components or functions, some of which being autonomic while others are not.  The "partially autonomic" entity is thus an entity which contains some aspects/components which are autonomic and some which are not.  

--- Alex

-----Original Message-----
From: nmrg [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Wednesday, July 23, 2014 9:38 AM
To: Sheng Jiang; Olivier Festor; [email-masked]
Cc: <[email-masked]> Festor
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback

Thoughts? 
Michael

> In the definition draft, we have defined the terms of autonomic 
> network (which probably should be changed into the "partial autonomic 
> network") and the "full autonomic network". What you mentioned is 
> refering to "full autonomic network".
> 
> Sheng
> If one considers Autonomic as defined in the original paper, and how 
> it is experienced on various use cases, the functions must be all 
> there to have a real « autonomic » system.
> I recommend the reading of work we did a couple of years ago on 
> network renumbering with R. Droms and how the different self-* 
> features when combined, lead to a real autonomic system.
> > Well in the end, configuration or information for a specific node 
> > will be
> involved.
> configuration or information for a specific node, dealing with the 
> intent you want to have from the network.
> >
> > Coincidently, this was just discussed at the time of typing these 
> > lines, by
> Brian, presenting in NMRG.
> > draft-irtf-nmrg-autonomic-network-definitions would benefit from 
> > this definition in my opinion, and a few words on the difference 
> > between autonomic and automatic
> >
> > -
> > Northbound interface. These days, with the SDN/controller story, 
> > this is a
> confusing term.
> > Is this an Autonomic Networking design goal to be modular? Not 
> > really I see this more like a good deployment practice, i.e. if you 
> > think about an autonomic protocol, please think of deployment, i.e.
> > modularity
> >
> > Regards, Benoit
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2014 08:08:36 +1200

> Actually, I agree with Olivier here.  IMHO it really should be "and", not "or".  If it's "or", the concept of autonomic becomes almost meaningless, as the label can then be applied widely to anythi…

Alex, that may be true in the academic view, but the pragmatic
view that we heard in the BOF today is that operators prefer a
small amount of AN now rather than aiming at 100% AN at some
undefined future date. To me that argues strongly for the "or"
approach. I heard it said that "if there's no control loop,
it's not properly autonomic." I don't get that. I would rather say
"if there's no human brain input, it's autonomic for all practical
purposes." (That's deliberately provocative, I know :-)

In fact perhaps the document should make an explicit statement
that we are talking about a practical, partial form of AN
and not complete AN in any formal sense.

That said, I do agree that we should include a citation or two
of review articles on AN or Autonomic Computing - perhaps to
point out that we are *not* claiming to boil that ocean.

    Brian

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 24 Jul 2014 00:05:04 +0000

Hello Brian,

I completely agree that a practical approach will not go from non-autonomic to all-autonomic in a single step, and we have to be pragmatic.  However, IMHO this does not mean that we should call things autonomic when really they are not.  The road forward will involve an increasing number of functions and components become autonomic, so that over time increasingly greater subsystems will.  This is similar to other areas, e.g. cars.  There are increasing numbers of autonomic subsystems, from automatic transmissions to smart cruise control, all of which are pragmatic steps towards more autonomic cars; however, the autonomic car as a whole  is still distinct from "regular" cars that contain such subsystems.  (You might argue that one could introduce the notion of an "autonomics degree", indicating the degree to which a system is autonomic, perhaps per the ratio of autonomic vs nonautonomic functions or components, but I am not sure how usefule that will be.)   

My concern is that "partial autonomics" muddies the concept of autonomics; leading to the term becoming overused and meaningless.  Of course, practical strategies will not boil the ocean, but address separate aspects one at a time.  So, IMHO the "small amount of AN now" simply calls for identifying and isolating specific subcomponents or network functions that can be made autonomic, while addressing others later.  The fact that the road to greater autonomy does not require boiling the ocean (I think we're all in agreement) is something that we should then clarify more strongly.  

--- Alex

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, July 23, 2014 1:09 PM
To: Alexander Clemm (alex)
Cc: Michael Behringer (mbehring); Sheng Jiang; Olivier Festor; [email-masked]; <[email-masked]> Festor
Subject: Re: [nmrg] draft-irtf-nmrg-autonomic-network-definitions-01 feedback

> Actually, I agree with Olivier here.  IMHO it really should be "and", not "or".  If it's "or", the concept of autonomic becomes almost meaningless, as the label can then be applied widely to anythi…

Alex, that may be true in the academic view, but the pragmatic view that we heard in the BOF today is that operators prefer a small amount of AN now rather than aiming at 100% AN at some undefined future date. To me that argues strongly for the "or"
approach. I heard it said that "if there's no control loop, it's not properly autonomic." I don't get that. I would rather say "if there's no human brain input, it's autonomic for all practical purposes." (That's deliberately provocative, I know :-)

In fact perhaps the document should make an explicit statement that we are talking about a practical, partial form of AN and not complete AN in any formal sense.

That said, I do agree that we should include a citation or two of review articles on AN or Autonomic Computing - perhaps to point out that we are *not* claiming to boil that ocean.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2014 00:16:26 +1200

I think we agree, so I hope Michael can edit the text accordingly.

Regards
   Brian