Subject: [Anima] Discuss: acp "simplifications"

From: Toerless Eckert <[email-masked]>
Date: Sun, 16 Aug 2015 01:44:38 -0700

So, we've come some way wrt. whether ACP should be optional or not for an
autonomic device, and i think we have more people chime in on ACP being non-optional,
and the only question was about the minimum complexity required for an AN device.

One way to think about simplification is to think about the "Data-plane(s)" to be
optional!

Aka: Think of some future target "lightweight" autonomic devices mean to be deployed
in some IoT environment with ONLY sensors/actors, and all the intelligence required
to serve these actors/sensors is in ASAs - communicating with each other via GARP
and maybe on the edge to the actor/sensors also via other protocols (legacy). So,
what's the ACP for ?  Well, all the stuff we defined:

- zero touch:
  - key infra.
  - routing for IPv6 unicast.
  - end-to-end security via hop-by-hop encryption.
  - ASA to ASA objective discovery / utilization
  - ASA  (not in charter yet)

This is all perfectly beneficial/necessary even for that future.

So, but whats a data-plane for ? IMHO, the data-plane is really only the
"legacy-network" that i want to configure/manage. But if i build out a new
network autonomously only, why would i need it ?

IMHO, i would not need it.

Aka: I could have lightweight AN-FOOBAR devices that have ASAs for FOOBAR
(eg: lighting, manufacturing, ... ), they ONLY have ACP, and i can ONLY
connect FOOBAR clients to them. I connect those AN-FOOBAR devices
to AN-IT devices, where "IT" means they have all this existing "data-plane" stuff,
and e voila ( ;-) ), it will work nicely together. When i use the ACP
in my "stable-connectivity" approach to set up the (data-plane(s)), i would
only be able to do that on the AN-IT devices, because, well, the AN-FOOBAR
devices don't have a data-plane. And of course, i could always choose to build
AN-IT-FOOBAR, meaning i also run the FOOBAR ASAs on an AN-IT device. And only
"IT" ASAs should dare to require communicating with each other over a data-plane,
becuase in lightweight AN devices, there is no data-plane.

So, i propose wrt to anima design, Data-Plane is optional, and required by
what we describe in "stable connectivity" .

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Aug 2015 17:13:33 +1200

Hi Toerless,

Comment at the end:

> what we describe in "stable connectivity" .

I don't think we even need to say even that much. I think we can simply
say that it's an ASA's own business how it communicates with the devices
that it manages, and how they communicate with each other. In traditional
networks it will be a traditional data plane (and the "stable connectivity"
use case fits there).

I think I'm agreeing with you but also suggesting that we say as little as
possible.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 17 Aug 2015 05:02:31 -0700

> I think I'm agreeing with you but also suggesting that we say as little as

Well, with ONLY drafts like "stable connectivity" and "addressing", both of which 
focus on the "IT" case i think we do not have a simple pitch of how to best apply
autonomic design for greenfield designs, especially in IoT. Maybe a use-case draft
would be right place to highlight the "no data plane needed" option ?

As i said in my mail to Hannes, maybe we
have a bit more breathing room to do such drafts with a) showing progress
on charter items, b) explicit asks from other WGs for such use-case drafts
to better understand how they could reuse anima charter items.

Cheers
  Toerless