On 18/01/18 09:59, Sheng Jiang wrote:
Hi, authors of anima-reference-model,
I have reviewed the draft as the document shepherd, see below
comments. Overall, I feel this document is very useful and it is
almost ready for be published. Please properly address my comments
together with other WGLC comments you may receive. Another revised
version of the document is needed to process the document further if
it passed the WGLC.
First of all thanks for the thorough review. I am now finished with
working your comments into the draft. I am just publishing version -06.
This version should address all your comments. I am not aware of any
other outstanding comments, and believe we have addressed all open
Details below in line.
1. In section 3.1, it says “The Autonomic Control Plane (ACP) is the
summary of all interactions of the Autonomic Networking Infrastructure
with other nodes and services.” I’m a bit confused by this statement.
In my understanding, the ACP itself is mostly a “channel”, although
some ANI functions (signaling, aggregated reporting etc.) are running
within the channel, they should be parallel with ACP function in the
At the same time, there are indeed some functions considered as
sub-functions of the ACP, e.g. the addressing and routing, which are
necessary to make the ACP runnable.
So, my questions to the co-authors:
1) Do you see ACP as an individual function as I understood (mostly a
channel), or a summary of a suite of functions running inside the ACP?
2) What functions are sub-functions of ACP, and what are in parallel
There are really two meanings to the term "ACP". This has caused quite
some confusion, and I agree it needs to be nailed once and for all.
Thanks for raising it here.
1) The general term "control plane" refers to the sum of all protocols
that control network behaviour. Like, in a traditional network, routing
protocols, etc. Consequently, an "Autonomic Control Plane" is the sum of
all protocols that controls the behaviour of an autonomic network. In
draft-ietf-anima-stable-connectivity we now use the term "Generalized
ACP" for this abstract concept.
2) In the ANIMA context, we use the term "ACP" also to describe a very
specific implementation of the generic concept of an "Autonomic Control
I now cleared up the naming in the reference draft. Where we mean the
abstract concept (3.1 for example), I now use "GACP", where we mean the
implementation, I now use "ACP" and refer to the ACP draft.
Specifically, I changed in 3.1 from ACP to GACP. And re-worded section
4.6, which is all about the implementation of the ACP.
2. I’m confused by the whole purpose of Section 3. The first
sub-clause is describing the architecture of an Autonomic Network
Element, while the rest sub-clauses (adjacency table, state machine
etc.) seems more like “implementation considerations” or “procedures”.
I think both are useful content, but they are in two different
dimensions, maybe separate them into different sections?
Well, the section is about the network element. I find it quite logic
that you first discuss the architecture of the element, then how it
behaves in a network. However, I added an explanatory intro at the
beginning of that section to make it clearer. Thanks for pointing out
that this wasn't clear!
3. Some texts (e.g. paragraph 4 of Section 1) are directly bind to the
WG’s charter, I’m not sure it is a good approach that an RFC
normatively refer the WG charter which is dynamically changed along
with the work going on in the WG. Maybe just simply re-phrase the
“chartered work” as “Phase 1/near term work”, and “non-chartered” as
“Phase 2 long-term”?
Agree that needs to be fixed. Did some editorial changes for that. The
sections with an (*) now start with a sentence like this:
<t>... is not covered in the current implementation specifications.
This section is for informational purposes, for following phases of
As part of that fix, I also re-worded the abstract. It now reads:
This document describes a reference model for Autonomic Networking. It
defines the behaviour of an autonomic node, how the various elements in
an autonomic context work together, and how autonomic services can use
Now, the word "charter" is no longer in the text at all.
4. The whole Section 7 seems too theoretical and abstract. The
described concepts are valuable, I’d suggest to have more texts
mapping these concepts into the ANI/AN.
I made the changes described above, to point out very explicitly that
these sections are essentially for future study. I would prefer NOT to
do any more editing beyond that. That should be done in a subsequent
document, I think.
Section 1 Introduction
- Paragraph 3 claims “This reference model allows for this hybrid
approach.” I think it would be better to explain in what degree the
“hybrid” could be. For example, the ANI actually doesn’t support
non-autonomic nodes to join in the same domain with the autonomic
nodes; thus, in this deployment level, it is not “hybrid”.
Good point. I added an example to explain the concept. I thought of
adding more, but then I think the intro would become too long.
- As said in the general issues, paragraph 4 seems binding with the WG
charter too much.
That is resolved.
Section 2 The Network View
- In the figure, it seems the ASAs are hierarchical, but there is no
relevant texts. My understanding is that, it is reasonable to
distinguish layered ASAs, e.g., some ASAs might be very fundamental,
and should be the future work of the Anima WG; while most of the
specific ASAs are service/scenario relevant, that might not be
suitable to do them case by case in Anima.
Oh, it was not the intention to imply a hierarchy. Thanks for pointing
this out. ASAs may or may not be hierarchical. I added a sentence to
clarify: "ASAs may be standalone, or use other ASAs in a hierarchical way."
- “The current charter of the ANIMA WG is to specify the ANI, using a
few autonomic functions as use cases.” Again, I’m not sure it is good
to bind the RFC to the WG charter.
Section 3 The Autonomic Network Element
- If Figure 1 means to make the ASAs hierarchical, then it is better
to be consistent in Figure 2.
I think this is fixed with the above text. Let me know if it is not
- Nits in Figure 2
Synchronization -> synchronization
The RFC editor will fix all the UK vs US English issues. I'll leave it
to them, since I'm not a native English speaker.
In the ANI part, the “Discovery, negotiation and synchronisation
functions” looks like a sub-item of “Autonomic Node Addressing”, I
guess it should be typo?
Good catch. Fixed.
- Section 3.1 “The Autonomic Networking Infrastructure (ANI) is
normally built on a hop-by-hop basis.” It is true for ACP, but I don’t
think it applies for all the other ANI functions, e.g.
Note the "built". I think the sentence is correct. However, to clarify,
I changed "built" to "constructed". And, we're really talking ACP here.
I changed that as well.
- Section 3.2, the first bullet point of paragraph 3 “link local
discovery”, it is ambiguous that what kind information is gathered
through GRASP. I think there should be some basic information gathered
through ND protocol.
Yes, this section is a bit ambiguous, I agree. But if we want to make it
precise, it's going to explode the section and make it unreadable.
Hmmm... I think the issue is really the phrase "This is described in
[GRASP]". I re-phrase that to "The related standards track documents
(GRASP, ACP, BRSKI) describe in detail how link local discovery is used."
- Section 3.2, the third bullet point: “Once the node is part of the
ACP of a domain, it will use GRASP discovery [I-D.ietf-anima-grasp] to
find Registrar(s) of its domain and potentially other services.” The
later version of BRSKI changed to use a GRASP Flood message to
actively broadcast the registrar service by the proxies in their
I removed "discovery". "It will use GRASP" is correct.
- Section 3.3.2, I think it would be good to briefly discuss the
situation that if an enrolled node re-boot from power cut or be
attached to another network, how the transition state would be? Is it
the same with “Factory reset”?
This discussion is not specific to 3.3.2. A node can reboot at any point
in time. The important part is if it keeps its LDevID or not.
But you're right. This is not mentioned anywhere... Hmmm... Thinking
more, this is just another transition in the state machine, for each
state. I'll add that, I think it makes sense.
"Powercycle event: The device loses all state tables, but not its
domain identity (LDevID). Next state: 2."
I hope I'm not opening a can of worms here... It is possible to conceive
a model where a device also loses its LDevID... I think that's going to
be an extreme corner case, and would prefer to not even mention it here.
Section 4 The Autonomic Networking Infrastructure
- Section 4.2 Addressing, there are a list of comprehensive
requirements of addressing, which are good content. It might be better
if Section 4.1 Naming also include such a requirement list?
I think the requirements are in the section, just not in a bulleted
list. Frankly, I prefer not to change this at this stage of the
document. Let me know if we're missing a requirement.
- Section 4.5 “All autonomic nodes in a domain must be able to
communicate with each other, and with autonomic nodes outside their
own domain.” The cross-domain mechanism hasn’t be covered yet, maybe
it’s better to note this feature is for “long term” work rather than
OK, changed that to "in later phases also with ..."
- Section 4.6 “The totality of autonomic interactions forms the
"Autonomic Control Plane". Again, it is the same as No.1 general issue
as described above.
Changed to "The "Autonomic Control Plane" carries the control protocols
in an autonomic network."
Section 5 Security and Trust Infrastructure
- Section 5.2 describes domain certificate; I think the device
certificate, which is pre-set by the manufacture also needs to be
Section 6 Autonomic Service Agents (ASA)
- It might be good to reference draft-carpenter-anima-asa-guidelines?
Good point. Included.
- Section 6.3 is interesting, it actually unveils the ANI functions
(except GRASP) are yet ASAs. It is no problem for me, but I have a bit
concern that new readers might be confused about the “overlap/mixture”
between ANI and ASAs?
I thought we were quite clear about that. In section 6.1 we say:
o A few 'infrastructure ASAs' that use basic ANI features in support
of the ANI itself, which must run in all autonomic nodes. These
are outlined in the following sections.
I suggest we leave it at that.
Section 7 Managing a (Partially) Autonomic Network
- Section 7.6 APIs: this section are too abstract for me, I just
couldn’t really get the point. It seems like a general design pattern
rather than specific mechanisms related to autonomic networks.
I agree with you, it is fairly generic. At the same time it provides
some context to the APIs we use, and it's clearly marked with a (*) as
being phase 2. I suggest we leave it in. If folks feel strongly, I think
we could take out the entire section. For now I leave it.
- Section 7.7 Data Model has the similar issue as above. It explains
the concept but lacks essential content related to ANI.
Dito. I suggest to leave it for now.
[end of reply]
Thanks and regards,
*From:*Anima [mailto:anima-boun...@ietf.org] *On Behalf Of *Sheng Jiang
*Sent:* Tuesday, January 09, 2018 2:26 PM
*Subject:* [Anima] WGLC on draft-ietf-anima-reference-model-05 -
Respond by January 22nd, 2018
This message starts the two-week ANIMA Working Group Last Call to
advance draft-ietf-anima-reference-model-05, A Reference Model for
Autonomic Networking. This document's intended status is
Informational. At present, there is no IPR file against this document.
Please send your comments by January 22nd, 2018. If you do not feel
this document should advance, please state your reasons why.
Sheng JIANG is the assigned document shepherd.
Sheng (co-chair, Toerless who as a co-author stayed neutral on the
Anima mailing list
Anima mailing list