Re: [Anima] Next steps for the reference document

[Jéferson Campos Nobre <[e-mail]>]

Inline

Em qui, 4 de jun de 2015 às 12:59, Michael Behringer (mbehring) <
[e-mail]> escreveu:

>  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. J
>
(Jéferson) I think it is also important to define/describe the management
interfaces supported by the ASAs and other ANIMA components.

>
>
> 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]
>
> 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]
>
> linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>
>
> address: Route de Villejust | 91620 Nozay | France
>  _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>