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

[Laurent Ciavaglia <[e-mail]>]

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



On 22/07/2014 00:45, Michael Behringer (mbehring) wrote:
> 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:
>
>     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
> --
>
> 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:[e-mail]] On Behalf Of Brian E Carpenter
>> Sent: 21 July 2014 18:04
>> To: Benoit Claise (bclaise)
>> Cc: [e-mail]
>> 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
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/nmrg
> _______________________________________________
> nmrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nmrg
>
>

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: [phone]

email: [e-mail] 
<mailto:[e-mail]>

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

address: Route de Villejust | 91620 NOZAY | France