Subject: [Anima] Notes from the ANIMA call today

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 4 Sep 2014 15:32:30 +0000

Here is the recording: 
https://cisco.webex.com/ciscosales/lsr.php?RCID=2d44676cde11469b9639c879771a8e3f

And below are the notes, thanks Toerless for taking them! 

Michael

---

Participants
  Michael Behringer
  Bing Liu
  Dan Romascanu
  Dean
  Dimitri P.
  Guy Meador
  Laurent Ciavaglia
  Rene Struik
  Sheng Jiang
  Yu Fu

Call #4. Target to stabilize the draft charter #8 published from last weeks meeting.

August 26/29 updated NMRG drafts: Definition and gap analysis.
Asked for last call on both drafts in NMRG.

Rene Struik: Need to be more clear what charter goal is:
 Autonomic Networking vs. stripping down #competing protocols.

Rene Struik: seems it is premature to go for adoption of the three documents in the charter. It is unclear what philosophy is behind the protocols.
Shen: These protocols are just meant to be starting points. WG is to start working on these problm areas. First adoption calls will be November.
Still time make documents more mature.
Rene Struik: But charter says "adoption of drafts". Fear these will be point solutions to unclear problems.

Michael: Goal is to come up with common infrastructure for the problems in scope. Does not mean we have to build new protocols, can also take existing ones.

Rene Struik: Wrt to negotiation protocol. I think about IoT applications, and the current proposal seems badly applicable. Maybe discussing the philosophy of the protocols should be one of the first goal of the charter.

Laurent: Why do we need to list these documents in the charter ?
Michael: leaving them out would make the charter even less clear.
Rene: Usually do not see references to drafts in other charter. Should there not simply be just topics that should be discussed in the charter instead ?  Dan Romascanu: Agreed with Laurent. 
Sheng Jiang: Agreed.

Laurent: Common infrastructure question. Where/how do we see the role of autonomic in it. SHould the protocols control atonomic functions, or be autonomic themselves. Question 2: Internet deployment or design principles to improve future protocols with autonomic philosophy applied to other groups protocols.

Michael: Please propose text on the anima working group to improve charter text. Wrt to NMRG drat comments

Discussion about mentioning of area director responsiblity in charter.
Michael: AD responsible to approve future charter changes. Negotiate with AD to work in a controlled way through the number of use cases to solve. REne: maybe this is a note that should be removed after finalization.

Discussio about how many use cases beyond those solved by the infrastructure we should ave. Conclusion was one.

Dimitri: Why do we need to build protocols to solve use-cases.
Value is not based on added value of synchronizing agents better than today. Other bodies who have tried to tackle this problem have also tried to build an infrastructure first and then focus on use cases.

PCE was a very good example. The overall use-case is the proof point tht helpe shape the 4 year work for those protocols.

Michael: current tentative use-case is IPv6 prefix management.
Dimitri: fears this is not generic enough ?! Need to wy to show flexiblity of agent model.

Laurent: Can we show in one single use case example how to reuse the common infraastructure ? What we should focus on in the demonstation use case, that we can check over multiple use-cases, we can solve each of them with the common component.

How to write the charter: Laurent: leave more headroom to the WG to decide what it will deliver.

Dimitiri: Success in functionality in use-cases. Sucess in design based on reuseability. Both can/should be in charter. But protocols are third step.

Sheng: The negotiation protocol wold be an aspect of reuseable design.

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 5 Sep 2014 23:57:36 +0000

Different opinions on how to bring this work forward have been expressed on this list over last 2 to 3 weeks.   

The fundamental discussion point can be summarized as follows: some consider the traditional protocol-driven approach of the IETF others due to the very nature of AN consider that proper design requires to start from functional areas/use cases, leading in turn to different charter proposals.

Following the latter, I have made that exercise as follow-up of the discussion held during the call of Sep.4: 

Current network processes perform independently on different views/partial information and by different means while interactions among their constituting entities take place at different spatial scales (from local to global). These processes also operate in the dark as the information to which they get access to/store is mostly limited to the one translating local protocol state(s) at current time. Finally, these processes have been designed to realize specific objectives which are often difficult to combine and reconcile preventing in turn the realization of more complex tasks (and involving multiple processes). Nowadays, the only mean to compensate these limits is to involve manual intervention/off-line control.  

This motivates the introduction of a control paradigm where network processes, driven by objectives (or intent), coordinate their local decisions, autonomously translate them into local actions, and adapt them according to external information and protocol information bases. This paradigm is referred to an autonomic networking.

Numerous realizations of this paradigm are possible. One of its simplest forms has been documented in [nmrg] where an information processing agent (IPA) is collocated with the set of protocol engines it drives. An IPA processes the input selected from external information sources and protocol information bases in cooperation with other IPAs, to derive states (information needed to make a decision now or in the future) and translate them into local actions (i.e. local policies). 

Application of this paradigm comprises use cases ranging from configuration to protection (security). For instance, considering the case of anomaly/attack/intrusion detection and related re-configuration operations i) automation is motivated because automata/programs are more proficient than humans in realizing systematic and exhaustive tasks such as ACL (re-configuration), ii) adaptation is required as new anomalies and attacks are constantly detected, and iii) cooperation and autonomy as each identified event requires both coordination and translation into different local actions to counter it.

Challenges:
----------

1. As use cases are numerous and diverse, the following question stems: can inter-agent protocol primitives be unified and can agent functionality be factorized. 

2. Different "cooperation modes" between IPA's can be considered from slave-master-slave to consensus; hence, the following question stems: would one cooperation mode fit all needs.

3. Finally, the information source selection and orchestration of actions (sequencing of instructions to protocol engines) requires to specify appropriate pre- and post-processing as these agents are required to be self-sufficient. 

Tasks:
-----

Step 0: Functional areas where the working group agrees to contribute (risk mitigation/avoidance, re-configuration/-programming, etc.) by providing at least one use case per functional area.

Step 1: Evaluation work on resulting use cases, document input, output, AN function, and distributivity needs (exchange of information from external sources, exchange with other AN agents, orchestrate execution/realization of decisions, etc.) and cooperation modes.

-> Goal: show the functional "utility" of AN and provide incentives for the design of the ACP

Step 2: AN control functional specification (in particular, cross-function single AN vs. cross-element multi AN) following the design goals of factorization, distribution, and unification and determine if protocol functionality already "available" in other/existing protocol (with/without extensions) or new protocol that could be needed.

-> Goal show the utility and feasibility of a "common AN infrastructure" 

Step 3: Depending on the outcome of step 2, extensions of existing protocols, new protocol design, etc. can be considered.
 
Milestones:
----------

X 2015 - WG formation and adoption of initial drafts
X 2015 + 12m - Uses cases evaluation and analysis - what did we learn ?
X 2015 + 18m - Functional specification - what do we miss (in terms of protocols) ?
X 2015 + 30m - Protocol specification(s) 
X 2015 + 36m - ACP architecture (informational)

Thanks,
-dimitri.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer
> (mbehring)
> Sent: Thursday, September 04, 2014 5:33 PM
> To: [email-masked]
> Subject: [Anima] Notes from the ANIMA call today
> 
> Here is the recording:
> Rene Struik: seems it is premature to go for adoption of the three
> documents in the charter. It is unclear what philosophy is behind the
> protocols.
> Shen: These protocols are just meant to be starting points. WG is to start
> working on these problm areas. First adoption calls will be November.
> Michael: Goal is to come up with common infrastructure for the problems in
> scope. Does not mean we have to build new protocols, can also take
> existing ones.
> 
> Rene Struik: Wrt to negotiation protocol. I think about IoT applications,
> and the current proposal seems badly applicable. Maybe discussing the
> philosophy of the protocols should be one of the first goal of the
> charter.
> 
> Rene: Usually do not see references to drafts in other charter. Should
> there not simply be just topics that should be discussed in the charter
> instead ?  Dan Romascanu: Agreed with Laurent.
> Sheng Jiang: Agreed.
> 
> Laurent: Common infrastructure question. Where/how do we see the role of
> autonomic in it. SHould the protocols control atonomic functions, or be
> autonomic themselves. Question 2: Internet deployment or design principles
> to improve future protocols with autonomic philosophy applied to other
> groups protocols.
> 
> Michael: AD responsible to approve future charter changes. Negotiate with
> AD to work in a controlled way through the number of use cases to solve.
> REne: maybe this is a note that should be removed after finalization.
> 
> Discussio about how many use cases beyond those solved by the
> infrastructure we should ave. Conclusion was one.
> 
> Value is not based on added value of synchronizing agents better than
> today. Other bodies who have tried to tackle this problem have also tried
> to build an infrastructure first and then focus on use cases.
> 
> PCE was a very good example. The overall use-case is the proof point tht
> helpe shape the 4 year work for those protocols.
> 
> Laurent: Can we show in one single use case example how to reuse the
> common infraastructure ? What we should focus on in the demonstation use
> case, that we can check over multiple use-cases, we can solve each of them
> with the common component.
> 
> Dimitiri: Success in functionality in use-cases. Sucess in design based on
> reuseability. Both can/should be in charter. But protocols are third step.
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 10 Sep 2014 09:31:15 +0000

Different opinions on how to bring this work forward have been expressed on this list over last 2 to 3 weeks. I have also discussed with several people the articulation of these different steps/tasks. This led me to think about the following analogy: before RSVP/RFC 2205 there was a model IntServ/RFC 1633 until protocol specification remained in the frame of this model its design had been well articulated; on the other hand, efforts to provide next steps without identifying objective boundaries leads unfortunately to an open ended protocol effort though it had shown that translating functionality into protocols has no unique 1:1 match; hence, articulation of the anima tasks would benefit from exploiting what has been learned out of these experiences:

Tasks:
-----

Step 0 (before start of WG): Functional areas where the working group agrees to contribute (risk mitigation/avoidance, re-configuration/-programming, etc.) by providing at least one use case per functional area. 

Step 1: Evaluation work of AN components (orchestration execution/realization of decisions, etc.), distributivity needs (exchange of information from external sources, exchange between AN agents, etc.) and cooperation modes against representative set of use cases

-> Goals: evaluate AN components against representative set of use cases and layout design of lightweight and reusable AN components

Step 2: ACP, a.k.a. common AN infrastructure, specification (in particular, cross-function single AN vs. cross-element multi AN) following the design goals of factorization, distribution, and unification required across use cases; determine if protocol functionality already "available" in other/existing protocol (with/without extensions) or new protocol(s) could be needed.

-> Goals: show the utility and feasibility of a common AN infrastructure (put/articulate AN components together across use cases)

Step 3: Depending on the outcome of step 2, extensions of existing protocols, new protocol design/specification, etc. can be considered.

-----

For the record, the complete text here below:

Challenges:
----------

Tasks:
-----

Step 0 (before start of WG): Functional areas where the working group agrees to contribute (risk mitigation/avoidance, re-configuration/-programming, etc.) by providing at least one use case per functional area. 

Step 1: Evaluation work of AN components (orchestration execution/realization of decisions, etc.), distributivity needs (exchange of information from external sources, exchange between AN agents, etc.) and cooperation modes against representative set of use cases

-> Goals: evaluate AN components against representative set of use cases and layout design of lightweight and reusable AN components

Step 2: ACP, a.k.a. common AN infrastructure, specification (in particular, cross-function single AN vs. cross-element multi AN) following the design goals of factorization, distribution, and unification required across use cases; determine if protocol functionality already "available" in other/existing protocol (with/without extensions) or new protocol(s) could be needed.

-> Goals: show the utility and feasibility of a common AN infrastructure (put/articulate AN components together across use cases)

Step 3: Depending on the outcome of step 2, extensions of existing protocols, new protocol design/specification, etc. can be considered.
 
Milestones:
----------

Thanks,
-dimitri.