Subject: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-05.txt

From: [email-masked]
Date: Thu, 12 Jan 2017 09:33:57 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach of the IETF.

        Title           : An Autonomic Control Plane
        Authors         : Michael H. Behringer
                          Toerless Eckert
                          Steinthor Bjarnason
	Filename        : draft-ietf-anima-autonomic-control-plane-05.txt
	Pages           : 34
	Date            : 2017-01-12

Abstract:
   Autonomic functions need a control plane to communicate, which
   depends on some addressing and routing.  This Autonomic Control Plane
   should ideally be self-managing, and as independent as possible of
   configuration.  This document defines an "Autonomic Control Plane",
   with the primary use as a control plane for autonomic functions.  It
   also serves as a "virtual out of band channel" for OAM communications
   over a network that is not configured, or mis-configured.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Jan 2017 16:58:32 +1300

Hi,

Some comments, not in order of importance.

> 2.3.  Data Plane Independent Permanent Reachability

It's probably worth noting in this section that the ACP
does depend on some basics: e.g. layer 2 bridges functioning
and intermediate nodes functioning (even if their data plane
routing is down). Otherwise it sounds a bit miraculous.
Maybe this is also the place to first mention that the ACP
may partition when something basic breaks.

> 5.1.1.  Domain Certificate with ANIMA information
...
>    An example:
> 
>    anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email-masked]
> 
>    The ACP address MUST be specified in its canonical form, as specified
>    in [RFC5952], to allow for easy textual comparisons.

Er-hum. RFC5952 specifies lower case hexadecimal.

> 5.1.2.  AN Adjacency Table
...
>    Where the next autonomic device is not directly adjacent, the
>    information in the adjacency table can be supplemented by
>    configuration.  For example, the node-ID and IP address could be
>    configured.

I hate this. If we let this camel put its nose in the tent, how can
we claim the result is "autonomic"? At the very least, I would to see
this (and any other such items) in a separate section with a big red
flag on it.

Maybe move this point to "6.2. ACP through Non-Autonomic L3 Clouds"?

> 5.2.1.  L2 topology considerations
...
>    Predictable scaling requirements for ACP neighbors can most easily be
>    achieved if in topologies like these, AN capable L2 switches can
>    ensure that discovery messages terminate on them so that neighboring
>    AN routers and switches will only find the physcially connected AN L2
>    switches as their candidate ACP neighbors.

Correct, but since you will soon present GRASP as the discovery mechanism,
I think you need to say here that *as a result of this requirement*, such
L2 switches need to run L3 (i.e. IPv6) and the ANI software suite
(i.e. at least ACP, BRSKI and GRASP). Dumb switches need not apply.

> 5.2.3.  Discovery with GRASP
...
>    The name of the GRASP objective to announce/discover the capability
>    of a neighbor to run the ACP is "ACP".

We're now suggesting "AN_ACP" simply so that it's identified as an ANI
objective. Not a big deal, just a suggested convention.

>    The precise
>    GRASP objective to be used is specified in Section 3 of
>    [I-D.carpenter-anima-ani-objectives].

That's fine for now. Later we should consider moving the definition
into this draft.

There's an open question whether we use the Flood or Discover/Negotiate
mechanism of GRASP for this. My view is that Flood is the simplest
and since it doesn't require any GRASP message from the discovering
node, it's marginally less attackable. [I-D.carpenter-anima-ani-objectives]
describes both options, but we need to decide.

> 5.2.4.  Discovery and BRSKY

s/BRSKY/BRSKI/

This section needs to use the agreed terminology at
https://mailarchive.ietf.org/arch/msg/anima-bootstrap/Iqsosf7pBgOeep4UL0C73mSUSKQ

>    When an autonomic device is a registrar, it will announce the
>    registrar function via GRASP in the ACP as the "6JOIN" objective.

That name is not settled. I suggest deleting it here; it belongs
in the BRSKI spec. (Also, every Join Registrar will also behave as
a Join Assistant, so it will also announce the assistant function
as a GRASP objective.)

> 5.5.5.  ACP Security Profiles

The MTI for normal nodes is IPsec, but you make dTLS the MTI for constrained
devices. That doesn't guarantee interoperability. Or do you mean that
constrained nodes MUST support IPsec and dTLS?

>    Autonomic devices need to specify in documentation the set of secure
>    ACP mechanisms they suppport.

That's very nice but no use; autonomic nodes don't read each other's
documentation. What is useful is that a device announces the mechanisms
it supports to its peers, e.g. in a GRASP Flood message.

> 6.  Workarounds for Non-Autonomic Nodes

I guess we have to cover this. I would like it to start with a short
rant about how awful it is. But more realistically, we have to be
very clear that (a) the ACP will come up and run without any of this
and (b) the points that have to be configured will be singularities
in the AN - they won't recover spontaneously if broken, etc.

That's it for now.

   Brian