Subject: [Anima] draft-carpenter-anima-asa-guidelines discussion

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Apr 2018 13:00:13 +1200

More comments on the discussion at IETF 101:
 
> [Toerless] I think this work is highly useful, But we have to figure out the 
>    charter issue, because ASAs in general are not in current charter. It can 
>    become better and better the more experience we gain, thus as a chair I  
>    wouldn'tnecessarily want to have it finished as quickly as possible.

I understand that argument, and the document is far from finished.
But how can we encourage people (not just IETF people) to provide
the experience? I think we need open source implementations of the
ANI components ASAP.

...> [Alex Galis] 1) this draft is to better describe the border between service 
>    system right up vs. ASA right up; in other words, what are these and how to 
>    move from the described application towards service, that's the driving 
>    force. I don't think that this is a clear answer in you current system.

Again: we need experience, not theory, to clarify this.

>    2) NFV is coming in a big way, it's time to embrace the virtualization
>    significantly because that's where our autonomicity will be applied.
>    it's the time to embrace virtualization;

Remember though that ANIMA is a *management* mechanism. Certainly
it can manage virtual functions and components, just as easily as
physical devices. I don't see a problem of principle here at all.
The ASAs need the administrative privilege necessary to manage
the virtual components, that's all.
(The ACP itself is a virtual network, using VRF functionality.)

>    3) Autonomicity had big subject, it's time to decouple it autonomocity 
>    in terms of specific self-x capabilities for which ASA or other parts of the
>    Anima could be better applied. One framework for all, it's not going to be
>    easy to put in deployment in all the aspects, including the control plane
>    which was described recently. I'm afraid I'm not sure that this is 
>    deployable. But if that's not deployed, at least ASA applications could be
>    better deployed.

GRASP requires a secure substrate. It doesn't actually *require*
draft-ietf-anima-autonomic-control-plane; that's just the first exemplar
of a secure substrate. GRASP could be deployed tomorrow over any other
sort of secure substrate (or, heretically, with no security at all,
but I don't advocate that outside a hackathon). 

Alex, can you propose a simple alternative to the ACP?

     Brian