Subject: Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

From: "Michael H. Behringer" <[email-masked]>
Date: Tue, 6 Mar 2018 21:58:03 +0100

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:[email-masked]] On Behalf Of Michael H.
>> Behringer
>> Sent: Friday, February 23, 2018 9:10 PM
>> To: Sheng Jiang <[email-masked]>; [email-masked]
>> Cc: [email-masked]
>> 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.
>>
>> Michael
>>
>>> General 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 -> 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.
>>> 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?

thanks,
Michael

>
> 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:[email-masked]] *On Behalf Of *Sheng
>>> Jiang
>>> *Sent:* Tuesday, January 09, 2018 2:26 PM
>>> *To:* [email-masked]
>>> *Cc:* [email-masked]
>>> *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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima
>> _______________________________________________
>> Anima mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/anima