Subject: [Anima] Warren Kumari's No Objection on draft-ietf-anima-autonomic-control-plane-16: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Jun 2018 16:57:17 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS concerns so quickly and well.

I've cleared.

 (Actually wrote this a few days back, but forgot to hit the confirm button :-
 ( )

-- Original DISCUSS for hysterical raisins --
I'm balloting DISCUSS, but I think that this should be relatively simple to
address: The document says things like:"Today, the management and control plane
of networks typically runs in the global routing table, which is dependent on
correct configuration and routing." and "Context separation improves security,
because the ACP is not
   reachable from the global routing table. "

The term "global routing table" is widely used and understood to mean the
global BGP routing table, or Internet global routing table. I understand that
you are using it in the "default VRF" meaning, but I think that it is really
important to clarify / disambiguate this the first time you use it.

----------

Thank you very much for writing this document -- it is comprehensive...

A rich text version of my review is here:
https://mozphab-ietf.devsvcdev.mozaws.net/D3801#inline-4146 , and pasted below
for tooling, email, etc.

---
draft-ietf-anima-autonomic-control-plane.txt:212
   network nodes that is not the ACP, and therefore considered to be
   dependent on (mis-)configuration.  This data-plen includes both the
   traditional forwarding-plane, as well as any pre-existing control-
Nit: data-plane

draft-ietf-anima-autonomic-control-plane.txt:508
   certificate.  This does not require any configuration on intermediate
   nodes, because they can communicate zero-touch and securely through
   the ACP.
I understand what you are trying to say, but "zero-touch" is not an adverb.

draft-ietf-anima-autonomic-control-plane.txt:518
   the data-plane is operational, will the other planes work as
   expected.
This is *sometimes* an undesirable dependency, but is usually viewed as a
feature (by operational people) -- having the control plane share fate with the
dataplane is something that is usually a feature - this drives at least part of
the reason that many organizations run OSPF and OSPFv3 - having V4 OSPF relying
on v4 dataplane avoids blackholes if the v4 dataplane stops working. (This is
sometimes, but less often used as an argument against ISIS).

I understand why it is useful in this context, but it would be useful to
clarify/make it clear that you understand the subtleties.

Also, nit: "is operational, will the" -- the comma feel weird here.

draft-ietf-anima-autonomic-control-plane.txt:526
   management session is running can lock an admin irreversibly out of
   the device.  Traditionally only console access can help recover from
   such issues.
"only console access or OOB".

You may be using "console access" to mean OOB, but much (most?) OOB is now not
console based.

draft-ietf-anima-autonomic-control-plane.txt:531
   Operations Center") such as SDN controller applications: Certain
   network changes are today hard to operate, because the change itself
   may affect reachability of the devices.  Examples are address or mask
I think that this was an editing issue -- you don't "operate" changes. Perhaps
"implement"?

draft-ietf-anima-autonomic-control-plane.txt:858
   o  If the node certificates indicate a CDP (or OCSP) then the peer's
      certificate must be valid according to those criteria. e.g.: OCSP
You expand CDP further in the document, but this is the first time it is used.

draft-ietf-anima-autonomic-control-plane.txt:994
   ACP neighbors.  Native interfaces (e.g.: physical interfaces on
   physical nodes) SHOULD be brought up automatically enough so that ACP
   discovery can be performed and any native interfaces with ACP
I don't have a suggestion, but "automatically enough" doesn't sound right -
"automatically configured enough" ?

draft-ietf-anima-autonomic-control-plane.txt:1067
   In the above (recommended) example the period of sending of the
   objective could be 60 seconds the indicated ttl of 180000 msec means
   that the objective would be cached by ACP nodes even when two out of
Editing fail -- missing some punctuation or words.

draft-ietf-anima-autonomic-control-plane.txt:1933
   for reachability.  The use of the autonomic control plane specific
   context eliminates the probable clash with the global routing table
   and also secures the ACP from interference from the configuration
IMPORTANT: The term "global routing table" has a well known meaning in
operations -- it is the global BGP table. I strongly suggest using a different
term, or having a very clear statement in the terminology section, AND the
first time you use it in the document. This will help minimize confusion.

draft-ietf-anima-autonomic-control-plane.txt:3081
10.2.  ACP (and BRSKI) Diagnostics
Just a note that I like / appreciate this section - having guidance on how to
troubleshoot is very helpful.

draft-ietf-anima-autonomic-control-plane.txt:3416
10.3.2.2.  Fast state propagation and Diagnostics

   "Physical down" state propagates on many interface types (e.g.:
When I saw the "physically brought down" I started composing a long soapbox
rant on the fact that this will slow down state propagation -- I like that that
document anticipates and addresses this. It might be useful to have a pointer
in the previous section (like "(see below)" or similar.)

draft-ietf-anima-autonomic-control-plane.txt:3482
   for 5 seconds to probe if there is an ACP neighbor on the remote end
   every 500 seconds = 1% power consumption.
I believe that this is sufficiently incorrect that you should remove the 1%
result (or, better yet the whole last sentence).

Various interfaces (especially long reach) take a significant amount of time
(and additional power) when bringing up interfaces -- things like DWDM optics
and amplifiers sometimes need significant power for heating elements to lock
the frequency / wavelength, and so the power consumption is not linear with
interface uptime.