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

[Brian E Carpenter <[e-mail]>]

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:
> Arran,
> 
> Please see in-line, marked [LC].
> 
> Kind regards, Laurent.
> 
> On 22/07/2014 02:02, Arran Cudbard-Bell wrote:
>> 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?
> 
> [LC]: yes, or at least the administrator should be warned that such
> change would impact/has impacted the performance negatively.
> 
>>
>>> 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.
> 
> [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.
> 
>>
>>> 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
>> 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.
> 
> [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...).
> 
>> 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.
> 
> [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.
> 
>>
>> -Arran
>>
> 
> 
>