Subject: [Anima] Review draft-ietf-anima-reference-model-04

From: Artur Hecker <[email-masked]>
Date: Wed, 26 Jul 2017 17:55:13 +0000

Dear community, dear Authors,

I reread the draft-ietf-anima-reference-model-04. I hope it's not arriving at an inappropriate moment, but please find some notes and remarks below:

1. Page 6: s/potentiall/potential

2. Page 8: Section 4. The text mentions "must implement" and "other" functions, but fails to correctly guide the reader as to the MUST or not MUST of the functions in the following subsections. It is partly not even clear from the semantics of the subsections.

Suggestion: clearly group MUST, SHOULD and MAY IMPLEMENT functions in the subsections.

3. Page 12: Information Distribution - consider rewriting parts of this section entirely. Several problems:

a) Remove repetitive text in the beginning:
"Certain forms of information, such as Intent, must be distributed across an autonomic domain. The distribution of information is also a function of the Autonomic Control Plane.  One form of such information is Intent."

Suggestion: Either remove the first inclusion, or the entire last sentence. I would rewrite these three, see next point:

b) There seems to be a problem with the statement above, as the "must" is somehow misleading in a potentially normative text. What is meant here is that some information requires dissemination, while other might not require that. 

Suggestion - please REWRITE e.g. as follows:
"Certain forms of information require per its nature distribution across a (part of) autonomic domain. Such information distribution is a function of the Autonomic Control Plane. As an example, Intents require distribution across the whole autonomic domain as per definitions from RFC7575."

c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference between the requirement to reach all recipients (indeed, the current text seems to equal flooding to that) and flooding, which technically usually means "unconstrained broadcast". [E.g. Wikipedia: "Flooding is a simple computer network routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on"]. This will lead to explosive message number growth, as the ACP uses routing - which does not guarantee a tree structure - while the scale of an autonomic domain is, by definitions of RFC7575, only constrained by the Intent as such ("the autonomic domain is the set of nodes, to which the intent needs to be sent"). At the same time, there are better known algorithms for routing, which achieve "distribution to all recipients" without "sending on all links except the one it arrived on" (e.g. structured broadcast, etc).

Suggestion: stay at the requirements level in the Reference text, which this draft represents. In other words, remove suggestions of implementations, or reword if the requirement to reach all nodes is meant.

4. Page 17, Section 6.3.3.  The Information Distribution ASA (*).
While the text above (on page 12: Information Distribution) says that Information Distribution is function of ACP, somehow there is a distinct section in this draft, talking about an Information Distribution ASA, which is NOT ACP ASA, and which is not obligatory.

How to read this correctly?

5. Page 17, Section 7.1: "How an AN Network Is Managed"
a) Please consider changing the title. AN is "autonomic network" network network :-)
b) The first paragraph says that the co-existence is twofold. However, I can think of at least one other way: the ACP could be used as a transport channel for "traditional" management. E.g. ACP could be used to transport NETCONF messages, instead of SSH or BEEP in NETCONF. Not clear, what twofold means here (just an example, limitation, strong statement, etc).

6. Page 18, Section 7.2: "Intent"
Please reread and correct this phrase: "It is expected Intent definitions from autonomic function(s) and even from traditional network management elements". (missing verb)

Later in the text, the section references I-D.liu-anima-grasp-distribution, which is odd, given that the actual Information Distribution section (see above) does not. Yet, information distribution in I-D.liu-anima-grasp-distribution is not limited to intents.

7. Page 19, Section 7.5: "Control loops"
The section talks about an "Autonomic System". Unless I am mistaken, an autonomic system is not defined (e.g. in RFC7575). This is a minor issue, as we all can imagine what a "system" is.

8. Page 20, Section 7.6: "APIs"
There is a strong "MUST" requirement in this section (express and preserve semantics across different domains), which is not as clear as a MUST should be. First, it's not clear what "express and preserve semantics" means (semantics of what? Of objects? Of object methods? Of the results delivered by object methods? Of all of them?). Second, the "domain" is not defined: is an autonomic domain meant? Note that this notion is dynamic, as per intent scope, so probably not a very good reference. Third, the requirement is not corroborated clearly. Instead, an example is given, which we might discuss in its relevance to the ANIMA WG and work scope. Is ANIMA implementing software contracts? Is it a MUST requirement? Probably not. Note that web-based systems today have no such formal specifications, as mentioned in this section. Example: invariants; these are nice to have, but hard to determine for any complex piece of software (like a web service, etc).

9. Page 20, Section 7.7: "Data Model"
Question: why do we need this section? This looks like some text book. Do we have a specification of data model in ANIMA? Information model? Anything like that? If not, I guess this can be shortened, as it is "for reference" only. (What is MRACL? Used without explanation in text).

10. Page 22, Section 8.1:
s/mechanisms exists/mechanisms exist.

11.  Page 23, Section 9: "Security Considerations"
Please rephrase "run inside the encrypted ACP". I hope that it's not simply "encrypted" but actually features the full range of cryptographic data protection methods.

Rationale: I would argue that integrity is more important than confidentiality in the ANIMA scope. As encryption alone does not provide any protection against modification, and since hopefully the used mechanisms (see Section 9.2) go beyond encryption, I would recommend to use a more correct wording, something like "protected" or "cryptographically protected ACP".

Generally, the section does not sufficiently presents the threat of message modification and replay, including the discovery messages. Also, authentication is not sufficiently covered, even though a reference to I-D.ietf-anima-bootstrapping-keyinfra is made. Not sure it's the best approach, as bootstrapping refers to how to enroll the node, and the authentication is probably using standard mechanisms? Normally, the threats should be described independently of the specific mechanisms.

Regards
artur

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jul 2017 08:14:14 +1200

Artur,

Thanks for your review. Whoever takes up the editing pen next will certainly use your comments.

> c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference…

I agree in general; the way the text uses "flood" is careless. However, the GRASP flooding mechanism is (a) of course limited to GRASP nodes and (b) contains specific measures to prune the distribution and prevent loops. While
that does not guarantee a strict tree structure, i.e. is not an idealised multicast routing algorithm, it doesn't require the ACP to support multicast routing and it is well adapted to low-frequency information distribution as we expect in an AN. 

Regards
   Brian

---

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 26 Jul 2017 22:17:17 +0200

Thanks for your comments, Artur. I'm in the middle of vacations, but 
will incorporate your comments when back, in the next version!

Brian, seen your response, too. Will catch up...

Michael

On 26/07/17 19:55, Artur Hecker wrote:
> c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference between the requirement to reach all recipients (indeed, the current text seems to equal flooding to that) and flooding, which technically usually means "unconstrained broadcast". [E.g. Wikipedia: "Flooding is a simple computer network routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on"]. This will lead to explosive message number growth, as the ACP uses routing - which does not guarantee a tree structure - while the scale of an autonomic domain is, by definitions of RFC7575, only constrained by the Intent as such ("the autonomic domain is the set of nodes, to which the intent needs to be sent"). At the same time, there are better known algorithms for routing, which achieve "distribution to all recipients" without "sending on al
>   l links except the one it arrived on" (e.g. structured broadcast, etc).
>
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Artur Hecker <[email-masked]>
Date: Thu, 27 Jul 2017 08:23:23 +0000

Brian,

Thanks for your answer. Good to know that GRASP takes those precautions, very good. It would be interesting to know how it does it - we will probably get to testing the current implementation at one point, please bear with us :-)

Still, referring to the draft in the email subject, as it is a reference model with requirements only, if I read it stupidly (letter by letter) then GRASP is not flooding, so it's not conforming to the reference model :-) (depending on the interpretation of "flooding" in the text).

My actual point is that we should not get into implementations in this draft. Maybe I am wrong. I think some rewording will do the trick.

Regards
Artur

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: 26 July 2017 22:14
To: Artur Hecker; [email-masked]
Subject: Re: [Anima] Review draft-ietf-anima-reference-model-04

Artur,

> c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference…

I agree in general; the way the text uses "flood" is careless. However, the GRASP flooding mechanism is (a) of course limited to GRASP nodes and (b) contains specific measures to prune the distribution and prevent loops. While that does not guarantee a strict tree structure, i.e. is not an idealised multicast routing algorithm, it doesn't require the ACP to support multicast routing and it is well adapted to low-frequency information distribution as we expect in an AN. 

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Jul 2017 08:44:03 +1200

> Still, referring to the draft in the email subject, as it is a reference model with requirements only, if I read it stupidly (letter by letter) then GRASP is not flooding, so it's not conforming to…

1) The objectives in GRASP M_FLOOD (or M_DISCOVERY) messages carry a loop count that
decreases at each hop, with a suggested default initial value of 6, but of course that
might be larger in a large network.

2) Nodes that relay M_FLOOD or (M_DISCOVERY) must cache the session ID and must
not relay messages with the same cached session ID again (within the cache lifetime,
obviously).

3) Nodes must limit the rate of relaying. (This is not implemented in my
prototype, due to laziness. But the two previous points are enough to prevent
loops in any topology.)
 
> My actual point is that we should not get into implementations in this draft. Maybe I am wrong. I think some rewording will do the trick.

Agreed.

    Brian

>> c) Later, the text in this section somehow confuses the high level requirements (=information distribution) with a specific implementation, notably flooding. Note that there is a subtle difference between the requirement to reach all recipients (indeed, the current text seems to equal flooding to that) and flooding, which technically usually means "unconstrained broadcast". [E.g. Wikipedia: "Flooding is a simple computer network routing algorithm in which every incoming packet is sent through every outgoing link except the one it arrived on"]. This will lead to explosive message number growth, as the ACP uses routing - which does not guarantee a tree structure - while the scale of an autonomic domain is, by definitions of RFC7575, only constrained by the Intent as such ("the autonomic domain is the set of nodes, to which the intent needs to be sent"). At the same time, there are better known algorithms for routing, which achieve "distribution to all recipients" without "sending on 
>  all links except the one it arrived on" (e.g. structured broadcast, etc).
>