Subject: Re: [nmrg] Autonomic Use Cases

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Apr 2014 16:40:58 +1200

Michael and everybody,

I apologise for being silent for a month on the list, but various
things intervened.

Shortly, I'll be posting a first draft of a use case. First though, here
are a few comments on what Michael proposed for use cases. I have trimmed
the text of the proposal:

> Problem Statement: 

Yes, we certainly need this.

> Intended user / administrator experience: 

Yes

> Intent: Strictly speaking intent is part of the administrator experience, but should probably explained explicitly with a high-level view

Yes, but I'm not so sure it's part of the user experience. At least for
my use case, as you'll see, it's probably a vendor default.

> Local knowledge: What the function needs to know about the capabilities of the node itself, and which local resources need to be accessed.

I found this a bit abstract. Concretely, it's a matter of which parameters
each device can decide for itself, without external information. Logically,
therefore, it comes before intent (as far as the device is concerned).

> Communication requirements: The requirements for message exchange, discovery, negotiation, etc with other autonomic nodes.

Firstly, the communication might be with non-autonomic nodes too! Secondly,
I found this a bit closer to the solution than the problem. So in my
version, this topic is about the information needed from neighbor devices,
not about messages.

Also, I found that I needed to say something about monitoring
(which affects each device, so can't just be described as part of
the user experience, although it affects that too).

Finally, it seems useful to compare the AN use case with current
solutions. If we can't describe benefits, we are a bit stuck.

> Use cases are not required to outline a solution in detail

Understood. But it's a matter of taste and judgment where
the problem statement stops and hints of the solution begin...

Anyway - the best test for all this is an example use case, which
will come very soon.

   Brian

On 08/03/2014 12:47, Michael Behringer (mbehring) wrote:
> NMRG, 
> 
> During the meeting we mentioned the need to document use cases. This section in the definitions draft is so far empty. Since we should have that section BEFORE working out the use cases, I drafted something up here. 
> 
> I also realised that while we haven't really written down in the draft that the key point of this work really is to work out common infrastructure requirements. So I'm also suggesting an additional short section in the Design Goals section: 
> 
>       <section title="Common Autonomic Networking Infrastructure">
> 	<t><xref target="I-D.irtf-nmrg-an-gap-analysis"/> points out that there are already a number of fully or partially autonomic functions available today. However, they are largely independent, and each has its own methods and protocols to communicate, discover, define and distribute policy, etc. </t>
> 	<t>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, etc. A common approach to define and manage intent is also required. </t>
> 	<t>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. </t>
>       </section>
> 
> Comments? Does this capture the idea well? 
> 
> And then, the use case section could look like this: 
> 
>       <section title="Guidelines for Case Studies">
> 	<t>Case studies and problem statements are mandatory to understand common requirements for autonomic functions. This section explains how case studies should be outlined and what they should describe:
>         <list style="symbols">
> 	  <t>Title</t>
> 	  <t>Problem Statement: An explanation which problem is being addressed, with information about existing solutions and their shortcomings.</t>
> 	  <t>Intended user / administrator experience: The goal of autonomic networking is to simplify network administration and usage. Use cases should point out how their experience differs from current solutions. If a use case depends on configuration, it may include configuration samples, although obviously the goal is to reduce or eliminate configuration. </t>
> 	  <t>Intent: Strictly speaking intent is part of the administrator experience, but should probably explained explicitly with a high-level view on how the autonomic function could be defined in intent (if required). </t>
> 	  <t>Local knowledge: What the function needs to know about the capabilities of the node itself, and which local resources need to be accessed.</t>
> 	  <t>Communication requirements: The requirements for message exchange, discovery, negotiation, etc with other autonomic nodes. </t>
>         </list>
> 	</t>
> 	<t>Use cases are not required to outline a solution in detail, nor to specify precise protocol or intent details. They are used at this point to determine a consolidated approach to developping an autonomic networking infrastructure. </t>
>       </section>
> 
> Comments? 
> Michael
> 
> _______________________________________________
> nmrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nmrg
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 10 Apr 2014 13:38:31 +0000

Thanks Brian. 

Let's have a quick look, and make sure we're in sync. We agreed to have a common format for the use cases. 

I had proposed the following outline: 
	Title
	Problem Statement
	Intended user / administrator experience
	Intent
	Local knowledge
	Communication requirements

You have used the following in your draft: 

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Intended User and Administrator Experience  . . . . . . . . .   3
   4.  Analysis of Parameters and Information Involved . . . . . . .   3
     4.1.  Parameters each device can decide for itself  . . . . . .   4
     4.2.  Information needed from policy intent . . . . . . . . . .   4
   5.  Interaction with other devices  . . . . . . . . . . . . . . .   4
     5.1.  Information needed from neighbor devices  . . . . . . . .   5
     5.2.  Monitoring, diagnostics and reporting . . . . . . . . . .   6
   6.  Comparison with current solutions . . . . . . . . . . . . . .   6

Let's not haggle over details, but learn as we move along. We can change my proposal to your layout. Only, 5.1 should read "...from other devices" - interactions are not limited to neighbors. 

I've taken the liberty to use your XML file Brian as a basis for a generic template. 

Anyone writing a use case: The attached XML file produces exactly the required outline. Just fill in your details. So, let's get going! (I've started to write "my" use case. Others?)

Michael

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 10 April 2014 10:11
> To: Michael Behringer (mbehring)
> Cc: [email-masked]
> Subject: Re: [nmrg] Autonomic Use Cases
> 
> Michael and everybody,
> 
> I apologise for being silent for a month on the list, but various things
> intervened.
> 
> Shortly, I'll be posting a first draft of a use case. First though, here are a few
> comments on what Michael proposed for use cases. I have trimmed the text
> of the proposal:
> 
> > Problem Statement:
> 
> > Intent: Strictly speaking intent is part of the administrator
> > experience, but should probably explained explicitly with a high-level
> > view
> 
> Yes, but I'm not so sure it's part of the user experience. At least for my use
> case, as you'll see, it's probably a vendor default.
> 
> > Local knowledge: What the function needs to know about the capabilities
> of the node itself, and which local resources need to be accessed.
> 
> I found this a bit abstract. Concretely, it's a matter of which parameters each
> device can decide for itself, without external information. Logically,
> > Communication requirements: The requirements for message exchange,
> discovery, negotiation, etc with other autonomic nodes.
> 
> Firstly, the communication might be with non-autonomic nodes too!
> Secondly, I found this a bit closer to the solution than the problem. So in my
> Also, I found that I needed to say something about monitoring (which
> affects each device, so can't just be described as part of the user
> experience, although it affects that too).
> 
> Finally, it seems useful to compare the AN use case with current solutions.
> If we can't describe benefits, we are a bit stuck.
> 
> Understood. But it's a matter of taste and judgment where the problem
> statement stops and hints of the solution begin...
> 
> Anyway - the best test for all this is an example use case, which will come
> very soon.
> 
>    Brian
> 
> 
> 
> 
> > During the meeting we mentioned the need to document use cases. This
> section in the definitions draft is so far empty. Since we should have that
> section BEFORE working out the use cases, I drafted something up here.
> >
> > I also realised that while we haven't really written down in the draft that
> the key point of this work really is to work out common infrastructure
> requirements. So I'm also suggesting an additional short section in the
> Design Goals section:
> >
> > 	<t><xref target="I-D.irtf-nmrg-an-gap-analysis"/> points out that
> there are already a number of fully or partially autonomic functions
> available today. However, they are largely independent, and each has its
> own methods and protocols to communicate, discover, define and
> distribute policy, etc. </t>
> > 	<t>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, etc. A
> common approach to define and manage intent is also required. </t>
> > 	<t>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. </t>
> >       </section>
> >
> > 	<t>Case studies and problem statements are mandatory to
> understand common requirements for autonomic functions. This section
> explains how case studies should be outlined and what they should
> describe:
> >         <list style="symbols">
> > 	  <t>Title</t>
> > 	  <t>Problem Statement: An explanation which problem is being
> addressed, with information about existing solutions and their
> shortcomings.</t>
> > 	  <t>Intended user / administrator experience: The goal of
> autonomic networking is to simplify network administration and usage. Use
> cases should point out how their experience differs from current solutions.
> If a use case depends on configuration, it may include configuration
> samples, although obviously the goal is to reduce or eliminate
> configuration. </t>
> > 	  <t>Intent: Strictly speaking intent is part of the administrator
> experience, but should probably explained explicitly with a high-level view
> on how the autonomic function could be defined in intent (if required). </t>
> > 	  <t>Local knowledge: What the function needs to know about the
> capabilities of the node itself, and which local resources need to be
> accessed.</t>
> > 	  <t>Communication requirements: The requirements for message
> exchange, discovery, negotiation, etc with other autonomic nodes. </t>
> >         </list>
> > 	</t>
> > 	<t>Use cases are not required to outline a solution in detail, nor to
> specify precise protocol or intent details. They are used at this point to
> determine a consolidated approach to developping an autonomic
> networking infrastructure. </t>
> >       </section>
> >
> > Comments?
> > Michael
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Apr 2014 07:54:33 +1200

Excellent. I assume we will adapt the template when we have a couple
more examples to consider.

> Only, 5.1 should read "...from other devices"

Yes, to cover the general case. (Personally I hope that most
interactions will be with on-link neighbors, to reduce the scope
of discovery requirements.)

Regards
   Brian