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>; anima@ietf.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.

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:anima-boun...@ietf.org] *On Behalf Of *Sheng
Jiang
*Sent:* Tuesday, January 09, 2018 2:26 PM
*To:* anima@ietf.org
*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

Reply via email to