Subject: [Anima] Next version of draft-irtf-nmrg-autonomic-network-definitions

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 29 Jul 2014 14:29:53 +0000

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

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 29 Jul 2014 17:49:43 +0200

Dear Michael, all,

Please find below some remarks/question on point 6:

-To what extent is/needs (or not) the control plane to be autonomic?
For me the "plane" we are talking below is the set of common control 
protocols/processes that autonomic functions must/should? support to 
interwork properly.
As a whole, and in parts, this set is not necessarily autonomic. so, it 
might be worth adding a sentence like "the autonomic control plane is 
not necessarily autonomic itself".

-It is not clear/straightforward what "in the global context of each 
device" means. If we want to say that the control protocols can run 
in-band/out-band, let's just say that.

-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.
(at the end of the day, the model is just (another) arbitrary grouping).

HTH, best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 NOZAY | France

  * English - detected
  * English
  * French

  * English
  * French

<javascript:void(0);>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2014 08:21:57 +1200

Just commenting on one point from Laurent. I'll stick to cross-posting for
this point. In due course I think we should avoid it, but OK for now.

> -It is not clear/straightforward what "in the global context of each device" means. If we want to say that the control protocols can run in-band/out-band, let's just say that. 

Yes, I think we have to be more explicit. One approach is to have
an explicit autonomic control plane which is an in-band overlay
on the physical network. Another approach is to make this implicit -
just use the existing L2/L3 network but without considering it
to be a control plane at all (that's what most routing protocols
do). A third approach would be a truly separate control plane
such as a dedicated L2VPN. The point is that they could all support
autonomic behaviour; it's a design choice.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2014 12:58:18 +1200

On 30/07/2014 03:49, Laurent Ciavaglia wrote:
...
> autonomic networking principles/mechanisms to the operations on internet

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

    Brian
>> 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:
>>
>> 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.
>> 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."
>>
>> 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.
>> 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).
>>
>>        <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.
>>
>> 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
>> 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:

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 30 Jul 2014 08:45:37 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 29 July 2014 22:22
> To: Laurent Ciavaglia
> Cc: Michael Behringer (mbehring); [email-masked]; [email-masked]; draft-
> [email-masked]
> Subject: Control plane [was Next version of draft-irtf-nmrg-autonomic-
> network-definitions]
> 
> > -It is not clear/straightforward what "in the global context of each device"
> means. If we want to say that the control protocols can run in-band/out-
> band, let's just say that.
> 
> Yes, I think we have to be more explicit. One approach is to have an explicit
> autonomic control plane which is an in-band overlay on the physical
> network. Another approach is to make this implicit - just use the existing
> L2/L3 network but without considering it to be a control plane at all (that's
> what most routing protocols do). A third approach would be a truly separate
> control plane such as a dedicated L2VPN. The point is that they could all
> support autonomic behaviour; it's a design choice.

Suggestions for better wording is welcome. For a L3 device it's relatively clear: It's either the global routing table or a virtual routing table, such as a VRF, or a virtual router. Problem is that the concept of the Autonomic Control Plane as described in draft-behringer-autonomic-control-plane applies also to non-L3 devices, for example to switches or NMS systems, or .... 

So, what is the generic term for "global routing table" and "virtual routing table" which is valid also for non-L3 devices? 

So, the full range of options is: 
- inband, as we run for example IGPs today
- Over a configured VPN ("management VPN")
- Over the self-managing Autonomic Control Plane (See above mentioned draft)
- Over a "real" out of band network. 

Should we list those, and explain what they do in a bit more detail? Maybe that would make things clearer... 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Jul 2014 08:07:44 +1200

On 30/07/2014 20:45, Michael Behringer (mbehring) wrote:
> Should we list those, 

IMHO, we should definitely list them.

> and explain what they do in a bit more detail? Maybe that would make things clearer... 

I'm not sure that is needed in the definitions draft; it might get a bit
complicated. But I certainly have no objection to one or two sentences
for each one. We should probably avoid pros and cons, since that is
not the job of a definition.

   Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 30 Jul 2014 19:58:53 -0300

> in the next few weeks, and so that we can rely on it for IETF work).

+1

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 31 Jul 2014 06:00:29 +0000

>From: Anima [mailto:[email-masked]] On Behalf Of Brian E
>Carpenter
>

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

Best regards,

Sheng

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 31 Jul 2014 09:35:14 +0200

Hi,

Isn't there some ITU-T Rec defining such options? i.e. we could 
cite/re-use these agreed definitions. I will check... but if someone has 
some pointers, feel free to share them.

Best regards, Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 31 Jul 2014 10:02:57 +0200

Hi,

please see below for additional comments.

Best regards, Laurent.

On 31/07/2014 08:00, Sheng Jiang wrote:
> 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.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

From: Tom Taylor <[email-masked]>
Date: Thu, 31 Jul 2014 10:00:31 -0400

...
> performance... by using autonomic networking.
...
I was teelling Brian that one of the things I used to wwork on in BNR 
(Bell-Northern Research) several decades ago was operator services 
planning. There, a few seconds of work time per call was worth a lot due 
to volume. The same ideas for reducing work time were always around, but 
only became cost-effective as teechnology evolved to support them.

In a similar way, Anima might identify the promising ideas and what has 
to happen before they can be supported at the business level. Either 
Anima or other groups can then periodically review whether a particular 
solution approach has matured to the point of development and deployment.

Tom Taylor