Subject: [nmrg] Autonomic Use Cases

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 7 Mar 2014 23:47:22 +0000

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

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 8 Mar 2014 14:03:34 +0000

Hi Michael,

I certainly share this goal. 

Reading throughout the intro, OSPF currently provides adaptive routing (within the setting for which they have been configured, information exchanged with other OSPF routers, etc.), a main goal that requires also further wording is the augmentation of their capability by means of predictive (and not only reactive) re-parametrization that couldn't be diagnosed by OSPF alone, information element not exchanged by the OSPF protocol itself, and procedures not currently part of its algorithmic. This example can be generalized to other protocols and processes but bare with me, the ultimate goal of autonomics is indeed to provide network-wide (so-called) intelligence to nodes while minimizing functional and informational dependence on centralized management or control systems. 

Hence, the focus of this design goal should be on autonomic (distributed) control plane elements.

Thanks,
-dimitri.

> -----Original Message-----
> From: nmrg [mailto:[email-masked]] On Behalf Of Michael Behringer
> (mbehring)
> Sent: Saturday, March 08, 2014 00:47
> To: [email-masked]
> Subject: [nmrg] Autonomic Use Cases
> 
> 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:
> 
> 	<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
> 
> _______________________________________________
> nmrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/nmrg

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sat, 08 Mar 2014 16:26:04 -0500

> 	<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 autono…

Is this IETF or IRTF?  I know the goal is to eventually move into the 
IETF, but what do you intend here?

> 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.

> 	  <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...

> 	  <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 int…

Nit: probably BE explained...

> 	<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…

Nit: DEVELOPING (typo)

> 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?

Joe

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 10 Mar 2014 15:16:53 +0000

> From: Joe Clarke (jclarke)
> Sent: 08 March 2014 22:26
> To: Michael Behringer (mbehring); [email-masked]
> Subject: Re: [nmrg] Autonomic Use Cases
> 
> 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:
> >
> own methods and protocols to communicate, discover, define and
> distribute policy, etc. </t>
> > 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>
> >
> 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!
 
> > 	<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>

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>

Fixed, thank you! :-) 

> > 	<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

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

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 11 Mar 2014 06:08:52 +0000

>Hence, the focus of this design goal should be on autonomic (distributed)

I fully agree on this observation. However, to clarify, this autonomic control plane we are talk about is different from the current control plan that mainly focus on, but only on routing and reachability. The new autonomic control plan is mainly targeting to minimize the current management plan. It should be able to autonomically decide the most (if not all) of management objects that currently needs human intelligence.

Thanks,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 11 Mar 2014 06:23:53 +0000

Hi, Michael,

Your text for "Design Goal" and "Guidelines for Case Studies" looks good.

One more thing I would like to add: the use cases could be written up with the assumption that the common infrastructure support (for example, the negotiation ability among devices) was already in the place. The use cases (documents) could focus on the scenarios, requirements and autonomic functions.

Regards,

Sheng

>Sent: Saturday, March 08, 2014 7:47 AM
>To: [email-masked]
>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>
>infrastructure may contain common control and management functions such
>as messaging, service discovery, negotiation, intent distribution, etc. A
>autonomic service agents do not have to replicate common tasks individually.
></t>
>      </section>
>
>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>
>experience, but should probably explained explicitly with a high-level view on
>how the autonomic function could be defined in intent (if required). </t>
>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: Sheng Jiang <[email-masked]>
Date: Tue, 11 Mar 2014 06:57:18 +0000

>IETF, but what do you intend here?

The autonomic network work in IRTF and IETF are relevant to each other. The ideal is we have high-level definitions, design goals, requirements and gap analysis in IRTF. For any concrete protocol work, that supports common autonomic network infrastructure, such as negotiation protocol, should be hold in IETF.

Ideally, we would have several autonomic network use cases that are based on the same common control and management functions. Then we can work on these common control and management functions in IETF, while each of use cases may have its own instance on top of the common infrastructure.

Best regards,

Sheng

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 12 Mar 2014 08:42:03 +0000

The autonomic control plane is a generic communications channel between autonomic devices. It contains protocols needed for autonomic purposes, such as a message bus, discovery functions, etc. 

Michael

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: 11 March 2014 07:09
> To: Papadimitriou, Dimitri (Dimitri); Michael Behringer (mbehring);
> [email-masked]
> Subject: RE: Autonomic Use Cases
> 
> I fully agree on this observation. However, to clarify, this autonomic control
> plane we are talk about is different from the current control plan that
> mainly focus on, but only on routing and reachability. The new autonomic
> control plan is mainly targeting to minimize the current management plan.
> It should be able to autonomically decide the most (if not all) of
> management objects that currently needs human intelligence.
> 
> Thanks,
> 
> Sheng
> 
> >Thanks,
> >-dimitri.
> >
> >> 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:
> >>
> >> available today. However, they are largely independent, and each has
> >> its own methods and protocols to communicate, discover, define and
> >> 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>
> the
> 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>
> autonomic
> >> should point out how their experience differs from current solutions.
> >> experience, but should probably explained explicitly with a
> >> high-level view on how the autonomic function could be defined in
> >> intent (if required). </t>
> >> 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
> >>