Inline... On 28/02/18 15:36, Sheng Jiang wrote:
Hi Michael,Thanks for addressing my review comments. Below in lines for my further comments regarding to several points. None of them are major. So, I will start my document shepherd based on the current 06 version. It is up to you to do a quick update soon or addressing them together with the IESG review comments, which I am sure will have. Regards, Sheng-----Original Message----- From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Michael H. Behringer Sent: Friday, February 23, 2018 9:10 PM To: Sheng Jiang <jiangsh...@huawei.com>; firstname.lastname@example.org Cc: anima-cha...@ietf.org Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima- reference-model-05 - Respond by January 22nd, 2018 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.Hi Sheng, 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 issues now. Details below in line. MichaelGeneral issues: 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 architecture view. 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 with ACP?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 Plane". 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.[Sheng] My original comment implied two aspects: 1. As you explained, the "General" control plane vs. the "specific" implementation (ACP). So, as I understood, the ACP is an instance of GACP. I have no problem on this. 2. The specific ACP actually serves as a management channel for the underlay network, in this sense, the ACP could be seen as a "management plane" for the underlay network; in other words, the ACP is a "Virtual DCN(Data communication network)". Thus, there could be a summary of management functions running inside the ACP, and this summary doesn't belong to ACP itself. If you agree with it, I think this also needs to be clarified.
Yes, of course I agree with it! :-) I'm however worried that this will confuse readers a lot. I suggest in this document to stick to the autonomic aspect of the ACP only. And in section 4.6 we already say "See [I-D.ietf-anima-stable-connectivity <https://tools.ietf.org/html/draft-ietf-anima-reference-model-06#ref-I-D.ietf-anima-stable-connectivity>] for uses cases for the ACP." which describes in detail what you're saying above. I suggest we leave it with this in the reference model.
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 standardization. </t> 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 the infrastructure. Now, the word "charter" is no longer in the text at all. Comments?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.Specific comments: 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.Fixed.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 clear enough.- Nits in Figure 2 Synchronization -> synchronizationThe 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. negotiation/sync signaling.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 link-local scope.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. Thoughts?[Sheng] The added texts are good for me. But please pardon me for opening the can even a bit more: When one device has enrolled, maybe it is good to keep the domain certificate as well as the LDevID? In this way, the network won't suffer too much in a power outage event. If it is plugged into another domain, it should not be difficult to detect the abnormity.
We're saying the same thing. LDevID *is* the domain certificate. And it should keep that. You probably meant to say the IDevID, which it also keeps.
Although, my feeling is that we should not *forbid* a case where the LDevID (domain cert) is lost in a power outage / reboot event. While our current use cases would probably not behave optimally, I think there may be special cases in the future where this may be an option.
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 “phase 1”.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 mentioned.Done.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.[Sheng] I think Section 7.6 (APIs) is related to drfat-ietf-anima-grasp-api, I couldn't exactly tell whether the GRASP API design consists with the design principles described in this section. If this section doesn't mean that API related work "MUST" follow the design principles, I'd suggest to add a sentence to clarify it.
Good point. I'll add that point. I think this should not stop us from proceeding with the IESG review, we can add that later. Can we progress the doc now?
Regards, Sheng- 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, Sheng *From:*Anima [mailto:anima-boun...@ietf.org] *On Behalf Of *Sheng Jiang *Sent:* Tuesday, January 09, 2018 2:26 PM *To:* email@example.com *Cc:* anima-cha...@ietf.org *Subject:* [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018 Hi all, 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. Regards, Sheng (co-chair, Toerless who as a co-author stayed neutral on the content side) _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima