[nmrg] Review of draft-irtf-nmrg-autonomic-network-definitions-04

[Kostas Pentikousis <[e-mail]>]

Dear authors, all,

I reviewed draft-irtf-nmrg-autonomic-network-definitions-04. Overall, the draft is easy-to-read, but it feels more like "original" work than the RG documents I'm familiar with. As I mentioned in the Toronto meeting and on the list, the draft lacks the appropriate list of "citations and references to relevant research publications". I personally do not consider sufficient the three references mentioned in passing ("There is a
large literature, including several useful overview papers (e.g., [Samaan], [Movahedi], and [Dobson])"). Further, several assumptions remain unstated (could be fixed by adding a new section) and certain inconsistencies persist in this revision (see below).

In summary: If this draft is to become the reference RFC on Autonomic Networking, more work is needed in the RG.


General comments:
-----------------

The draft includes some normative-resembling language, which may be misleading to uninitiated readers:
 
* "For this reason we suggest here to NOT generally disable autonomic functions if they encounter unexpected conditions ..."

* "Autonomic functions must be able to adapt their behavior ... "

* "Intent must not be used to convey low-level commands or concepts ..."

* "an autonomic function must understand the full life cycle of the device it runs on ...

* "Warnings however should be issued if node specific overrides may conflict with autonomic behaviour."

* "Information about the network should be collected and aggregated by the network itself, presented in consolidated fashion to the administrator."

* "Autonomic network events should concern the autonomic network as a whole, not individual systems in isolation. ..." (and the rest of the paragraph)

* "apply specific algorithms to determine what should be reported."

* "All the components around the "autonomic service agents" should be common components, such that the autonomic service agents do not have to replicate common tasks individually." Doesn't this read like an implementation suggestion?

* "autonomic functions in the context of this framework should therefore operate at the IP layer."

I guess it would be better to rephrase the above sentences to avoid future misunderstandings.

Also, have we reached consensus in NMRG that "The goal of the work on autonomic networking in the IETF is therefore not just to create autonomic functions, but to define a common infrastructure that autonomic functions can use." And, why is an NMRG draft indicating what the IETF goal is?


Section-specific comments:
--------------------------

- Abstract: The sentence "This document applies the concepts of autonomic systems to a network, ..." does not reflect the draft contents. There is very little that is being _applied_ to, as no references to earlier work are given for the concepts defined in the draft (as per Sec. 2). As mentioned above, the text reads more like original work undertaken for this draft.


- Section 1: The draft makes an implicit assumption which should become explicit. Namely, the draft adopts a node-centric approach ("Autonomic Networking aims at putting the intelligence of today's operations back into algorithms at the node level ...". This assumption should be stated explicitly. Mind you, not everyone in the research community may agree that AN should be defined at the node level, instead of at the system level. I'd would be interested in other folks' opinion/pointers in earlier literature on this. Note that "node" is defined in Sec. 2 by what it does (i.e. it "employs exclusively autonomic functions").

The following sentence implies a certain dichotomy: "a mixed approach, where some functions are autonomic and others are centrally mangaged", which may be true if you have the node-centric assumption in mind. A RoutFlow-like network runs OSPF "centrally" but I would argue that it retains the autonomic properties of the protocol at the system level ("Autonomic Domain" in terms of this draft). This dichotomy appears later in the text as well, e.g. "which functions should be centralised or follow an autonomic approach."

Regarding related work, the text indicates that in "the present document we focus on concepts and definitions that seem sufficiently mature to become the basis for interoperable specifications in the near future." Since no references are given, _who_ has determined that the "concepts and definitions" in this draft are "mature". The authors? NMRG? ... Was there a workshop to tackle this point? Perhaps adding a reference would resolve this in a speedy manner. Ditto for the ending sentence of this section: "This document provides the definitions and design goals for Autonomic Networking." In which context?

Another assumption is that the draft aims for a migration environment ("such specifications will need to co-exist with traditional methods of network configuration and management, rather than realising an exclusively autonomic system with all the properties that it would require."). A distinct section entitled "Assumptions" would serve the casual reader well.


- Section 2: Since no references are provided, some text should be added to explicitly state that these definitions are specified by _this_ draft. Alternatively, of course, refs could be added.

It's not crystal clear what is the relationship between an Autonomic Network and a Autonomic Domain. Based on their current definitions, it appears to be the lack of (the same) intent. Please clarify.

The concept of an operating region for an autonomic node/network/domain is missing in the definitions.


- Section 3: Do we have consensus in NMRG that "The original design goals of autonomic systems as described in [Kephart] also apply to Autonomic Networks" (as-is)? I heard different opinions, but I'm curious what others in the RG think.


In Sec. 3.1:

"Functions do not require to be configured," -- by whom? Do you mean a network operator?

"secure themselves against potential attacks." -- shouldn't this be a bit scoped?

Proposed text:

OLD: "determine ways to optimise their behaviour."
NEW: "determine ways to optimise their behavior against a set of well-defined goals".


In Sec. 3.2:

"Conflict resolution between autonomic default behaviour and intent on one side ..." -- This may be confusing. Why doesn't _autonomic default behavior_ include intent? Please clarify.

Given the implicit node-centric approach adopted in this draft (see above) the following sentence is a bit contradictory, and I think inconsistent with the rest of the text: "Generally, autonomic mechanisms define a network wide behaviour, whereas the alternative methods are typically on a node by node basis." 

Then, "Node based management concepts take a higher priority over autonomic methods." But don't we refer to Autonomic Nodes?

As the draft indicates, network operations tend to be manual/configuration-oriented as opposed to adopting well-defined algorithms for steering operation. Is operating an atomic plant less critical or less complex than operating a network? Some retrospective/discussion on earlier efforts in the autonomic networking practice would be valuable here.


In sec. 3.4: does the following maxim "If a problem can be solved in a distributed manner, it should not be centralised." belong to this draft?


In Sec. 3.6: the goal "optimize my network for energy efficiency" is not well-defined. Abstraction may it be, but it has to be measurable somehow. See proposed text above.

Also, it's not clear how this sentence "The administrator should not even be exposed to the version of the IP protocol running in the network." is related with "energy optimization".


In Sec. 3.9: Please add a couple of references/examples to better document the sentence "For example, layer 2 switching today is already relatively autonomic in many environments; routing functions can be autonomic." 


- Section 4: In general this section needs further editing. First, the opening sentence ("This section identifies various items that are explicitly not design goals for autonomic networks, ...") is quite vague. For whom is this _not_ a design goal? NMRG? IRTF? IETF? Researchers? Practitioners? Engineers? Network operators? Protocol designers/implementers? In general, it is not clear whose anxieties does this section address by explicitly declaring non-goals. Second, are the following sentences really needed?

* "(They should become more like doctors than hospital orderlies.)"
* "Truck rolls will not be eliminated when faulty equipment needs to be replaced."
* "Senior management might fear loss of control of an autonomic network."

In general, is Section 4 needed in the first place? Isn't it better to define the goals clearly so that listing an arbitrary set of non-goals becomes redundant?


- Section 5: wrt Fig. 1, it's not clear why the "Autonomic Control Plane" is outside the "Standard Operating System Functions". Such an illustration somehow indicates that ACP is an add-on, as opposed to being part and parcel of an autonomic node.


Editorial/Nits:
-----

In the beginning of Sec. 2, a sentence such as "This document uses the following terms:" would be nice to add.

s/mangaged./managed.

s/self- managing,/self-managing,

s/take place."/take place.

s/outside scope/outside the scope

respected‎ ???

s/(Section 3.5,/ (Section 3.5)


Finally, there's no text adhering to RFC 5743, Sec. 2.1. It would be good to add in the next draft revision.


Best regards,

Kostas