Re: [Anima] Next steps for the reference document

["Michael Behringer (mbehring)" <[e-mail]>]

inline...
From: Laurent Ciavaglia [mailto:[e-mail]]
Sent: 04 June 2015 16:56
To: Michael Behringer (mbehring); Anima WG
Subject: Re: [Anima] Next steps for the reference document

Hi Michael,

Thanks for rounding the todo / issue list.

I am ok to contribute on the intent and section 8 - "coordination / conflict resolution" (as per draft-behringer-anima-reference-model-01), and section 9 - "Hybrid Approach with Non-Autonomic Functions".
MB: Thanks for volunteering!
For "constrained" AN nodes, I think they are in scope, but what is the implication for the reference model document? Do we already have some inputs/requirements (e.g. from other WGs or sources) that could enlighten how / to which extent autonomic networks / their functionalities and mechanisms shall (or not) adapt (to such constrained nodes)?
MB: I think we need to work out what is the minimum "useful" autonomic node, and specify what the requirements for those are. Personally I do not think we want to make every smallest sensor fully autonomic. I see three classes:

1)      fully AN capable (what we describe today)

2)      constrained AN capable: This will be a node that for example can be an edge, can use AN functions, but doesn't participate in many functions, only has stub functionality.

3)      non AN capable (according to our definitions here): Those can still implement something "autonomic" in their own understanding of the world, but it may or may not work with what we're doing here.
We need to consider nodes in 1) and 2). For 3) I would argue we'd require some gateway between two different models. None of this is set in stone, it's just my current thinking.

I am not quite sure what you meant by the "management angle"... I assume you are talking about the management/operations of the whole system (as if deployed by e.g. a network operator). if correct, then I think some aspects of lifecycle / phases/ operations should be considered / written in the document. I can contribute to this but would prefer to start with some group discussions to see if we agree on the scope first.
MB: Yes, that's what I had in mind. Thanks for volunteering. :)

A tricky (missing) part might be the relationships among the various component. If judged useful (I think it is especially for ANIMA "outsiders"), it could be in the form of a diagram and/or linked to the (TBC) lifecycle section.
Of course, we shall not seek a ultimate, absolute reference diagram, but at least proposing one can help understanding, as you wrote: "show how all the various drafts, protocols, and discussions in the ANIMA WG fit together".
MB: Yes, we should have such a diagram. Or diagram(s).
Thanks Laurent!
Michael

Thanks, best regards, Laurent.

On 04/06/2015 15:18, Michael Behringer (mbehring) wrote:

Thanks for all who volunteered to participate in the reference doc. While detailed discussions may be between the contributors, the main technical discussions should probably take place on the main list. Here, I summarise my view on what needs to be done in the reference document.



If someone thinks he/she can produce text for the respective sections, please let me / the list know.



The overall goal is to show how all the various drafts, protocols, and discussions in the ANIMA WG fit together.



Points to address:



-       We should have a short section on intent. Explaining ingest of intent, distribution, the nature (on top of what's in RFC7575). That intent is signed, time stamps, etc. Probably pointing back to RFC7575. (Note intent distribution is handled in section 7.3)

-       Do we want to address "constrained" AN nodes, with limited capabilities, here? I think so... We'll need that for AN in constrained environments. This could go into a new section in section 3: "constrained network elements".

-       The masa section needs to be written. The masa will be an optional element. Needs to point to the bootstrap draft, which explains the basics.

-       Naming section needs meat. What names are used for, where it is in the domain cert.

-       Addressing section needs to bring in recent discussions. Needs to include how an ASA uses addressing. per node or per ASA. (I think we concluded per node).

-       Domain certificate template. We should write a section on the AN domain certificate. How the various fields are used.

-       Need to explain sub-domains

-       Section 9 needs to be worked out. This is all about conflict resolution. Maybe we should re-name that section? RFC 7575 already mentions this. Maybe we don't need much more here.

-       trust management: inside a domain, between domain and sub-domain, and between domains. This should become a new section.

-       Need to treat the question of the "out of band" ACP versus the inline ACP. The two models both work, but there are implications, different benefits, drawbacks, etc. This needs to be explained.

-       Routing: In the case of a virtually separate ACP, as in draft-behringer-anima-autonomic-control-plane, we need to also define a routing protocol (thinking of the discussion in homenet, this might be "fun"...)

-       Need considerations for APIs: How can ASAs use the ANI?

-       Need considerations for a data model. What it should cover, scope.

-       We should also describe the management angle

-       Security considerations need to be expanded. Threat analysis needs work; need general security considerations, talk about the PKI and trust model, etc.



Thoughts? Anything missing? Any volunteer for a specific part?



Michael



_______________________________________________

Anima mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/anima





--

Bien cordialement, Best regards,

Laurent Ciavaglia
Secure Cloud Networking
Bell Labs | Alcatel Lucent

phone: [phone]
email: [e-mail]<mailto:[e-mail]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 Nozay | France