Subject: [Anima] Warren Kumari's Discuss on draft-ietf-anima-autonomic-control-plane-13: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 06 Jun 2018 10:35:48 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-13: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

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

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.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 9 Jun 2018 01:03:23 +0200

Thanks a lot Warren, great suggestions.

Replies inline

Changes for feedback from Mirja, Kumar and Joel committed to -16,
didn't create separate diff for individual reviewers as diff is not large. 
(Just ignore whole section 11 moved to appendix in diff.)

https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-15.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-16.txt

Cheers
    Toerless

> https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

Good catch. The use of "global routing table" seems to be almost a day 1
text issue of the doc ;-(

We can't use VRF to explain it, because we are not referring to
VRFs in the data-plane anymore for those devices that do not have VRFs.
(reviewer request) Only ACP VRF is defined and used as a term.

I removed all uses of "global routing" (table), and just refer to
"Data-Plane routing (and forwarding, where appropriate) tables":

| Today, the management and control plane of networks typically uses a routing and forwarding table which is dependent on correct configuration and routing

| For management plane protocols, the ACP provides the functionality of a Virtual out of Band (VooB) channel, by providing connectivity to all nodes regardless of their Data-Plane configuration, routing and forwarding tables.

| Context separation improves security, because the ACP is not reachable from the Data Plane routing or forwarding table(s).

Done.

> I understand what you are trying to say, but "zero-touch" is not an adverb.

Took the opportunity fix also some semantics of the paragraph.

 <t>With the ACP, secure bootstrap of new devices and whole new networks can happen without requiring any configuration of unconfigured device along the path: As long as all devices along the path support ACP and a zero-touch bootstrap mechanism like BRSKI, the ACP across a whole network of unconfigured devices can be brought up without operator/provisioning intervention. The ACP also provides additional security for any bootstrap mechanism, because it encrypts the traffic along the path hop-by-hop.</t>

> clarify/make it clear that you understand the subtleties.

Added paragraph:

<t>Note that specific control plane functions for the Data-Plane often want to depend on forwarding of their packets via the Data-Plane: Aliveness and routing protocol signaling packets across the Data-Plane to verify reachability across the Data-Plane, using IPv4 signaling packets for IPv4 routing vs. IPv6 signaling packets for IPv6 routing.</t>

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

Removed

Changed to:

> Traditionally only out-of-band access can help recover from such issues (such as serial console or ethernet management port)

Mileage for ethernet based OOB does vary i think. Probably on DC and 
core/distribution SP gear. Not the typical enterprise gear yet, i think.

> I think that this was an editing issue -- you don't "operate" changes. Perhaps

Good suggestion. Fixed.

> You expand CDP further in the document, but this is the first time it is used.

Expansion of terms was introduced in -14.

> "automatically configured enough" ?

Fixed to:
SHOULD be initialized automatically to a state in which ACP discovery can be performed

> Editing fail -- missing some punctuation or words.

Fixed in -14.

> first time you use it in the document. This will help minimize confusion.

Done. See Discuss section.

> troubleshoot is very helpful.

Thanks. 

> in the previous section (like "(see below)" or similar.)

First paragraph of previous chapter (admin-down) had (see below),
now addd xref: (see below, <xref target="down-fast-state-propagation"/>)

> the frequency / wavelength, and so the power consumption is not linear with

fixed to:

<t>Power consumption of "physical down" interfaces may be significantly lower than those in "admin down" state, for example on long range fiber interfaces. Bringing up interfaces, for example to probe reachabiliy, may also consume additional power. This can make these type of interfaces inappropriate to operate purely for the ACP when  
they are not currently needed for the Data-Plane.</t>

Joel Halpern also asked about DWDM. I'll refrain from trying to add more
details here how this situation could othrewise be mitigated, i just
wanted to highlight understood key aspects, not necessarily all solutions.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 8 Jun 2018 20:40:30 -0400

> Thanks a lot Warren, great suggestions.
​And thanks for addressing -- I just cleared my DISCUSS.
W​

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> | Today, the management and control plane of networks typically uses a
> routing and forwarding table which is dependent on correct configuration
> and routing
>
> | For management plane protocols, the ACP provides the functionality of a
> Virtual out of Band (VooB) channel, by providing connectivity to all nodes
> regardless of their Data-Plane configuration, routing and forwarding tables.
>
> | Context separation improves security, because the ACP is not reachable
> from the Data Plane routing or forwarding table(s).
>
>  <t>With the ACP, secure bootstrap of new devices and whole new networks
> can happen without requiring any configuration of unconfigured device along
> the path: As long as all devices along the path support ACP and a
> zero-touch bootstrap mechanism like BRSKI, the ACP across a whole network
> of unconfigured devices can be brought up without operator/provisioning
> intervention. The ACP also provides additional security for any bootstrap
> mechanism, because it encrypts the traffic along the path hop-by-hop.</t>
>
> >
> <t>Note that specific control plane functions for the Data-Plane often
> want to depend on forwarding of their packets via the Data-Plane: Aliveness
> and routing protocol signaling packets across the Data-Plane to verify
> reachability across the Data-Plane, using IPv4 signaling packets for IPv4
> routing vs. IPv6 signaling packets for IPv6 routing.</t>
>
> > Traditionally only out-of-band access can help recover from such issues
> (such as serial console or ethernet management port)
>
> <t>Power consumption of "physical down" interfaces may be significantly
> lower than those in "admin down" state, for example on long range fiber
> interfaces. Bringing up interfaces, for example to probe reachabiliy, may
> also consume additional power. This can make these type of interfaces
> inappropriate to operate purely for the ACP when

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf