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

[Laurent Ciavaglia <[e-mail]>]

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
>