Subject: [Anima] Adjacency table

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 7 Oct 2015 15:54:48 +0000

ANIMA WG,

In the latest version of the ACP draft, I was trying to be clearer on what triggers ACP creation. While thinking about this I came to the conclusion that practically all operations in ANIMA today are really focused around an adjacency table, which I now list in section 5.1 (precondition).

Also in the bootstrap design team call just now, same thing: What triggers a bootstrap action? And again, it's really anchored around the adjacency table.

Since this seems a pretty important concept (although quite simple, really), I wanted to illustrate how this all fits together in my mind:

There are processes feeding the adjacency table; there are processes triggered by it. Discovery feeds the table. But there are also potential other input vectors. Depending on the state of the device, and what it sees in the table, different things happen. And there we go into the bootstrap draft, the ACP draft, or potentially others.

I guess the reference model should explain this table, because it really links all the documents together, in a way. v

Does this make sense to everyone? Any things that don't seem right? Thoughts?

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Oct 2015 08:17:49 +1300

On 08/10/2015 04:54, Michael Behringer (mbehring) wrote:
> ANIMA WG,
> 
> In the latest version of the ACP draft, I was trying to be clearer on what triggers ACP creation. While thinking about this I
> came to the conclusion that practically all operations in ANIMA today are really focused around an adjacency table, which I now
> list in section 5.1 (precondition).
> 
> Also in the bootstrap design team call just now, same thing: What triggers a bootstrap action? And again, it’s really anchored
> around the adjacency table.

The adjacency table is also essential for correctly dealing with link-local
multicast, I think. The details are a bit messy to explain in a few words, but
in essence GRASP and the ACP have to ensure that some link-local multicasts are
*selectively* relayed between physical interfaces, and the information for doing
that is already present in Michael's table.

> There are processes feeding the adjacency table; there are processes triggered by it. Discovery feeds the table. But there are
> also potential other input vectors. Depending on the state of the device, and what it sees in the table, different things
> happen. And there we go into the bootstrap draft, the ACP draft, or potentially others.
> 
> Does this make sense to everyone? Any things that don’t seem right? Thoughts?

Can you clarify what you mean by discovery? I think this is distinct from GRASP
discovery, which is oriented towards individual objectives, so the GRASP protocol
engine will need a discovery cache, but that's distinct from the adjacency table.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 8 Oct 2015 07:45:23 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 07 October 2015 21:18
> To: Michael Behringer (mbehring) <[email-masked]>; Anima WG
> <[email-masked]>
> Subject: Re: [Anima] Adjacency table
> 
> > In the latest version of the ACP draft, I was trying to be clearer on
> > what triggers ACP creation. While thinking about this I came to the
> > conclusion that practically all operations in ANIMA today are really focused
> around an adjacency table, which I now list in section 5.1 (precondition).
> >
> > Also in the bootstrap design team call just now, same thing: What
> > triggers a bootstrap action? And again, it’s really anchored around the
> adjacency table.
> 
> multicast, I think. The details are a bit messy to explain in a few words, but in
> essence GRASP and the ACP have to ensure that some link-local multicasts
> are
> *selectively* relayed between physical interfaces, and the information for
> doing that is already present in Michael's table.

I think in Yokohama we should spend some time to discuss the multicast aspects. I sort of see where we're going, but wouldn't bet a lot that I'd be able to articulate it properly. 
 
> > Since this seems a pretty important concept (although quite simple,
> > really), I wanted to illustrate how this all fits together in my mind:
> >
> > There are processes feeding the adjacency table; there are processes
> > triggered by it. Discovery feeds the table. But there are also
> > potential other input vectors. Depending on the state of the device, and
> what it sees in the table, different things happen. And there we go into the
> bootstrap draft, the ACP draft, or potentially others.
> >
> > I guess the reference model should explain this table, because it
> > really links all the documents together, in a way. v
> >
> Can you clarify what you mean by discovery? I think this is distinct from
> GRASP discovery, which is oriented towards individual objectives, so the
> GRASP protocol engine will need a discovery cache, but that's distinct from
> the adjacency table.

Well, there is a reason this is a bit vague: I'm not really sure, and we need to sit down and discuss this. I think GRASP *could* be the basic discovery mechanism. But other proposals have been made (last IKE from mcr). 

Can you expand on why you think if we used GRASP for this purpose, this couldn't feed the adjacency table directly? 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Oct 2015 08:41:26 +1300

Below...

> Can you expand on why you think if we used GRASP for this purpose, this couldn't feed the adjacency table directly?

No, because in fact I think it could; I had been thinking that the ACP
was operating as a lower layer, but there's no reason it couldn't use
the GRASP upper layer for this. Just some API details to be fixed.

So, at that stage GRASP would be running in no-ACP mode, using sockets directly.
We could postulate a generic GRASP objective simply called "grasp" which all GRASP
instances must support. Then each node would send a link-local multicast on each
interface with a GRASP discovery message looking for the "grasp" objective.
Each link-local response message would indicate a GRASP neighbor. I think
those are the addresses needed to populate the adjacency table.

In terms of the CBOR version of GRASP that will be posted shortly, the discovery
message would look like this in CBOR diagnostic format:
 [1, 3141593, ["grasp", 0]]
and each response would be something like:
 [2, 3141593, h'fd0000000000000128ccdc4c97036781']

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 14 Oct 2015 16:01:45 +0000

During today’s bootstrapping design team we discussed the attached thread/image from the anima WG mailing list.

There are 4 points where this table interfaces with the bootstrapping documents as follows:

1) “AN discovery (cloud redirect)” is a possible reference to draft-ietf-anima-bootstrapping-keyinfra [draft-bootstrap]
 Section 3.1.4 discussion of “EST Redirect”. From discussion it appears the ‘redirect’ text is in the wrong place. It will occur during the s3.1.3 “request join” so some of the text needs to be moved to there. Additionally the protocol details section 5.1 needs some discussion of how the redirect occurs.

2) “Bootstrap that node” is a reference to providing proxy behavior as per [draft-bootstrap] section 3.2. [draft-bootstrap] says nothing about providing this service as a result of any the AN adjacency table state and it isn’t clear if there is something to reconcile here. Perhaps [draft-bootstrap] only supports bootstrap for nodes in the adjacency table that have been discovered w/o a domain or perhaps it provides bootstrap for any node. My personal preference is for the later as it doesn’t imply state but the design team discussion is not complete.

3) “I bootstrap” is a reference to a New Entity initiating bootstrap functionality. This is the start of the [draft-bootstrap] s3.1 state diagram and initiates the discovery functionality described in s3.1.1.

4) “Non-autonomic inputs” is a possible reference to [draft-bootstrap] s5.3 “basic configuration information package”. This is effectively only a placeholder w/in the current document and feedback is solicited.

I’ll be making changes as per (1) above as well as attempting to add a figure to s5 that provides a more detailed view of figure2 (see s3) that includes more protocol details.

Also discussed was to ensure bootstrap has an agenda point during the IETF94 proceedings.

- max

On Oct 7, 2015, at 9:54 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:

ANIMA WG,

Also in the bootstrap design team call just now, same thing: What triggers a bootstrap action? And again, it’s really anchored around the adjacency table.

Michael

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 14 Oct 2015 16:39:41 +0000

And here is the updated figure (not complete yet, need to think a bit more about some bits, especially the re-direct). I now also put in references to where the corresponding topic is discussed.

To me, this picture explains the big “how it all fits together”, which element feeds which other element. Again, the adjacency table is the pivotal piece at this stage, and it is really important that we drive to a common understanding here.

I’d really appreciate more discussion. For Yokohama I’ll prepare this slide in more detail, going through the life cycle of an autonomic device.

Michael

From: Max Pritikin (pritikin)
Sent: 14 October 2015 18:02
To: Anima WG <[email-masked]>; anima-bootstrap <[email-masked]>
Cc: Michael Behringer (mbehring) <[email-masked]>
Subject: bootstrap design team meeting notes Re: [Anima] Adjacency table

- max

ANIMA WG,

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Oct 2015 15:15:25 +1300

Hi Michael,

So, I'm thinking about how a GRASP implementation might use the adjacency table,
and I have some questions and comments.

1. What is the format and scope of the Node-ID? Is it just an arbitrary
value that has no global meaning, or is it more than that?

2. I would very much like the Interface ID to be the interface index
(a small integer, to be found in ipi6_ifindex in the Advanced Socket API).
There's no benefit and more work in having a name there.

3. Similarly, I would very much like the IP addresses to be binary. Again,
there's no benefit and more work in having them human-readable.

Regards,
   Brian

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Thu, 29 Oct 2015 02:54:24 +0000

>there's no benefit and more work in having them human-readable.

<JMC> I agree with Brian on this point that storing these values in index format and binary format will be the best method.
The implementations can take that information and display it in human-readable format as needed by design.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 31 Oct 2015 01:42:46 -0400

Brian E Carpenter <[email-masked]> wrote:
    > 2. I would very much like the Interface ID to be the interface index (a
    > small integer, to be found in ipi6_ifindex in the Advanced Socket API).

    > 3. Similarly, I would very much like the IP addresses to be
    > binary. Again, there's no benefit and more work in having them
    > human-readable.

These comments seem to suggest that what Michael presented is somehow how the
code works, rather than how the humans interpret the contents of the bits in
the table. 

I didn't read it as anything other than the human readable form of exactly
what you asked for...

-- 
Michael Richardson
-on the road-

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 1 Nov 2015 07:56:37 +1300

> I didn't read it as anything other than the human readable form of exactly

Sure. But when we briefly considered JSON for GRASP messages, I got very upset
by the inefficiency of always representing addresses in ASCII.

    Brian