Subject: [Anima] review of draft-irtf-nmrg-autonomic-network-definitions-03

From: Rene Struik <[email-masked]>
Date: Tue, 16 Sep 2014 16:46:52 -0400

Dear colleagues:

Please find below my initial comments on 
draft-irtf-nmrg-autonomic-network-definitions-03.

1. Summary:

The draft provides a loose introduction of some autonomic networking 
notions and then lists some design goals and non-goals.

2. General comments:

a) The title of the document is somewhat misleading, since the document 
is mostly about goals and non-goals and less about definitions.
b) The goal of autonomic networking is described {Section 2} in terms of 
reversing the swing of a pendulum that previously swung into the 
direction of replacing localized configuration and network management 
decision criteria by centralized ones (by putting "intelligence" into 
network management tools rather than devices themselves) into the 
counter-swing of putting more intelligence in devices themselves. What 
is missing, though, is a somewhat more balanced treatment of the topic: 
after all, network design exercises have to deal with many trade-offs, 
with optimal choices not a priori cast in stone. As case in point, 
consider sensor networks: here, energy savings and spotty connectivity 
favor localized decisions, whereas configuration may benefit from a more 
holistic view of the network (e.g., to manage time latency and energy 
cost, as with, e.g., 6TiSCH, or to reduce the shear amount of traffic to 
communicate micro-updates on state that may be flushed from a more 
centralized repository in one protocol pass). I would strongly suggest 
giving this entire section more substance by bringing in various 
elements of network design considerations besides configuration (e.g., 
audit/log functionality) and paying tribute to trade-offs in device 
capabilities, energy usage, time latencies, flexibility, security, ease 
of use, and the-like. Now, it reads like a "cutting the non-localized 
cord" ode no matter what. This should also include some discussion on 
whether localized decisions result in anything close to a "global 
optimum", what the effect is if some local decisions are disturbed 
(whether due to malicious act or otherwise), and whether convergence 
actually can take place. {NOTE: I do realize that this is an internet 
draft and not an academic paper, but why not at least mention some of 
this??}
c) I would also describe some other factors that may have contributed 
{Section 2} to complexity and non-flexibility, where lack of "separation 
of concern" (e.g., encoding addresses in a topology-aware fashion -- 
nice for semi-static networks, but a major headache for mobile networks, 
where flexibility comes at a premium) may unfortunately have driven part 
of the design activities in the past for whatever reason and where 
vested economical interests may have favored centralized control points 
(think: service providers, with centralized user authentication 
functionality; and with an interest in raising the entry bar for new 
network entrants, via these same control points).
d) It should be made more clear that autonomic networking has limits, 
since it cannot really deal well with device-specific functions, since 
"intent" treats all devices within a network generically and similarly 
(e.g., in their role as routers or as "members of a domain"). This may 
have repercussions when applying these notions to security architectural 
design that includes applications, since physical devices are often not 
generic, but display tailored functions, without too much redundancy and 
replication.
e) Some of the non-goals seem to be actually goals that one, for some 
reason (politics, unions?) does not want to label as such. As an 
example, the objective clearly is to significantly reduce human 
involvement in network management, for all but specialized functions 
(conflicting with Section 4.1, but implied by the last sentence hereof 
-- "more like doctors than hospital orderlies"), to reduce control by 
management rather than "network management controls" (which are 
completely different things altogether!) (Section 4.3), to sanitize the 
current complexities and thereby strive for elimination of configuration 
tools (Section 4.4) and existing network management systems (Section 
4.5). If the goal of the autonomic networking exercise is *not* to clean 
up the current complexities, do things better, with ultimate goal of 
brushing some of the current procedures/dead wood/ossified methods 
aside, why even start this effort at all? Stating goals as non-goals is 
not credible. More to the point would be that one takes into account 
"managed change", co-existence of new systems with pre-existing ones, 
etc., but that is something that applies to any development. A draft 
with goals should make a convincing case, including convincing no loss 
of manageability and anomaly control, and not pay lip service to all 
those who might be impacted by this (moreover, this is a technical 
document, isn't it?).

3. Specific comments

Section 1:
1) First sentence (p. 2): "control loops" should read "control loop"
2) First sentence (pp. 2-3): remove the word autonomic (twice), which is 
really overused here, without definition yet. Moreover, the definition 
in Section 2 is really strict, so most networks may not be labelled this 
way.
3) Forelast para (p. 3): define "as a well as northbound" (or, better, 
remove this topology-related notions and replace by "and with external 
processes" or the-like)

Section 2:
4) The word "autonomic" is defined in terms of self*, which is not that 
descriptive. Couldn't one describe this in terms of devices reaching 
localized decisions, via observation (akin to the nervous system analogue)?
5) The description of "intent" seems to preclude codifying 
device-specific functionality in, e.g., a device certificate or 
attribute certificate. (As described in the draft, it seems to codify 
only "domain" policy attributes.) As an aside, codifying domains seems 
to require careful network planning and coordination and knowing in 
advance which domain a node should belong to. I wonder to what degree 
this limits flexibility of deployment and ease of use.

Section 3:
6) First bullet (p. 6): With self-configuration, how does one 
distinguish two devices A and B or elevate one to be in control of the 
other? Shouldn't one mention somewhere privacy aspects (what if a retail 
store "discovers" may cell phone and now conveniently tracks this, since 
the cell phone has to authenticate itself first?)
7) Second bullet (p. 6): With self-healing, how does one recover from 
anomalies that cannot easily be decided by majority rules (such as with 
security)?
8) Third bullet (p. 7): With self-optimizing, shouldn't one add some 
verbiage as to local vs. global optimization and the potential impact of 
a local disturbance of the system on state? (As to the latter, I can 
imagine there to be a few algorithms that lend themselves to easy 
convergence and failure recovery, whereas with others, localized failure 
recovery is almost doomed to fail.)
9) First para Section 3.2: "forseeable" should read "foreseeable"
10) First para Section 3.2: "fully autonomic nodes and network(s)" 
(i.e., make the last word plural)
11) In Section 3.2, the priority order (where human decisions rule) 
should not necessarily be a "design principle"; rather, it should be a 
potential instantiation of a policy-setting. After all, management 
functionality should consider a mix of local self-management functions, 
plus oversight (thereby, keeping operational invariants), where 
different applications may call for different decision criteria 
prioritization and choices. (In fact, this is alluded to in the last 
para of Section 3.2, withe auto-pilot and nuclear plant scenarios.) One 
may want to add some verbiage here as well to graceful degradation and 
failure recovery.
12) First para (p. 6): replace "trustworhty" by "reliable"
13) In Section 3.3, first para, one should omit the subsentence "using a 
domain identity, for example a certificate issued by a domain 
certificate authority". After all, there are multiple ways for a device 
to evidence group membership, besides issuing domain specific certs. As 
case in point, with sensor networks such as w/HART, ZigBee, ISA SP100, 
network membership is evidenced by the use of a group key and network 
access is arbitraged by a network manager (who may coincide or 
coordinate with the originator of the group key).
14) In Section 3.3, first para, replace "common trust anchor" by 
"mutually respected trust anchor" (after all, it may be that two devices 
A and B have certs issued by different CAs, but nevertheless A respect 
B's certificate authority's CA and vice-versa).
15) In Section 3.3, 2nd para, while it is possible to have domain 
entities, this is not a priori necessary for autonomic networking: as 
already mentioned above, if network access involves a network manager, 
it could simply perform membership tests via a white list of devices 
(SubjectPublicKeyInfo, so to speak). Should one use domain identities, 
one should clearly articulate how these should be issued, what 
preplanning and coordination this requires and what the impact is on 
flexibility of deployment. This should be compared with alternatives, 
such as the use of group keys in the sensor network example above. As a 
final note, if one where to use domain identities, these could also be 
realized via attribute certs, rather than device certs.
16) In Section 3.4, I believe it has merit to replace the somewhat 
positional/almost ideological language ("decentralization above all") by 
the more neutral statement that one aims to "improve the ability to cope 
with changes". (This is also the language in the ACM 2006 survey paper 
by Dobson et al).
17) In Section 3.4, 2nd para, one should add some verbiage to the effect 
that a central repository of information has also been in the interest 
of vested interests, since this has been about control and lock-in of 
users/customers as well. It is not clear to me why an autonomic network 
*must* be able to use a centralized system in order to be deployable. 
Isn't this just lip service to the vested interests? {I can very well 
imagine, e.g., completely distributed wifi access, with local 
micropayment to pay for ongoing access, without need for any centralized 
system, except perhaps for settling those micro-payments. This seems to 
indicate that the autonomic approach could live in parallel of whatever 
central repositories/control points might be operatioal right now.}
18) In Section 3.5, I would explicitly mention audit/log/monitoring and 
failure recovery mechanisms, as well as, perhaps, aggregated 
functionality that is relevant when one zooms out (e.g., lease more 
capacity on backbone if local network generates lots of traffic).
19) Section 3.6, last sentence of first para: I would argue that some of 
these details do matter, e.g., auto-address configuration, naming of 
entities, etc.
20) Section 3.7, first para: I wonder how "autonomic network reporting" 
provides functional trouble shooting? (Faulty components, anomaly 
detection, dead link, etc.)
21) Section 3.7, last para: replace "special algorithms" by "specific 
algorithms"
22) Section 3.7, last para: while I agree one should be cognoscent to 
not create unnecessary messaging, I again have trouble to see how one 
could build a reliable system if one purportedly does not care about 
detail. With some systems, this may violate per-device requirements 
(e.g., specific safety valve info does not come through).
23) Section 3.8, first para: replace "however, they" by "however, these"
24)  Section 4, first para: replace "items which" by "items that" (also 
on numerous other locations in the draft)
25) Section 4.2, p. 9: replace "fault" by "error"

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363