Subject: [Anima] Notes from the reference doc meeting

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 23 Jul 2015 16:58:07 +0000

Earlier today, the authors of the reference doc met and discussed the reference model. Notes below. 

Michael

---

Reference Model Discussion
22 Jul 2015

Attendees: Sheng, John, Jason, Bing, Jeferson, Toerless, Michael (notes)

*** Design team
Sheng suggested to define a formal design team, even though it is strictly not necessary. This way we can define a charter, and a more formal structure. He is fine with almost all of the text in the current document, but need to adhere to the charter. 
Sheng: The charter proposed by Michael yesterday is too simple. Need AD approval. 
Michael: In this case I prefer not to have a design team, but to do it informally. 
Sheng: This is fine. 

*** Scope of document
Sheng guidance: 
- document must focus on the current charter items. 
- (current) non-charter items (marked with (*)) should be reduced to just some high level overview, no details. 
- may move to separate docs for now. 
- if the chairs have a concern, that should be raised immediately.

*** Constrained nodes
- Michael: Idea: we should always consider constrained nodes as well, this may impact our current design decisions. We don't want to miss an opportunity to use our approach on less capable devices (to be defined what that means). 
- Sheng: Pascal Thubert (6tisch co-chair) stated that if ANIMA approaches (bootstrap) work for 6lo devices, he would use our approach. 
- how to define constrained?. Need more help from people with expertise in this field. ACE has some definitions. RFC7228 defines terms. To be reviewed - is that usefult for ANIMA? Where would we expect ANIMA functions? 
- must define now to not miss opportunities to adapt our protocols to constrained devices. 
- Sheng: example: Intent may be different for constrained devices. 

*** Naming: 
Sheng guidance: we can specify a general naming concept. But we can't define a semantic for names. So the current text is an example. Specifically we can not define requirements on how to structure names. 
- Bing: Also need to define requirements. 
- Michael: Need to explain USAGE of names: Why we need them, and how we use them. Also need to define what we use as a node id. The choice of identifier will affect all other decisions later on. Important! 
- Michael: We should have a separate section in the reference doc on what we use as node identifier. 
- John: Canonical structure of names cannot be pre-defined. Should be taken out. How nodes are named is outside scope. 

*** Addressing: 
Sheng guidance: 
- Addressing schemas should move into a separate document again, but must be linked to the ACP. So this is part of that work item. The title of the doc should ideally contain "acp". 
- addressing requirements and high level concepts remain in reference doc.
- addresses are for nodes, not ASAs. (consensus?)
- addressing must happen autonomically. 

*** Meaning of ACP
The ACP is the context in which autonomic infrastructure works. 
- can be separate context
- can be data plane based. 
Do we agree on that? Yes. 
- John: Need to enumerate the advantages and disadvantages of both approaches. 

Corollary: 
- addressing discussion is for "ACP"
  + but this could be the data plane based ACP or in the virtually separated ACP. 

- Potential Definition (to be discussed): the autonomic address is the foundation for the ACP. So if a protocol uses the autonomic address space, that *is* the ACP. Then there are two implementation choices: Virtually separate and data plane. 

- Sheng: ACP draft doesn't define the ACP - needs to be done. 
- Michael: Following this addressing discussion, maybe the addressing text SHOULD go into the ACP draft. (general agreement - to be seen)
- Sheng: But in this case, need an update before we go for WG adoption call. 
- Michael: Will suggest next week whether I suggest we keep addressing separate from ACP draft or put it in (need to think about it, look at doc, etc). 
- Toerless: need to consider if the NOC should get autonomic addressing. If separate address space for NOC, and if data plane model for ACP, then the selection on what goes through the tunnels becomes harder. Then it would be advantageous to have the NOC devices use the autonomic address space. Suggestion: Take the data plane ACP into an appendix, with the note that there are specific challenges. 

*** Intent (see also SUPA)
- What is different between SUPA and our Intent (Sheng's comment on the mic yesterday in SUPA).   
- Sheng: First, Intent is not on the charter yet. Second, some other working group could define the concept of intent. In that case we should use what they define. If nobody else does it, ANIMA does it.   
- Sheng: in the ref model, no need to define what Intent will do in detail. 
- Toerless: Need to make clear that ASAs will use Intent. That we can use GRASP to carry Intent. Is the logic of distributing Intent the job of an ASA? 
- Need to also describe a interpretation function. 
- is the requirement to flood? different distribution model needed? 
- The logic on how to distribute Intent is the function of an ASA. The mechanics (GRASP etc) is part of the ANI. 
--> Add another "specific ASA" in the ref doc for the Intent distribution. 
- scope of intent: Declarative, will not allow all knobs. 
- Michael: Worried that Intent allows you to set all possible parameters; should restrict to high level policy only. Need to keep some oversight. 
- Michael: What if we explain that we expect Intent to be flooded. That implies that it can't grow indefinitely, and that it should be limited to the strictly required. This explanation can be used to explain to other groups that Intent should be small. 
- John: Reasonable.   
- Sheng: We need to be specific that we're talking about "ANIMA Intent". 
- Bing: Point out that ANIMA Intent is for network devices, not higher level devices such as controllers. 
- Toerless/John: What if we have a policy  for 50k users, belonging to 5 user profiles. Is that Intent? 
  Users should be on AAA server, Intent should define how profiles are used. Or Intent could define profiles. (to be discussed more). 
- Other example: 10k enterprise VPNs: Again, the service descriptions might be, the instantiation for a particular customer is not. 
  
*** Hybrid approach
- Bing: Didn't find text any more about the hybrid approach any more? Should be in. To be checked. 
- How do we define autonomic node? --> If it has an autonomic address? (tbd)

*** How it all fits together.  (draft structure). 
- see also sequence in ACP draft. 

- start with assumptions. 

1. Discovery
- Nodes discover each other. 
- Sample protocol: GRASP (not using autonomic addressing if one node is not in the domain)

2. Mutual Authentication 
- Nodes authenticate each other
- which protocol to use? 
- using domain certificate, if they have one, or 802.1ar cert, or unique device identifier (UDI)

3. If a pair of nodes authenticate each other to be part of the same domain
- next step: establish ACP
- else: invoke bootstrap process

4. Establish ACP
- GRASP: negotiate tunnel type / ACP type. 
- security association between nodes used for autonomic interactions
- 2 options: can be virtually separated or data plane
- provides security
- provides separation
- if separate model: start routing

5. Launch / Instantiate ASAs
  + bootstrap proxy ASA
  + intent distribution ASA
  + ... others ...

5. Intent distribution
- inside the ACP, so only with trusted nodes. 
- GRASP can be used for flooding.
- new nodes cannot receive the "raw" Intent. 

6. Service discovery
- GRASP

... and so on. 

- Sheng: Send this text around the WG to get feedback before putting into draft. 

Action Itemes: 
- Everybody to adapt his section(s) according to the above discussion.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2015 16:35:32 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > - how to define constrained?. Need more help from people with expertise
    > in this field. ACE has some definitions. RFC7228 defines terms. To be
    > reviewed - is that usefult for ANIMA? Where would we expect ANIMA
    > functions?

7228 defines Class 0 and class 1 nodes.  Class 0 is really too small, and
anyway, given that Raspberry PI class devices (0.5G ram, 2-4G flash, full
Linux stack) are now approaching $10 as BOM, and OpenWRT class devices (4-64M
ram, 16-64M flash) are selling *retail* for $15...  the major constraint is
energy, not ram or compute.
(Note 7228 needs to be revised to create some class 2/3/4 devices for above)
Some of the high-end router control planes CPUs are starting to look
"constrained" in comparison :-)

Then 7228 defines challenged *networks*, and I would say that an energy
related thing about the challenge of challenged networks is that they few
TxOps: sometimes as low as 10 packets per second.

So focus on network constraints, and assume that code space is not initially
a constraint, but think about things that can be optional.

    > - Sheng: example: Intent may be different for constrained devices.

I'd say that Intent may be too rich a concept for Constrained devices to
*interpret*, but that they may be able to express an Intent from a
description compiled in.

    > - can be data plane based.

The dataplane-ACP as described in the current document in too terse to reason
about.  The slide/picture from Monday had 10x the info, and yet is still too
terse.

Fundamentally this is how I understand it: if you do not create an overlay
for the ACP, then it means that one is passing GRASP/etc. messages across the
link-layer, and therefore any forwarding that happens is happening at the
application layer.  If this is what people want, then say so.

I asked during today's session:

  should "form ACP"  be an Intent, or is it implicit?  Is "connect ACP to NOC
  at address BLAH" an Intent?

    > - Potential Definition (to be discussed): the autonomic address is the
    > foundation for the ACP. So if a protocol uses the autonomic address
    > space, that *is* the ACP. Then there are two implementation choices:
    > Virtually separate and data plane.

I still don't understand.

    > - Sheng: First, Intent is not on the charter yet. Second, some other
    > working group could define the concept of intent. In that case we
    > should use what they define. If nobody else does it, ANIMA does it.

I started watching the SUPA BOF, but haven't finished.

    > - Michael: What if we explain that we expect Intent to be flooded. That
    > implies that it can't grow indefinitely, and that it should be limited
    > to the strictly required. This explanation can be used to explain to
    > other groups that Intent should be small.

What if, within the ACP, a node says (floods) something like:
     "I'm a <FLAVOUR> ASA, and I'm trying to enact <INTENT>.
     Join me at <MULTICAST> address, if you can Help."

(with allusions to Darth Vader, episode V)

    > - GRASP

I think that there is too many new protocols imagined here.
1) Discovery: one of: mDNS, ND, DHCPv6 DISCOVERY.
2) Mutual Authentication: IKEv2.
3) bootstrap process: can be EAP-over-IKEv2, could instead be NETCONF(HTTP) over
             prospective ACP.
4) Establish ACP.  IPv6(proto 41)-over-transport-mode-IPsec.
             (looks a lot like tunnel mode, but the SPD is different)
   Run Routing protocol (RPL, can argue here)
   Run MPL over ACP if we want multicast for 5.
5) ASAs need to be defined, there is where GRASP comes in.
5b) not sure why new nodes can not receive raw Intent. Seems to be
    assumption of GRASP-level multicast, which is fine.

Constrained nodes will already have:
  1) ND, possibly some DHCPv6 client code.
  2) IKEv2 is new for constrained nodes; but perhaps in the 6tisch and other
     situations, we can build the ACP using a seperate DODAG and/or a
     different ESSID/PANID.  Note that we can also considering using HIP
     rather than IKEv2, and it might be that HIPDEX is already present in
     constrained nodes for use by MLE/ZigbeeIP.
  3) EAP-over-IKEv2 implies EAP-TLS + EST really.  That's a lot of code.
     That's why I prefer to use raw DTLS/COAP or HTTPS over a prospective ACP.
  4) constrained nodes already have RPL, and may have MPL already too.
     IPsec code could be traded for new ESSID/PANID.
  5) Constrained nodes might express Intents ("give me"), but I don't think
     will run ASAs.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Jul 2015 06:50:20 +1200

On 24/07/2015 08:35, Michael Richardson wrote:

<snip>

> *interpret*, but that they may be able to express an Intent from a

I'm not convinced. If Intent is delivered in bite-sized pieces, I think
a low-end device should be able to interpret it. For that matter, even if
the relevant Intent is embedded in a much longer global Intent, discarding
irrelevant Intent shouldn't be that hard.

(However, I'm assuming that the device is already capable of handling the
bootstrap mechanism and the ANI components; if we do it right, that will
already provide most of the run-time support for Intent acquisition).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Jul 2015 06:58:23 +1200

Another <snip>

> application layer.  If this is what people want, then say so.

No. If there's no ACP, GRASP will use whatever layer 3 addresses are
returned by GRASP discovery; if they are off-link, regular routers will
forward the packets. My expectation is that this will all be TLS (except for
insecure multicast for discovery messages). But I'd regard this as a poor
solution compared to having a secure ACP overlay.

The GRASP protocol engine itself will forward discovery messages, and that
will be link-local.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2015 18:13:32 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> I'd say that Intent may be too rich a concept for Constrained devices
    >> to *interpret*, but that they may be able to express an Intent from a
    >> description compiled in.

    > a low-end device should be able to interpret it. For that matter, even
    > if the relevant Intent is embedded in a much longer global Intent,
    > discarding irrelevant Intent shouldn't be that hard.

Perhaps you are right, if the structure of the Intent is easily decomposible,
but I'm not sure that the device will even be able to deal with bite-sizes
pieces.  I think that this would be a very nice property for Intents.
(I still haven't watched the SUPA BOF video yet...)

My take is that constrained devices (and the challenged networks that connect
them) will be involved in the ACP and with Intent distribution system only
because the constrained networks, being wireless, and naturally mesh will
connect things up first.

I think I gave the example of two high-end routers that would find themselves
connected if only they agreed on the right set of lambdas (frequencies), and
maybe told the optical switch in between of their desire to be connected.
The ACP would flow (poorly) across the challenged network to get that part
done, and that's all.. Then the light bulbs go back to being (just) light bulbs,
and the only "Intent" they know about has to do with illumination.
(Queue: HHGG' Sirius Cybernetics Door personality)

    > (However, I'm assuming that the device is already capable of handling
    > the bootstrap mechanism and the ANI components; if we do it right, that
    > will already provide most of the run-time support for Intent
    > acquisition).

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2015 18:16:21 -0400

>> Fundamentally this is how I understand it: if you do not create an
    >> overlay for the ACP, then it means that one is passing
    >> GRASP/etc. messages across the link-layer, and therefore any
    >> forwarding that happens is happening at the application layer.  If
    >> this is what people want, then say so.

    > forward the packets. My expectation is that this will all be TLS

Well, I am assuming a situation where there are no non-link layer addresses,
because they haven't been distributed yet, and there is no routing, because
GRASP hasn't distributed the Intent that tells everyone what routing protocol
to speak...

Of course, once the system is up, GRASP should use whatever addresses are
available, and I really like the idea of MPTCP being able to offload the
ACP...

    > The GRASP protocol engine itself will forward discovery messages, and
    > that will be link-local.

okay: so what I hear you saying is that GRASP will include application layer
multicasting, and that we will not require the ACP to provide a multicasting
service.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Jul 2015 18:43:12 +1200

> multicasting, and that we will not require the ACP to provide a multicasting

That's the current design.
https://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-04#page-17

    Brian