Subject: [Anima] WGLC on draft-ietf-anima-autonomic-control-plane-12 - Respond by October 28th, 2017,

From: Sheng Jiang <[email-masked]>
Date: Sun, 15 Oct 2017 08:59:45 +0000

Hi all,

This message starts the two-week ANIMA Working Group Last Call to advance draft-ietf-anima-autonomic-control-plane-12, An Autonomic Control Plane (ACP). This document's intended status is Standards Track. At present, there is one IPR file against this document, see below link.

https://datatracker.ietf.org/ipr/2407/

Please send your comments by October 28th, 2017. 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)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Oct 2017 16:25:03 +1300

Here's my first comment on this draft. However, it is very long and I hope you can allow some extra delay.

As far as the two GRASP objectives are concerned, both "AN_ACP" and "SRV.est"
look mainly OK and I have made a demonstration implementation of both of them.
For example, the ASA pretending to be an established ACP node says things like:
 Flooding AN_ACP 17 500 and SRV.est 6 83
and the ASA pretending to be a new ACP node trying to join says things like:
 Found 1 result(s) for SRV.est 
 SRV.est with locator fe80::c0da:ac17:5f6d:8e76 6 83 expiry 30693 
 Found 2 result(s) for AN_ACP 
 AN_ACP with locator fe80::c0da:ac17:5f6d:8e76 17 500 expiry 30693 
 AN_ACP with locator fe80::c0da:ac17:5f6d:8e76 17 504 expiry 30753

I haven't uploaded this code to GitHub yet because it needs more testing.

I do have a question about the value field of each of these objectives.
They are both defined as "name of the (list of) of supported protocols"
but the examples show a simple string. That needs to be more precise.
Is it a string, a list of strings ["abc", "def"] or something else?
And do the names need to be registered?

That covers about 2 pages. I need a little more time for the other 104 pages.

Regards
   Brian

On 15/10/2017 21:59, Sheng Jiang wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: William Atwood <[email-masked]>
Date: Tue, 24 Oct 2017 22:35:56 -0400

Hello,

These are my technical comments on this draft, for the first 32 pages.
Given the length of the document, I do not expect to be able to finish
it by October 28, so I second Brian's request for additional time.

  Bill

1) The definition of "ANI" in Section 2 says that it includes ACP, BRSKI
and GRASP.  The statement of Requirements in Section 4 says:

"ACP4:  The ACP MUST be generic. ... It MUST NOT be tied to a particular
application or transport protocol."

These two statements are in conflict, because the ANI as defined in this
document clearly depends on GRASP.

2) As a specification, Step 4 in Section 5 is terrible.  Step 3
explicitly includes the "for-loop".  Step 4 then shifts to the
perspective of an individual peer relationship, and uses the singular in
the first sentence.  It then shifts again to the plural for the second
sentence.  Suggested text:

"4. For each node in the candidate peer list, it then establishes a
secure tunnel of the negotiated type.  The resulting tunnels are then
placed into the previously set up VRF.  This creates an overlay network
with hop-by-hop tunnels."

3) In Section 6.1.1, in the comment on "routing-subdomain", it says,
<<"rsub" is optional and should only be used when its impacts are
understood.>>  Who must do the understanding?  What is the test for
"understanding"?  Is this a statement that "rsub" should not be used
until the WG has done more work, or until the reader has read this
document 42 times, or ??  For a normative section of this document, this
is remarkably ambiguous.

4) In Section 6.2.3, para 1, line 3, "must" -> "MUST"  (I believe that
this requirement should be normative.)

5) In Section 6.7.2, para 2, line 4, "and not permit" -> "and MUST NOT
permit"  (The implied dependence on the previous "MUST" should be made
explicit.)

6) In Section 6.8.2, para 2, I was puzzled by the statement that the ACP
could exist in the absence of any active ACP neighbors, since the ACP is
only created with the help of a neighbor that is already a member of the
domain.  I then realized that domain membership (and its accompanying
domain certificate) could be established while a neighbor was active,
and then the neighbor could vanish.  I suggest adding some text to make
this sequence of events clear.  Suggestion: "It is created when the node
has a domain certificate, and continues to exist even if all of its
neighbors cease operation."

On 15/10/2017 4:59 AM, Sheng Jiang wrote:
> Hi all,
> 
>  
> 
> This message starts the two-week ANIMA Working Group Last Call to
> advance draft-ietf-anima-autonomic-control-plane-12, An Autonomic
> Control Plane (ACP). This document's intended status is Standards Track.
> At present, there is one IPR file against this document, see below link.
> 
>  
> 
> Please send your comments by October 28th, 2017. If you do not feel
> this  document should advance, please state your reasons why.
> 
>  
> 

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Oct 2017 16:44:27 +1300

Hi,

I've already sent my comments on the GRASP objectives defined in this version.

Here are my comments from a superficial re-read of the whole document. I only
spent about an hour on this, so document shepherd and AD please note:
this document really needs multiple reviewers.

Nits and substantive points are mixed together.

Introduction, page 5:

>    The following sections are non-normative: Section 7 reviews benefits
>    of the ACP 

Actually that should be Section 9. I really hope you are using <xref>
for all internal references. Otherwise there will be a disaster when
this goes to the RFC Editor.

Introduction, page 6:

>    The ACP as defined in this document can be implemented and operated
>    without dependency against other components of autonomous networks

Please don't use "autonomous". It doesn't mean exactly the same as
"autonomic". This occurs in 4 places in the draft. (Autonomous cars drive
themselves. An autonomic car would also decide for itself where to go.)

Acronyms and Terminology, page 7:

>    domain information (field):  An rfc822Name information element (e.g.:
>       field) in the domain certificate in which the ACP relevant
>       information is encoded: the domain name and the ACP address.

You need to define "domain certificate" too, even just a forward
reference since it is well explained later in the draft.

Also, somewhere in the terminology section, can you give a relevant
definition of "loopback interface", since we have established via
the 6man list and even the internet-history list that it is a
slippery concept. Something like:

loopback interface: The conventional name for a neutral virtual
IP interface to which addresses may be assigned, but which
transmits no external traffic.

In Overview, page 13:

>    Note:
> 
>    o  Non-autonomic NMS ("Network Management Systems") or SDN
>       controllers have to be manually connected into the ACP.

The phrase "manually connnected" bugs me a little. I agree there
needs to be a human decision but that will be a configuration
decision; the actual connection process will be automated.
How about "manually configured for connection into the ACP"?

>    o  Connecting over non-ACP Layer-3 clouds initially requires a tunnel
>       between ACP nodes.
> 
>    o  None of the above operations (except manual ones) is reflected in
>       the configuration of the node.

That sentence illustrates exactly why "manually connected" is wrong.

In ACP Adjacency Table, page 20:

>    To know to which nodes to establish an ACP channel, every ACP node
>    maintains an adjacency table.  The adjacency table contains
>    information about adjacent ACP nodes, at a minimum: node-ID, Link-
>    local IPv6 address (discovered by GRASP as explained below), domain,
>    certificate. 

You must also include the interface index (the number, not the name)
with the LL address. Without that, the address is useless. (Discussed
with Michael B a long time ago, but somehow it didn't make it into
the reference model text.)

(I write as one who has coded the process of discovering a node's
link local addresses and interface indexes, because GRASP can't run
without them.)

Also - this text duplicates the reference model. We'd perhaps better
agree where it belongs and delete it from one draft or the other.
Duplicated text always causes problems later.

In GRASP as a core service of the ACP, page 28:

>    The ACP does not use IP multicast routing nor does it provide generic
>    IP multicast services. 

However, GRASP sends multicasts to the GRASP multicast address on each
ACP interface, sent as unicast inside the ACP tunnels. This is fully explained
later, but the reader might be confused. I suggest adding:

  The handling of GRASP multicast messages is explained in the following section.

In Addressing inside the ACP, page 33:

>    Links inside the ACP only use link-local IPv6 addressing, such that
>    each node only requires one routable virtual address.

Does the really mean each *node*? Can we have more than one ACP instance in
a node? And didn't we discuss some use cases for multiple addresses recently?

A related but more general question:

If there are multiple GRASP instances in a node (ignoring the DULL case),
does each instance require its own ACP unicast address and its own ACP
security associations? (I hope the answer is "No".)

In Combined ACP/Data-Plane Interface (VRF Select), page 57:

>    In result, RFC6724 source address selection Rule 5.5 may result in
>    the same correct source address selection behavior of NMS hosts
>    without further configuration on it as the separate ACP connect and
>    data-plane interfaces.  As described in the text for Rule 5.5, this
>    is only a may, because IPv6 hosts are not required to track next-hop
>    information.

Well, you can change this by requiring RFC8028.

In Configured Remote ACP neighbor, page 58:

>        remote-peer = [ local-address, method, remote-address ]
>        local-address  = ip-address
>        remote-address = transport-address
>        transport-address =
>           [ (ip-address | pattern) ?( , protocol ?(, port)) (, pmtu) ]
>        ip-address = (ipv4-address | ipv6-address )
>        method = "IKEv2" / "dTLS" / ..
>        pattern = some IP address set

Hmm. This seems a bit loose for normative text. What's ".."
and what's the format of "pattern"?

That's it for now.

     Brian

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 26 Oct 2017 06:10:31 +0000

Hi, William and Brian,

Thanks for your review. I would not draw a conclusion before November 3rd. That gives one week extra time. If that's still not enough, I suggest you to express the major point first. The details could be come later. They could be addressed together with the comments received during IETF-scope review and IESG review.

Regards,

Sheng

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of William Atwood
> Sent: Wednesday, October 25, 2017 10:36 AM
> To: [email-masked]
> Subject: Re: [Anima] WGLC on draft-ietf-anima-autonomic-control-plane-12 -
> Respond by October 28th, 2017,
> 
> Hello,
> 
> Given the length of the document, I do not expect to be able to finish it by
> October 28, so I second Brian's request for additional time.
> 
>   Bill
> 
> 1) The definition of "ANI" in Section 2 says that it includes ACP, BRSKI and
> GRASP.  The statement of Requirements in Section 4 says:
> 
> 2) As a specification, Step 4 in Section 5 is terrible.  Step 3 explicitly includes
> the "for-loop".  Step 4 then shifts to the perspective of an individual peer
> relationship, and uses the singular in the first sentence.  It then shifts again to
> the plural for the second sentence.  Suggested text:
> 
> "4. For each node in the candidate peer list, it then establishes a secure tunnel
> of the negotiated type.  The resulting tunnels are then placed into the
> previously set up VRF.  This creates an overlay network with hop-by-hop
> tunnels."
> 
> 3) In Section 6.1.1, in the comment on "routing-subdomain", it says, <<"rsub" is
> optional and should only be used when its impacts are understood.>>  Who
> must do the understanding?  What is the test for "understanding"?  Is this a
> statement that "rsub" should not be used until the WG has done more work, or
> until the reader has read this document 42 times, or ??  For a normative
> section of this document, this is remarkably ambiguous.
> 
> 4) In Section 6.2.3, para 1, line 3, "must" -> "MUST"  (I believe that this
> requirement should be normative.)
> 
> 5) In Section 6.7.2, para 2, line 4, "and not permit" -> "and MUST NOT permit"
> (The implied dependence on the previous "MUST" should be made
> explicit.)
> 
> 6) In Section 6.8.2, para 2, I was puzzled by the statement that the ACP could
> exist in the absence of any active ACP neighbors, since the ACP is only created
> with the help of a neighbor that is already a member of the domain.  I then
> realized that domain membership (and its accompanying domain certificate)
> could be established while a neighbor was active, and then the neighbor could
> vanish.  I suggest adding some text to make this sequence of events clear.
> Suggestion: "It is created when the node has a domain certificate, and
> continues to exist even if all of its neighbors cease operation."
> 
>