Re: [nmrg] Autonomic Use Cases

[Brian E Carpenter <[e-mail]>]

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

On 11/04/2014 01:38, Michael Behringer (mbehring) wrote:
> 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:[e-mail]]
>> Sent: 10 April 2014 10:11
>> To: Michael Behringer (mbehring)
>> Cc: [e-mail]
>> 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:
>> 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
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/nmrg
>>>
>