Subject: [Anima] Review of draft-ietf-anima-autonomic-control-plane-04

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Nov 2016 17:32:26 +1300

Hi,

This is not an exhaustive review, because I've mainly focussed on the aspects
that concern me most as co-author of the GRASP draft. But in general, I like
this document and what it proposes.

> Abstract
> 
>    Autonomic functions need a control plane to communicate, which
>    depends on some addressing and routing. 

I think this should say "a secure control plane" because security is
an absolute requirement.

Similarly:

> 1.  Introduction
...
>    Autonomic functions need a stable and robust infrastructure to
>    communicate on.

I suggest

   Autonomic functions need a secure, stable and robust infrastructure to
   communicate on.

> 5.1.2.  AN Adjacency Table
> 
>    To know to which nodes to establish an ACP channel, every autonomic
>    node maintains an adjacency table.  The adjacency table contains
>    information about adjacent autonomic nodes, at a minimum: node-ID, IP
>    address, domain, certificate.  An autonomic device MUST maintain this
>    adjacency table up to date.  This table is used to determine to which
>    neighbor an ACP connection is established.

I'm pretty sure it should be "neighbors" (plural) in the last line. If not,
I have misunderstood something.

> 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 ...

This is troubling. Hopefully it's just terminology, but there may be something
deeper.

An L2 switch that is AN capable is more or less a contradiction in terms.
(I'm old fashioned, and I think of an L2 device with many physical ports
as a bridge, that knows nothing about anything except MAC addresses.) So I
assume you mean "A device that combines L2 bridging with L3 routing
capability and has enough resource to run the ANI components." If so,
I think you should say so.

An important issue linked to this is MLD snooping. You're going to also
require that *if* the device performs MLD snooping it treats the GRASP
LL multicast address as a special case, when and only when it is operating
in the way you describe in this section. If not, it will treat MLD joins
from GRASP nodes as an instruction to be transparent to such multicasts,
which is exactly what you are trying to stop. An L2 device that is *not*
acting as you describe MUST be transparent to GRASP multicasts.

> 5.2.3.  Discovery with GRASP

One question is whether the best model is Discover or Flood.
The Discover model means that a newcomer will find all neighboring
ACP nodes individually. The Flood model means that it will announce
itself to all such nodes. Either will work, I think. I have no
strong opinion.

I would prefer to name the objective "AN_ACP" (and to use the
same convention for all infrastructure objectives). That's a
detail of course.

I can do some more work on the objective, such as implementing a toy
version, if there's general agreement. (Also see comments below on 5.5.4.)

> 5.2.4.  Discovery and BRSKY

s/BRSKY/BRSKI/
Also needs a reference to draft-ietf-anima-bootstrapping-keyinfra

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

I already commented to Michael that we really don't need the "6" prefix
(especially after the recent IAB statement). Also, it's unclear to me
whether a registrar and a proxy will announce themselves in exactly the
same way. Is the pledge supposed to know any difference? In any case,
the proxy will only be announced or discovered on-link, whereas the
registrar will be announced or discovered across the whole AN.

I had assumed we'd need separate objectives "AN_registrar" and
"AN_proxy". If we can manage with just one, that's fine.

The choice whether we use GRASP Discover/Synchronize, Discover/Negotiate
or Flood is also open. I think any of them could work. At the cost of
repeating myself, I feel strongly that one of these MUST be supported
for autonomic nodes, quite independent of using mDNS for non-autonmic
nodes.

That's all a bit out of scope for the ACP draft, however. But next:

> 5.5.4.  GRASP/TLS negotiation

I'm perhaps a bit confused. Firstly, GRASP is supposed to use TLS automatically
when there's no ACP (and there are certificates). So that's OK.

Let's say (skipping some syntactic sugar):

1. Bob issues grasp.discover(["AN_ACP"])
2. One of the replies is from Alice.
3. Bob issues grasp.negotiate(["AN_ACP", [0,7]) to Alice, meaning he wants either channel type 0 or 7.
4. Alice replies grasp.negotiate(["AN_ACP", [0]), meaning she offers only type 0.
5. Bob replies grasp.end_negotiate(True) meaning he accepts.

Is that what you want?

>    The GRASP/TLS connection can be kept
>    alive or timed out as long as the seelected channel protocol has a
>    secure association between Alice and Bob.

Why is that useful?

> 5.6.  GRASP instance details

I think it's in this section that you should state which network
interfaces GRASP will use in each case.

> 5.7.  Context Separation

I've been looking around for a document that actually explains VRFs in
more than one line of text. I suspect it's a term of art whose meaning varies,
but I didn't find an RFC that helps.

> 6.2.  ACP through Non-Autonomic L3 Clouds
...
>    One workaround is to manually configure IP tunnels between autonomic
>    nodes across a non-autonomic Layer-3 cloud.

Is that really "manually"? I think it could be automatic via some sort
of rendezvous server. We don't really want the word "manually" in Anima ;-).

Regards
   Brian