Subject: [Anima] Reference document

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 10 Jun 2015 12:14:24 +0000

Thanks for all the volunteers to help with the doc here. In fact, I’m having a bit of a hard time figuring out how to move forward, because there are several overlapping editing suggestions, and the document structure doesn’t take the latest discussions into account.

Here is what I’ve done now:

-          I worked all the open points into the outline of the document
(most of them from http://www.ietf.org/mail-archive/web/anima/current/msg01044.html )
I moved sections back and forth, trying to figure out the most logical structure.
The result is a completely new, but hopefully better structured outline.

-          Let’s agree on the outline first. Does this capture all the important points?

-          Then, based on the proposals, we look at who works out which section, to avoid overlap, and make sure we’re in sync. (I’ll propose something to get started).

Does this make sense?

If so, below is the new suggested outline. I think it’s more logically organised now:

-          Section 2 gives the high level view, as for example someone writing ASAs would need to know.

-          Section 3 is the architecture of a single node.

-          Section 4 is the ANI. So this is the “baseline” an AN node needs to support. I moved the ACP sections into this section now, because it’s base line really.

-          Section 5 describes security. I’ve been putting the sub-domain question eventually under this heading. We also need to describe the certificate format as well. I’ve also moved the MASA into this section, since it’s about trust at the end of the day. (Not 100% sure this is the best place).

-          Section 6 is about the ASAs. I’ve now taken out the registrar from the “nodes” section and moved it as a “must implement” ASA into the ASA section. Also the bootstrap functions really are ASAs, so they are in this section now. This way we keep the ANI “clean”.

-          Section 7 is about everything Management and Programmability. Intent belongs in here, the general description of how an AN network is managed, APIs, data models.

-          Sections 8 and 9 are unchanged from the last version. (apart from numbering)

-          And I marked the sections that are not directly addressed in the current charter, but which we should at least cover in principle here, with an (*).

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

   2.  The Network View  . . . . . . . . . . . . . . . . . . . . . .   3

   3.  The Autonomic Network Element . . . . . . . . . . . . . . . .   4

     3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   4

     3.2.  Unconstrained AN Nodes  . . . . . . . . . . . . . . . . .   5

     3.3.  Constrained AN Nodes (*)  . . . . . . . . . . . . . . . .   6

   4.  The Autonomic Networking Infrastructure . . . . . . . . . . .   6

     4.1.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . .   6

     4.2.  Addressing  . . . . . . . . . . . . . . . . . . . . . . .   6

     4.3.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   7

     4.4.  Signaling for Negotiation and Synchronization . . . . . .   8

    4.5.  Intent Distribution . . . . . . . . . . . . . . . . . . .   8

     4.6.  Routing . . . . . . . . . . . . . . . . . . . . . . . . .   8

     4.7.  The Autonomic Control Plane . . . . . . . . . . . . . . .   8

     4.8.  Reporting (*) . . . . . . . . . . . . . . . . . . . . . .   9

     4.9.  Feedback Loops (*)  . . . . . . . . . . . . . . . . . . .   9

   5.  Security and Trust Infrastructure . . . . . . . . . . . . . .   9

     5.1.  Public Key Infrastructure . . . . . . . . . . . . . . . .   9

     5.2.  Domain Certificate  . . . . . . . . . . . . . . . . . . .   9

     5.3.  Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . .  10

     5.4.  Cross-Domain Functionality (*)  . . . . . . . . . . . . .  10

     5.5.  The MASA (*)  . . . . . . . . . . . . . . . . . . . . . .  10

   6.  Autonomic Service Agents (ASA)  . . . . . . . . . . . . . . .  10

     6.1.  General Description of an ASA . . . . . . . . . . . . . .  10

     6.2.  Specific ASAs . . . . . . . . . . . . . . . . . . . . . .  10

       6.2.1.  The Enrolment ASA . . . . . . . . . . . . . . . . . .  10

       6.2.2.  The Enrolment Proxy ASA . . . . . . . . . . . . . . .  10

       6.2.3.  The Registrar ASA . . . . . . . . . . . . . . . . . .  11

   7.  Management and Programmability  . . . . . . . . . . . . . . .  11

     7.1.  How an AN Network Is Managed  . . . . . . . . . . . . . .  11

     7.2.  Intent (*)  . . . . . . . . . . . . . . . . . . . . . . .  11

     7.3.  APIs (*)  . . . . . . . . . . . . . . . . . . . . . . . .  11

     7.4.  Data Model (*)  . . . . . . . . . . . . . . . . . . . . .  11

   8.  Coordination Between Autonomic Functions (*)  . . . . . . . .  11

     8.1.  The Coordination Problem (*)  . . . . . . . . . . . . . .  11

     8.2.  A Coordination Functional Block (*) . . . . . . . . . . .  12

   9.  Hybrid Approach with Non-Autonomic Functions (*)  . . . . . .  13

   10. Security Considerations . . . . . . . . . . . . . . . . . . .  13

I have this in XML, will first ask the current co-authors for approval to publish this – I think it would be good to have the new outline as a new version available to all. If the co-authors are fine with this, I’ll publish (hopefully tomorrow).

Feedback? Moving in the right direction?

Michael

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 10 Jun 2015 16:16:35 +0000

Hi Michael.
The structure looks good.
Just a clarification: in Section 7, intent will be described in high level,
right? I am saying this because I think it is necessary a new I-D for the
intent description.
Cheers.
Jéferson

Em qua, 10 de jun de 2015 às 09:14, Michael Behringer (mbehring) <
[email-masked]> escreveu:

>  Thanks for all the volunteers to help with the doc here. In fact, I’m
> having a bit of a hard time figuring out how to move forward, because there
> are several overlapping editing suggestions, and the document structure
> doesn’t take the latest discussions into account.
>
>
>
> -          I worked all the open points into the *outline* of the document
> (most of them from
> http://www.ietf.org/mail-archive/web/anima/current/msg01044.html )
> *The result is a completely new, but hopefully better structured outline.*
>
> -          Then, based on the proposals, we look at who works out which
> section, to avoid overlap, and make sure we’re in sync. (I’ll propose
> something to get started).
>
>
>
> Does this make sense?
>
>
>
> -          Section 4 is the ANI. So this is the “baseline” an AN node
> needs to support. I moved the ACP sections into this section now, because
> it’s base line really.
>
> -          Section 5 describes security. I’ve been putting the sub-domain
> question eventually under this heading. We also need to describe the
> certificate format as well. I’ve also moved the MASA into this section,
> since it’s about trust at the end of the day. (Not 100% sure this is the
> best place).
>
> -          Section 6 is about the ASAs. I’ve now taken out the registrar
> from the “nodes” section and moved it as a “must implement” ASA into the
> ASA section. Also the bootstrap functions really are ASAs, so they are in
> this section now. This way we keep the ANI “clean”.
>
> -          Section 7 is about everything Management and Programmability.
> Intent belongs in here, the general description of how an AN network is
> managed, APIs, data models.
>
> -          And I marked the sections that are not directly addressed in
> the current charter, but which we should at least cover in principle here,
> with an (*).
>
>
>
> I have this in XML, will first ask the current co-authors for approval to
> publish this – I think it would be good to have the new outline as a new
> version available to all. If the co-authors are fine with this, I’ll
> publish (hopefully tomorrow).
>
>
>
>  _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 10 Jun 2015 16:22:14 +0000

From: Jéferson Campos Nobre [mailto:[email-masked]]
Sent: 10 June 2015 18:17
To: Michael Behringer (mbehring); Anima WG
Subject: Re: [Anima] Reference document

Hi Michael.
The structure looks good.
Just a clarification: in Section 7, intent will be described in high level, right? I am saying this because I think it is necessary a new I-D for the intent description.
Cheers.
Jéferson

Oh yes, for sure!! In fact most sections will just explain the concept, and point to the detailed documents. Like, signalling points to GDNP, the ACP points to the ACP draft, etc. What’s important to come out is that Intent is one way to influence the behaviour of an autonomic node. How this works needs to be shown, high level.

The overall goal is to show how all those drafts and work items fit together.

Michael

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 10 Jun 2015 16:41:17 +0000

Hi Michael.
Great, this what I had in mind, just want to make sure.
Cheers.
Jéferson

Em qua, 10 de jun de 2015 às 13:22, Michael Behringer (mbehring) <
[email-masked]> escreveu:

>  *From:* Jéferson Campos Nobre [mailto:[email-masked]]
> *Sent:* 10 June 2015 18:17
> *To:* Michael Behringer (mbehring); Anima WG
> *Subject:* Re: [Anima] Reference document
>
>
>
> Hi Michael.
>
> Just a clarification: in Section 7, intent will be described in high
> level, right? I am saying this because I think it is necessary a new I-D
> for the intent description.
>
> Cheers.
>
> Jéferson
>
> Oh yes, for sure!! In fact most sections will just explain the concept,
> and point to the detailed documents. Like, signalling points to GDNP, the
> ACP points to the ACP draft, etc. What’s important to come out is that
> Intent is one way to influence the behaviour of an autonomic node. How this
> works needs to be shown, high level.
>

---

From: John Strassner <[email-masked]>
Date: Fri, 12 Jun 2015 14:51:44 -0700

Sorry, forgot to respond. Feedback is MUCH BETTER. :-)

best regards,
John

-- 
regards,
John