Subject: [Anima] Latest draft charter text of ANIMA

From: Sheng Jiang <[email-masked]>
Date: Mon, 18 Mar 2019 10:20:37 +0000

Hi, Anima,
Please find the latest draft charter text below. Actually, the chairs made all the draft writing open for all the time. Versions are shared in ANIMA wiki at the first time. You can access from datatracker-anima -> additional URLs -> Wiki -> 2019 Rechartering
This current version is a lightweight improvement from 01-03 (accessible from datatracker-anima -> charter), which is uploaded by our responsible AD Ignas in Feb 13th, 2019.
Regards,
Sheng
2.0.5 Draft charter (Sheng)
Proposed 2nd Charter for ANIMA Working Group
The Autonomic Networking Integrated Model and Approach (ANIMA) working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of networks that are developed, built and operated by professionals.
The vision is a network that configures, heals, optimizes and protects itself. The strategy is the incremental introduction of components to smoothly evolve existing and new networks accordingly.
ANIMA work will rely on the framework described in draft-ietf-anima-reference-model. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The three areas of the framework are (1) the Autonomic Networking Infrastructure (ANI), (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA) and (3) Intent.
The ANI is specified through prior ANIMA work. It is composed of the Autonomic Control Plane (ACP), Bootstrap over Secure Key Infrastructures (BRSKI) including Vouchers, and the Generic Autonomic Signaling Protocol (GRASP). ANIMA will work on closing gaps and extended ANI and its components.
ANIMA will start to define AFs to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management including coordination and dependency management.
ANIMA will not work on Intent or machine learning and other AI techniques without explicit rechartering.
ANIMA will coordinate with other IETF and IRTF groups. It will rely on NMRG to define the next steps for Intent.
Acceptance of work items by the WG will be scheduled/throttled so that contributors can target them to enter WG last call after not more than 4 IETF meeting cycles.
Proposed work items include but are not limited to:

  *   Works extending ANI, including variation of ANI deployment (e.g. in virtualization or compounding environment), information and signaling distribution within an AN, ANI OAMP interfaces (Operations, Administration, Management, Provisioning), e.g. YANG models, interaction with YANG-based mechanisms, defining the domain boundary and membership management of the domain, and etc.

  *   Works regarding to generic Autonomic Service Agents, including design and implementer guidelines for ASAs, life cycle management, authorization and coordination of ASA, and etc.

  *   BRSKI relevant works, including proxies, enrollment, adaptions over various network protocols, variations of voucher formats, and etc.

  *   Generic use cases of Autonomic Network and new GRASP extensions/options for them, including but not limited to bulk transfer, DNS-SD interworking, autonomic resource management,autonomic SLA assurance, autonomic multi-tenant management, autonomic network measurement, and etc.

  *   Integration with Network Operations Centers (NOCs), including autonomic discovery/connectivity to NOC, YANG-based ANI/ASA management by the NOC and reporting and reporting AF from node to NOC.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2019 12:57:14 -0400

Sheng Jiang <[email-masked]> wrote:
    > Please find the latest draft charter text below.. Actually, the chairs
    > made all the draft writing open for all the time. Versions are shared
    > in ANIMA

Thank you for posting this.
Some comments below.

    > The Autonomic Networking Integrated Model and Approach (ANIMA) working
    > group
    > develops and maintains specifications and documentation for interoperable
    > protocols and procedures for automated network management and control of
    > networks that are developed, built and operated by professionals.

    > The vision is a network that configures, heals, optimizes and protects
    > itself. The strategy is the incremental introduction of components to
    > smoothly evolve existing and new networks accordingly.

    > ANIMA work will rely on the framework described in
    > draft-ietf-anima-reference-model. Work not related to this framework is
    > welcome for review, but WG adoption of such work requires explicit
    > rechartering. The three areas of the framework are (1) the Autonomic
    > Networking Infrastructure (ANI), (2) Autonomic Functions (AF) built from
    > software modules called Autonomic Service Agents (ASA) and (3) Intent.

    > The ANI is specified through prior ANIMA work. It is composed of the
    > Autonomic Control Plane (ACP), Bootstrap over Secure Key Infrastructures
    > (BRSKI) including Vouchers, and the Generic Autonomic Signaling Protocol
    > (GRASP). ANIMA will work on closing gaps and extended ANI and its components.

    > ANIMA will start to define AFs to enable service automation in
    > networks; it will also work on generic aspects of ASA including design
    > guidelines and
    > lifecycle management including coordination and dependency management.

I think that this is a good set of goals, and I'd like to see AFs built,
but I'm not seeing them.  I am pleased to have a place in which to extend
BRSKI, but I feel that it's a *distraction* to the goal of getting the AFs
built.  I've said this before, and I'm prepared to be in the rough here.

What I'd ideally like to see is:

1) some place for enrollment work -- including BRSKI.

2) a way to finish and revise the ANI work.   This may need rather some
   kind of lightweight industrial forum to push interoperability testing
   leading to Updates to documents presently in the queue or already
   published.

3) a way to get AFs brought out.  Maybe an IRTF RG, maybe something else.

While not properly the business of the IETF, I don't think that (3)
can get much traction until there is a way to bring up a (virtual) ANI
on a bunch of VMs or cheap equipment in research labs.
Having ANI is like Web 1.0... the real value doesn't come until 2.0.

So one thought is, provided that (1) can be satisfied some other way,
is to suspend (not shutdown) ANIMA rather than recharter it.  I recognize
that such an action might have negative consequences to how various
people are able to participate.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 19 Mar 2019 01:05:32 +0000

In lines.

Sheng

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael Richardson
> I think that this is a good set of goals, and I'd like to see AFs built, but I'm not
> seeing them.  

This is in the scope. Whether the WG participants come up with good AFs, we will see. Actually, we saw some AFs came together with use cases. What we are not sure is the balance between specific AFs for narrow usage or generic AFs that can be reused in many scenarios.

> 1) some place for enrollment work -- including BRSKI.

It is already in the proposed work items: BRSKI relevant works, including proxies, "enrollment", adaptions over various network protocols, variations of voucher formats, and etc.

>    leading to Updates to documents presently in the queue or already

We believe this is covered. Maybe the word "Works extending ANI" needs be revised? Any suggestion?

> 3) a way to get AFs brought out.  Maybe an IRTF RG, maybe something else.

Generic ASAs that can be reused in multiple scenarios are already in the scope. We are not sure about the dedicated ASAs. They may come up with specific use cases. We need to discuss them case by case when we see them. How to arouse people to work on AFs/ASAs is another topic. It is out of the discussion of WG charter, I believe.

Sheng

> While not properly the business of the IETF, I don't think that (3) can get much
> traction until there is a way to bring up a (virtual) ANI on a bunch of VMs or cheap
> equipment in research labs.
> So one thought is, provided that (1) can be satisfied some other way, is to
> suspend (not shutdown) ANIMA rather than recharter it.  I recognize that such
> an action might have negative consequences to how various people are able to
> participate.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Mar 2019 19:20:01 +1300

Hi,

(FYI a direct link to the draft charter is:
 https://trac.ietf.org/trac/anima/wiki/Recharter2019 )

One in line comment...

> Generic ASAs that can be reused in multiple scenarios are already in the scope. We are not sure about the dedicated ASAs. They may come up with specific use cases. We need to discuss them case by c…

Well, many IETF WGs have attached implementation efforts (QUIC is a current
example). I agree that they are not IETF work officially, but it's often the
same people - working under open source rules, not IETF rules. That needs to
be discussed in a side meeting, perhaps (unfortunately I won't be in Prague,
so I can't help with that).

I will take the liberty of reminding people that there is already one 
open source platform for implementing demonstration ASAs and AFs. I'm a
little surprised there hasn't been more interest in it. It needs a secure
ACP, but nobody has given me one of those yet, so it runs insecure
apart from normal firewall protection.

https://github.com/becarpenter/graspy (start with the README and graspy.pdf)

    Brian

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