Subject: [Anima] Notes from the ANIMA Call today

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 Aug 2014 17:26:34 +0000

Please find the notes attached. The recording of the call is here: 

https://cisco.webex.com/ciscosales/lsr.php?RCID=2dc6ab80adcd425a893a605ec9ae31ff

Thanks to all who participated! 
Michael

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 21 Aug 2014 18:42:04 +0000

Hello,

Reading these minutes, the charter still requires (re)work in my opinion:

- it doesn't state the overall objective of this effort, neither motivates it appropriately (what does it solve ? what's missing today ? what are the "operational" burdens it aims at addressing ? etc.)

- assuming OPS area doesn't put major focus on architecture itself but on functionality, the question stems as of why the "solution target" section of the charter is mostly about protocol machinery (discovery, negotiation, etc.) and not on the functionality each of the use cases would provide/solve (or more efficiently than we could today by other means) 

- why the charter lists starting point documents next to each of the goals ? it reads as if focus is on validating these protocols but it should work the other around (essence of the previous point). This being said the two first documents have never been discussed so why consider them as starting point ? --note: for the third one, see comment below. 

- the charter states "Definition of a solution for a separated Autonomic Control Plane" why from the start the architectural decision is to have a "separated" control plane ? and separated from what (to start with) ? 
Again if OPS area is not focusing on architecture why all these architectural decisions have to be carved in stone in the charter ? shouldn't they be documented at the end (as part of the last work item of the charter) instead of the beginning ?

Thanks,
-dimitri.

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer
> (mbehring)
> Sent: Thursday, August 21, 2014 7:27 PM
> To: [email-masked]
> Subject: [Anima] Notes from the ANIMA Call today
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Aug 2014 08:30:44 +1200

On 22/08/2014 06:42, Papadimitriou, Dimitri (Dimitri) wrote:
> - it doesn't state the overall objective of this effort,
> neither motivates it appropriately (what does it solve ?
> what's missing today ? what are the "operational" burdens it
> aims at addressing ? etc.)

These issues have certainly been discussed in some of the
existing documents that are assumed as background. It's a matter
of taste how much of this is duplicated in the charter. I agree
that some extra text would help the reader.

> - assuming OPS area doesn't put major focus on architecture
> itself but on functionality, the question stems as of why the
> "solution target" section of the charter is mostly about
> protocol machinery (discovery, negotiation, etc.) and not on
> the functionality each of the use cases would provide/solve
> (or more efficiently than we could today by other means)

That is in my personal opinion a recognition of an old truth
about the IETF: we succeed much better when we work on simple
"piece parts" than when we work on architectures and
systems-level solutions.

> - why the charter lists starting point documents next to each
> of the goals ? it reads as if focus is on validating these
> protocols 

What is unclear about the phrase "starting point"? (Although
there is in fact running code, as there is for the
draft-pritikin and draft-behringer documents, but they are more
specific to individual use cases.)

> but it should work the other around (essence of the
> previous point). This being said the two first documents have
> never been discussed 

Actually, they have been presented in IRTF and IETF. But I agree
that discussion is needed.

> so why consider them as starting point ?
> --note: for the third one, see comment below.
> 
> - the charter states "Definition of a solution for a
> separated Autonomic Control Plane" why from the start the
> architectural decision is to have a "separated" control plane

Actually it is only one option, and not intended as a required
feature of a systems architecture. I'm pretty sure that many
deployments would want a logically separate control plane.

> ? and separated from what (to start with) ? 

Separate address space? Separate VLAN? Separate overlay network?
Separate security environmemt? Or even a physically separate
network? Actually I'm not even sure it matters, since these all
seem like valid deployment models.

> Again if OPS area
> is not focusing on architecture why all these architectural
> decisions have to be carved in stone in the charter ?
> shouldn't they be documented at the end (as part of the last
> work item of the charter) instead of the beginning ?

That gets back to my point about piece parts. Yes, by defining a
certain set of parts you constrain the systems architecture and
deployment architecture. I think the approach we're proposing
comes out of a quite long period of discussion in the NMRG and
prototyping and even an initial product, so it seems normal to
me that we tie it down in the charter. The NMRG remains
available as the venue for wider discussions.

All IMHO still
   Brian

> 
> Thanks, -dimitri.
> 
> 
> 
> 
> 
>> -----Original Message----- From: Anima
>> [mailto:[email-masked]] On Behalf Of Michael
>> Behringer (mbehring) Sent: Thursday, August 21, 2014 7:27
>> PM To: [email-masked] Subject: [Anima] Notes from the ANIMA
>> Call today
>> 
>> Thanks to all who participated! Michael
> 
> _______________________________________________ Anima mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 21 Aug 2014 22:56:44 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, August 21, 2014 10:31 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: [email-masked]; Michael Behringer (mbehring)
> Subject: Re: [Anima] Notes from the ANIMA Call today
> 
> > - it doesn't state the overall objective of this effort, neither
> > motivates it appropriately (what does it solve ?
> > what's missing today ? what are the "operational" burdens it aims at
> > addressing ? etc.)
> 
> These issues have certainly been discussed in some of the existing
> documents that are assumed as background. It's a matter of taste how much
> of this is duplicated in the charter. I agree that some extra text would
> help the reader.

Let's see how the reworked text for these sections will provide actual motivation in the form of problem statement, new needs, design limits, etc. wrt current operations and associated models.

> > - assuming OPS area doesn't put major focus on architecture itself but
> > on functionality, the question stems as of why the "solution target"
> > section of the charter is mostly about protocol machinery (discovery,
> > negotiation, etc.) and not on the functionality each of the use cases
> > would provide/solve (or more efficiently than we could today by other
> > means)
> 
> That is in my personal opinion a recognition of an old truth about the
> IETF: we succeed much better when we work on simple "piece parts" than
> when we work on architectures and systems-level solutions.

May be. The approach the OPS area underlines though the fundamental question as what's the purpose and operational benefits of this effort (instead of the specifics of the design of underlying protocols which would come in a second phase). Reading through the charter this goal neither reflects as input nor an output.

Actually, such question raises mainly because despite of the various discussion rounds at IRTF, the NMRG outcomes are mainly qualitative (and for most part few experimental outcomes have been actually documented and consolidated).

> > - why the charter lists starting point documents next to each of the
> > goals ? it reads as if focus is on validating these protocols
> 
> What is unclear about the phrase "starting point"? (Although there is in
> fact running code, as there is for the draft-pritikin and draft-behringer
> documents, but they are more specific to individual use cases.)

The justification looks for me mainly because these documents exist (instead of reflecting technically objective arguments). As you refer to old truths, it is also known that cross-fertilizing existing with new outcomes is beneficial. It doesn't seem to be the case here -why ? 

> > but it should work the other around (essence of the previous point).
> > This being said the two first documents have never been discussed
> 
> Actually, they have been presented in IRTF and IETF. But I agree that
> discussion is needed.
> 
> > - the charter states "Definition of a solution for a separated
> > Autonomic Control Plane" why from the start the architectural decision
> > is to have a "separated" control plane
> 
> Actually it is only one option, and not intended as a required feature of
> a systems architecture. I'm pretty sure that many deployments would want a
> logically separate control plane.

Difficult to state as there is no deployment (yet). The argument seems rather limited to make such statement upfront. I think the charter takes as given truth what has served as material for discussion at IRTF whereas the trialing phase has been moved to IETF. 

What can be motivated though is separated or not, the deployment criteria will be functionality first.

> Separate security environmemt? Or even a physically separate network?
> Actually I'm not even sure it matters, since these all seem like valid
> deployment models.

So why making that assumption at first place ?

> > Again if OPS area
> > is not focusing on architecture why all these architectural decisions
> > have to be carved in stone in the charter ?
> > shouldn't they be documented at the end (as part of the last work item
> > of the charter) instead of the beginning ?
> 
> That gets back to my point about piece parts. Yes, by defining a certain
> set of parts you constrain the systems architecture and deployment
> architecture. I think the approach we're proposing comes out of a quite
> long period of discussion in the NMRG and prototyping and even an initial
> product, so it seems normal to me that we tie it down in the charter. 

The trialing/experimental phase at IRTF is too narrow to come with such ground truth statement. There are several alternatives possible and this at different levels; the same question occurs for the service agents defined as "single function" in the NRMG documents whereas a cross-function agent per node is certainly an option to explore --but discarded beforehand for unclear reasons. 

> The NMRG remains available as the venue for wider discussions.

The problem remains. This charter requires serious rework because of all the reasons explained here above --and for which technically objective answers are still missing. I suppose you would like this discussion to happen on this list not at IRTF.

> >> [mailto:[email-masked]] On Behalf Of Michael Behringer
> >> (mbehring) Sent: Thursday, August 21, 2014 7:27 PM To: [email-masked]
> >> https://cisco.webex.com/ciscosales/lsr.php?RCID=2dc6ab80adcd425a893a6
> >> 05ec9
> >>  ae31ff
> >>
> > _______________________________________________ Anima mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/anima
> >
> 
> _______________________________________________
> Anima mailing list
> [email-masked]

---

From: Rene Struik <[email-masked]>
Date: Fri, 22 Aug 2014 16:47:34 -0400

Hi Brian:

I must say that the suggestion to "That is in my personal opinion a 
recognition of an old truth about the IETF: we succeed much better when 
we work on simple "piece parts" than when we work on architectures and 
systems-level solutions." seems to conflict what is supposed to be the 
goal of autonomic networking effort (see excerpt of the "definitions" 
draft below).

I will comment on the individual drafts mentioned in the draft "charter" 
(if that is what it is -- it is still very hard to interpret this or 
make sense of this) separately.

Right now, it seems much more needs to be done to make this into a 
workable charter, with a coherent task.

[excerpt of draft-irtf-nmrg-autonomic-network-definitions-01 (Section 3.3)]
The goal of the work on autonomic networking in the IETF is therefore 
not just to create autonomic functions, but to define a common 
infrastructure that autonomic functions can use. This autonomic 
networking infrastructure may contain common control and management 
functions such as messaging, service discovery, negotiation, intent 
distribution, self-monitoring and diagnostics, etc. A common approach to 
define and manage intent is also required. Refer to the reference model 
below: All the components around the "autonomic service agents" should 
be common components, such that the autonomic service agents do not have 
to replicate common tasks individually.

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Aug 2014 14:20:45 +1200

> goal of autonomic networking effort (see excerpt of the "definitions"

Nevertheless, it isn't the IETF that designs traditional network
management systems - we design protocols used by network management
systems; vendors and/or large sites design the systems. I think that
tells us something about what can be achieved.

Don't misunderstand me. We need to design things that can be fitted
together into a coherent whole, and that's why the excerpt you quote
below exists. But what can the IETF's output documents be except
a set of mutually consistent protocol specifications?

> workable charter, with a coherent task.

I feel you are trying to ask the charter to contain the WG's output,
not a description of its scope. But anyway, I will leave it to someone
else to propose the next draft of the charter.

    Brian

>>>> https://cisco.webex.com/ciscosales/lsr.php?RCID=2dc6ab80adcd425a893a605ec9
>>>>
>>>>   ae31ff
>>>>