Re: [nmrg] [Anima] Architecture [was Next version of draft-irtf-nmrg-autonomic-network-definitions]

[Jéferson Campos Nobre <[e-mail]>]

On Tue, Jul 29, 2014 at 9:58 PM, Brian E Carpenter
<[e-mail]> wrote:
> On 30/07/2014 03:49, Laurent Ciavaglia wrote:
> ...
>> -If we agree to keep working on the architectural aspects in NMRG, then,
>> we have to strengthen the NMRG definitions/goals I-D with more
>> architectural aspects or create a dedicated document. Wrt. the
>> state-of-the-art, the content and guidelines of the NMRG document are
>> not enough.
>> As for the architectural model, this is a Pandora box, there has been
>> plenty of models all more or less equals (see the reference you have
>> added for a start). The important thing to agree on are the
>> definitions/terminology, design goals/principles, requirements to design
>> the right protocols(in the IETF WGs). The architectural I-D should allow
>> us to better understand what are the implications/impact of introducing
>> autonomic networking principles/mechanisms to the operations on internet
>> protocols.
>
> Precisely because it's Pandora's box, I am strongly in favour of
> making such a document a separate NMRG draft, and keeping the
> definitions document roughly as it is (so that we can get it finished
> in the next few weeks, and so that we can rely on it for IETF work).

+1

>     Brian
>> (at the end of the day, the model is just (another) arbitrary grouping).
>>
>> HTH, best regards, Laurent.
>>
>>
>> On 29/07/2014 16:29, Michael Behringer (mbehring) wrote:
>>> [excuse cross-posting, but I do believe that this is relevant to both
>>> lists]
>>>
>>> Anima, NMRG,
>>>
>>> Before and at the IETF there was a lot of discussion around the
>>> autonomic paradigms discussed in
>>> draft-irtf-nmrg-autonomic-network-definitions. I tried to now
>>> consolidate all input into a new version of the document (link below).
>>> I'm not commenting every single mail, although mostly I replied to
>>> each mail. High level, I tried to capture the discussions in this way:
>>>
>>> 1. Coexistence with config / other management paradigms.
>>> There was a lot of discussion around what takes priority, autonomic
>>> behaviour or config. I believe we have consensus that config always
>>> overrides autonomic behaviour. There was some discussion about
>>> "emergency disable" in case an autonomic function gets into unknown
>>> conditions. The consensus I think is that we do NOT want an automatic
>>> shut-down in such cases, because it adds even more uncertainty to the
>>> network.
>>> This is highly important, so I felt the best way to capture this
>>> discussion was to introduce a new section in the design goals on
>>> co-existence. Section 3.2.
>>> In the definitions, for intent, I now point to this section, because
>>> the question arose also at this point.
>>>
>>> The document -01 states "Fully Autonomic Node: A node which employs
>>> exclusively autonomic functions. It requires no configuration." I
>>> expanded that now with "It requires (!) no configuration. Note that
>>> configuration can be used to override an autonomic function. See <xref
>>> target="coexistence"/> for more details."
>>>
>>> 2. What is a "fully autonomic network".
>>> Some folks commented that autonomic = self-management = self-CHOP
>>> (configuring, healing, optimising, protecting), and that a truly
>>> autonomic function MUST contain all four elements.
>>> I suggest that we don't become too rigid in our argumentation, but
>>> leave a bit of flexibility in the definitions. My arguments are:
>>> A) there is no generally accepted, precise definition of which
>>> self-properties must be present in a system so that it can be called
>>> "autonomic". The Kephart paper itself is not clear for starters, while
>>> it focuses MAINLY on the self-CHOP, it also uses terms
>>> "self-maintaining" and "self-governing".
>>> The paper cited by Olivier
>>> (http://hal.inria.fr/docs/00/53/12/15/PDF/renumbering_cameraReadyv2.pdf)
>>> leaves out self-healing, but introduces self-monitoring.
>>> Other terms, such as self-discovering, self-learning, etc can be found
>>> all over the literature.
>>> Therefore: In the absence of a clear reference I do NOT think it makes
>>> sense to be too academic on MUST contain self-features.
>>> B) I can see implementations of autonomic that do not implement all
>>> self-* properties. For example, in a simple network self-healing may
>>> just not be relevant. (And indeed, the paper mentioned by Olivier
>>> doesn't contain it anyhow). Do we really NOT want to call this
>>> autonomic? The term "more religious than the pope" comes to mind ;-)
>>>
>>> I suggest to actually not add too much wording around it in order to
>>> not make it even more confusing. Instead, I will remove the "and" in
>>> the definition, so that it reads " Autonomic: Self-managing
>>> (self-configuring, self-protecting, self-healing, self-optimizing);
>>> however, allowing high-level guidance by a central entity, through
>>> intent."  For practical purposes this should be ok. Can everyone live
>>> with this? If not, can you propose concrete text / changes?
>>>
>>> 3. Changed section title: Simplification of Autonomic Node Northbound
>>> Interfaces (changed from "simplification of the northbound
>>> interfaces") (suggestion of Benoit).
>>>
>>> 4. difference between automatic and autonomic (request by Benoit): I
>>> added some text in the introduction:
>>>        <t>There is an important difference between "automatic" and
>>> "autonomic". "Automatic" refers to a pre-defined, linear process, such
>>> as a script. "Autonomic" is used in the context of self-management. It
>>> includes feedback loops between elements as well as northbound. </t>
>>> Comments welcome.
>>>
>>> 5. References. Added two references, and Brian suggested some text
>>> around this for the intro.
>>>
>>> 6. A clarification that the Autonomic Control Plane can be implemented
>>> in the global context, or in a separate context (section 7)
>>>
>>> I believe this should account for all the comments received to date on
>>> this draft. If I missed something, please respond!
>>>
>>> Michael
>>>
>>>
>>> ----
>>>
>>> A new version of I-D,
>>> draft-irtf-nmrg-autonomic-network-definitions-02.txt
>>> has been successfully submitted by Michael Behringer and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-irtf-nmrg-autonomic-network-definitions
>>> Revision:    02
>>> Title:        Autonomic Networking - Definitions and Design Goals
>>> Document date:    2014-07-28
>>> Group:        nmrg
>>> Pages:        15
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-irtf-nmrg-autonomic-network-definitions-02.txt
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitions/
>>>
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-02
>>>
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-irtf-nmrg-autonomic-network-definitions-02
>>>
>>>
>>> Abstract:
>>>     Autonomic systems were first described in 2001.  The fundamental goal
>>>     is self-management, including self-configuration, self-optimization,
>>>     self-healing and self-protection.
>>>
>>>     This document applies the concepts of autonomic systems to a network,
>>>     and describes the definitions and design goals of Autonomic
>>>     Networking.  The high-level goal for an autonomic function is to have
>>>     minimal dependencies on human administrators or centralized
>>>     management systems.  This usually implies distribution across network
>>>     elements.
>>>
>>>
>>
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima