Re: [nmrg] Autonomic Use Cases

["Michael Behringer (mbehring)" <[e-mail]>]

> -----Original Message-----
> From: Joe Clarke (jclarke)
> Sent: 08 March 2014 22:26
> To: Michael Behringer (mbehring); [e-mail]
> Subject: Re: [nmrg] Autonomic Use Cases
> 
> On 3/7/14, 6:47 PM, 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>
> 
> Is this IETF or IRTF?  I know the goal is to eventually move into the IETF, but
> what do you intend here?

The way I see it, we kick this work off in the IRTF, but will soon move to the IETF for standardisation of approaches. Personally I think we don't need to be overly precise here, especially since IMO this section is going to drop off the final doc if and when it becomes an RFC. 
 
> > 	<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?
> 
> I think so.  I like the idea of moving beyond atomic autonomic functions into
> more of an autonomic system.  One key aspect of this system is self-
> monitoring and diagnostics (think regulation).  The idea of probes,
> sentinels, etc. play into this, and I think it should be called out in the list.

Good point, added "self-monitoring and diagnostics" to the list. Thanks!
 
> >
> > 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>
> 
> Nit: OF which problem is being...

Fixed. Thank you! :-) 
 
> > 	  <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>
> 
> Nit: probably BE explained...

Fixed, thank you! :-) 

> > 	  <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>
> 
> Nit: DEVELOPING (typo)

Fixed as well, thanks for the review!
 
> >        </section>
> >
> > Comments?
> 
> I think this is a good set of high-level guidelines.  Is there a need for remote
> knowledge as well?  That is, what if a node needs to know topology to make
> the right choice?

Yes there is. The academic research in autonomic networking defines a "knowledge plane" for this purpose. You're right, that needs to be represented here somehow. I would contend that knowledge is both "inside" and "remote". It is however a fairly abstract concept, we'll need to nail this down with some good use cases. 

Michael

> Joe