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

[Laurent Ciavaglia <[e-mail]>]

Hi,

please see below for additional comments.

Best regards, Laurent.

On 31/07/2014 08:00, Sheng Jiang wrote:
>> -----Original Message-----
>> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
>> Carpenter
>>
>>> 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).
> Fully agree. It would NOT be easy to reach consensus on "the" architectural model. There is a good chance that we may struggle and spend too much time on architecture and requirements.

Agreed on the difficulty to reach consensus on the model (from several 
past experiences in SDOs and projects), I think it is not even advisable 
to seek such consensus on the model itself (as I said "at the end of the 
day, the model is just (another) arbitrary grouping").

What would be more useful in my opinion, is to study how the autonomic 
networking principles adapt/apply to new/emerging and combined 
environments such as IoT, NFV, SDN... and thus to document the 
design/architectural/operational implications, to provide 
guidelines/recommendations to enhance IETF protocols with autonomic 
networking principles, to improve Internet manageability and 
performance... by using autonomic networking.

Another objective/output of such a draft could also be to identify 
research directions and gaps (within autonomic networking concepts and 
techniques, and with internet protocols) in order to steer more 
work/investigation in these gap areas.

Do you see other objectives, agree with these ones?

> That's exactly the message from OPS ADs - we should try to avoid it and focus on solutions, which may be small steps, but real steps moving forward. A separate NMRG draft will isolate the risk within minimum impacts. We should complete the high-level concept works (definition and gap analysis) as soon as possible, then focus on produce code-proven protocols/solutions. Meanwhile, a separate, wider-scope architecture and requirement document in NMRG is also helpful. It could lead us on the exploring the potential next steps after we make the enabling common infrastructure available.
I also agree with Sheng on the fact that such a document could help 
shape the future of the activity in IRTF/IETF, in coordination with 
ANIMA work.

>
> Best regards,
>
> Sheng
>
>>     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-defi
>> nitions-02.txt
>>>> Status:
>>>>
>> https://datatracker.ietf.org/doc/draft-irtf-nmrg-autonomic-network-definitio
>> ns/
>>>> 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-definiti
>> ons-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
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>
>

-- 

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