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

[Arran Cudbard-Bell <[e-mail]>]

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 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.

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