Re: [Int-dir] [Anima] An IOT DIR review of draft-ietf-anima-autonomic-control-plane

[Michael Richardson <[e-mail]>]

Thank you Pascal for for the review!

I don't think I want to respond to your specific comments, but rather
constrast some text to explain why (charter aside) we felt that we need
to leave out constrained networks.

The ACP is primarily about connecting network *service* equipment at an ISP
(or Enterprise) with the Network Operations Center for managemenet and
control.  Running SDN flows over the ACP makes a significant amount of sense.
Doing RESTconf over the ACP also makes sense.
Or just ssh in and type "conf term" and go, knowing you *can't* fat finger
something and lose your command channel.

The ACP is secondarily (today! we hope it will change) about connectivity
*among* this equipment such that the devices can interact at a meta-level.
The ACP is in some sense an "Internet of Routers", ... by routers and *for*
routers (and devices that contain switching functionality like hypervisors)

These devices otherwise do revenue generating activities like moving packets,
slicing and dicing video, running virtual machines, mining bitcoin, etc.

There is no fundamental reason why constrained networks of constrained
devices couldn't have an ACP, except for code size and energy consumption.
I.e. except for the thing that makes them constrained.

In a cabinet full of a physical hosts supporting some kind of virtualized
structure such as you might find at facebook, google, amazon, etc.  the
little bit of interaction between the Top-of-Rack switch, the service
processors (iDrac, iLO, etc.) of the systems, is significantly less than 1%
of the typical 10G+ that the cabinet probably has.
The ACP gives you a safe and secure place to bring in the sensors and
actuators in the cabinet (IP enabled power bars, etc.).  IPsec support in
a powerbar is not unknown.

To constrast this to battery-powered OpenMote scale devices.
The ACP overhead is probably 80% of the bandwidth of network.

You asked about why we have so many possible ACP technologies, but really
IPsec is the MTI.  That's partly because many are unfamiliar with IPsec and
are sure that some other "custom" solution would be better.  Grass is just
greener over there.

But in fact we actually have no other IETF standard solution that we can
actually point to.  "SSL VPN" is a marketing term, solutions are completely
vertically integrated: they don't interoperate at all.
OpenVPN an example of one, but it is a company/open-source-project, not an
RFC.   And also some would like to try MACSEC.

I think that we could get IPsec + IKEv2 (or some other similar technology)
into an OpenMote, but I'm not sure it's worthwhile, because at the end of
the day the ROI isn't that good if you eat 70% of the system doing this.

This brings me to your comments about how many parents to select and the
like.  While we don't have layer-2 ACKs in the IPsec hop-by-hop tunnels the
way that 15.4 does, but we do have IKEv2 dead-peer-detection messages.  We
will generally know quite quickly if we have lot a connection to a parent.
The occurance of an IKEv2 negotiation also provides a very strong signal of
that there is a new peer.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [







--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-