Subject: [Anima] ANIMA draft charter

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 5 Aug 2014 08:19:15 +0000

At the BoF in Toronto there was rough consensus to continue the work on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I have now drafted a potential WG charter with the input of our ADs. Note that this is not yet a formal charter proposal, it's for discussion only so far.

The assumption is that more general aspects of autonomics will continue to be discussed in the NMRG group. 

If we were to go ahead with a WG, the goal would be to focus on realistic deliverables. So the plan is to start with a small, achievable set of deliverables, and, if successful and useful, expand after re-chartering. 

Please comment here on this draft charter proposal. 

Thanks, 
Michael

Autonomic Networking Integrated Model and Approach (ANIMA) WG

Description of Working Group

Autonomic Networking focuses on self-management of network elements. An autonomic function works in a distributed way across various network elements, allowing however central guidance and reporting. Autonomic functions already exist today, for example IGP routing protocols such as OSPF. However, all such functions have their own discovery, transport, messaging and security mechanisms. 

To transform the somewhat abstract Autonomic Networking concept into concrete, realisable requirements, the first stage, undertaken in the Network Management Research Group (NMRG) of the IRTF, was to define terminology and design goals, and to derive a high-level gap analysis. The definitions and design goals, as well as a simple architecture model are defined in draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN is described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF 90 discussed use cases and some existing solutions. All the above work serves as a baseline for this working group.

This working group defines solutions for an initial set of components of an autonomic networking infrastructure, based on the simple architecture and design goals defined in draft-irtf-nmrg-autonomic-network-definitions. Future work may include a more detailed systems architecture to support the development of autonomic service agents. The Anima working group will initially focus on enterprise, ISP networks and IoT.

The solutions target to cover the following areas: 
o identity of nodes
o common security model
o discovery model
o negotiation model
o a secure and logically separated communications channel
o an example for an autonomic management model

The goals of this working group are: 

o Definition of a generic discovery and negotiation protocol for autonomic functions
   Starting point: draft-jiang-config-negotiation-protocol
o Definition of a mechanism to bootstrap a trust infrastructure 
   Starting point: draft-pritikin-bootstrapping-keyinfrastructures
o Definition of an logically separated Autonomic Control Plane
   Starting point: draft-behringer-autonomic-control-plane

In addition, autonomic service agents will need to be defined for specific use cases. The working group will initially consider one simple example as a test case for further work. 

o Definition of <a selected use case by the group>
  Starting point: draft-use-case-tbd

The initial set of work items is limited to the above list to stay focused and avoid "boiling the ocean". Additional documents concerning policy intent, other autonomic infrastructure components, use cases or autonomic service agents are strongly encouraged, as individual submissions, but are not planned as working group deliverables for now. No additional work items will be accepted in the working group without re-chartering. 

Milestones

Nov 2014 - WG formation and adoption of drafts
           - Mar IETF - 
Jun 2015 - WGLC for draft-generic-discovery-negotiation-protocol
           - Jul IETF - 
Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG (standards track)
Oct 2015 - WGLC draft-keyinfrastructure-bootstrap 
Oct 2015 - WGLC draft-use-case-tbd
           - Nov IETF - 
Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG  (standards track)
Dec 2015 - submit draft-use-case-tbd to IESG  (standards track)
Jan 2016 - WGLC draft-autonomic-common-control-plane 
           - Mar IETF - 
Apr 2016 - submit draft-autonomic-common-control-plane to IESG  (standards track)
Jul 2016 - recharter if needed, or close

--

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 5 Aug 2014 11:48:26 +0000

Hi Michael,
I read the proposed WG charter and it looks good, great work.
I just have a comment on the following milestone:
-Dec 2015 - submit draft-use-case-tbd to IESG  (standards track)

Use cases drafts are usually informational documents: any reasons to propose this one as standard track?
Thanks
Regards
Roberta

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Michael Behringer (mbehring)
Sent: Tuesday, August 05, 2014 10:19 AM
To: [email-masked]
Subject: [Anima] ANIMA draft charter

Thanks, 
Michael

Milestones

--

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 5 Aug 2014 13:43:01 +0000

> From: Roberta Maglione (robmgl)
> Sent: 05 August 2014 13:48
> To: Michael Behringer (mbehring)
> Cc: [email-masked]
> Subject: RE: ANIMA draft charter
> 
> Hi Michael,

Thanks for your support Roberta. I wouldn't read too much into the details at this point ;-) There are a number of things to look. A use case could be either an informative description how an autonomic service agent acts, using standard protocols; in which case it would be informational; if it requires some protocol extension or similar, there may be some standards track involved as well. We'll see once we have the use case clear. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2014 11:14:55 +1200

> Thanks for your support Roberta. I wouldn't read too much into the details at this point ;-) There are a number of things to look. A use case could be either an informative description how an auton…

Indeed. The chances are that Roberta is correct. The other question of
course is which use case we should pick.

As a matter of fact, the proposed work item on an autonomic control
plane, definitely aimed at the standards track, is itself also a
use case (you could say that it's autonomic networking eating its
own dog food).

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 6 Aug 2014 01:21:28 +0000

>propose this one as standard track?

Hi, Roberta,

Thanks so much for point this out. I believe we put standards track there for reasons. There are two kinds of use case documents: A) use case description; B) protocol-oriented use case, which includes necessary extension of protocol in order to fulfill this use case. We referred to the latter. If the scope was limited to the former, of course, it should be informational. That's what I recall from our discussion in Toronto. However, it is the anima group who have the final decision.

Best regards,

Sheng

>At the BoF in Toronto there was rough consensus to continue the work on an
>autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I have now
>drafted a potential WG charter with the input of our ADs. Note that this is not
>yet a formal charter proposal, it's for discussion only so far.
>
>If we were to go ahead with a WG, the goal would be to focus on realistic
>deliverables. So the plan is to start with a small, achievable set of deliverables,
>and, if successful and useful, expand after re-chartering.
>
>Autonomic Networking focuses on self-management of network elements.
>An autonomic function works in a distributed way across various network
>elements, allowing however central guidance and reporting. Autonomic
>functions already exist today, for example IGP routing protocols such as OSPF.
>However, all such functions have their own discovery, transport, messaging
>and security mechanisms.
>
>To transform the somewhat abstract Autonomic Networking concept into
>concrete, realisable requirements, the first stage, undertaken in the Network
>Management Research Group (NMRG) of the IRTF, was to define terminology
>and design goals, and to derive a high-level gap analysis. The definitions and
>design goals, as well as a simple architecture model are defined in
>draft-irtf-nmrg-autonomic-network-definitions; the gap analysis for AN is
>described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF 90
>discussed use cases and some existing solutions. All the above work serves as
>a baseline for this working group.
>
>This working group defines solutions for an initial set of components of an
>autonomic networking infrastructure, based on the simple architecture and
>design goals defined in draft-irtf-nmrg-autonomic-network-definitions. Future
>work may include a more detailed systems architecture to support the
>development of autonomic service agents. The Anima working group will
>initially focus on enterprise, ISP networks and IoT.
>
>In addition, autonomic service agents will need to be defined for specific use
>cases. The working group will initially consider one simple example as a test
>case for further work.
>
>The initial set of work items is limited to the above list to stay focused and
>avoid "boiling the ocean". Additional documents concerning policy intent,
>other autonomic infrastructure components, use cases or autonomic service
>agents are strongly encouraged, as individual submissions, but are not
>planned as working group deliverables for now. No additional work items will
>be accepted in the working group without re-chartering.
>
>Milestones
>

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Wed, 6 Aug 2014 07:52:55 +0000

Thanks Michael, Sheng and Brian for the clarifications.
Regards
Roberta

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]] 
Sent: Wednesday, August 06, 2014 3:21 AM
To: Roberta Maglione (robmgl); Michael Behringer (mbehring)
Cc: [email-masked]
Subject: RE: ANIMA draft charter

Hi, Roberta,

Best regards,

Sheng

>At the BoF in Toronto there was rough consensus to continue the work on 
>an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I have 
>now drafted a potential WG charter with the input of our ADs. Note that 
>this is not yet a formal charter proposal, it's for discussion only so far.
>
>If we were to go ahead with a WG, the goal would be to focus on 
>realistic deliverables. So the plan is to start with a small, 
>achievable set of deliverables, and, if successful and useful, expand after re-chartering.
>
>However, all such functions have their own discovery, transport, 
>messaging and security mechanisms.
>
>concrete, realisable requirements, the first stage, undertaken in the 
>Network Management Research Group (NMRG) of the IRTF, was to define 
>terminology and design goals, and to derive a high-level gap analysis. 
>The definitions and design goals, as well as a simple architecture 
>model are defined in draft-irtf-nmrg-autonomic-network-definitions; the 
>gap analysis for AN is described in draft-irtf-nmrg-an-gap-analysis. 
>The UCAN BoF at IETF 90 discussed use cases and some existing 
>solutions. All the above work serves as a baseline for this working group.
>
>This working group defines solutions for an initial set of components 
>of an autonomic networking infrastructure, based on the simple 
>architecture and design goals defined in 
>draft-irtf-nmrg-autonomic-network-definitions. Future work may include 
>a more detailed systems architecture to support the development of 
>autonomic service agents. The Anima working group will initially focus on enterprise, ISP networks and IoT.
>
>o a secure and logically separated communications channel o an example 
>for an autonomic management model
>
>In addition, autonomic service agents will need to be defined for 
>specific use cases. The working group will initially consider one 
>simple example as a test case for further work.
>
>The initial set of work items is limited to the above list to stay 
>focused and avoid "boiling the ocean". Additional documents concerning 
>policy intent, other autonomic infrastructure components, use cases or 
>autonomic service agents are strongly encouraged, as individual 
>submissions, but are not planned as working group deliverables for now. 
>No additional work items will be accepted in the working group without re-chartering.
>
>Milestones
>
>Aug 2015 - submit draft-generic-discovery-negotiation-protocol to IESG 
>(standards track) Oct 2015 - WGLC draft-keyinfrastructure-bootstrap Oct 
>2015 - WGLC draft-use-case-tbd
>           - Nov IETF -
>Dec 2015 - submit draft-use-case-tbd to IESG  (standards track) Jan 
>2016 - WGLC draft-autonomic-common-control-plane
>           - Mar IETF -
>Apr 2016 - submit draft-autonomic-common-control-plane to IESG 
>(standards track) Jul 2016 - recharter if needed, or close
>
>--
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 6 Aug 2014 10:28:12 +0000

Hi Michael,

The proposal looks pretty good. The deliverables are clear and feasible.

>    Starting point: draft-behringer-autonomic-control-plane

It seems like the solution areas are distributed into the 3 documents? But some of the items such as "identity of nodes" might be common issues, so I'm not sure whether the 3 documents could cover all the targeted solutions?

Best regards,
Bing

> Sent: Tuesday, August 05, 2014 4:19 PM
> To: [email-masked]
> drafted a potential WG charter with the input of our ADs. Note that this is
> not yet a formal charter proposal, it's for discussion only so far.
> 
> deliverables. So the plan is to start with a small, achievable set of
> deliverables, and, if successful and useful, expand after re-chartering.
> 
> functions already exist today, for example IGP routing protocols such as
> OSPF. However, all such functions have their own discovery, transport,
> Management Research Group (NMRG) of the IRTF, was to define
> terminology and design goals, and to derive a high-level gap analysis. The
> definitions and design goals, as well as a simple architecture model are
> defined in draft-irtf-nmrg-autonomic-network-definitions; the gap analysis
> for AN is described in draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF
> 90 discussed use cases and some existing solutions. All the above work
> serves as a baseline for this working group.
> 
> design goals defined in draft-irtf-nmrg-autonomic-network-definitions.
> Future work may include a more detailed systems architecture to support the
> planned as working group deliverables for now. No additional work items
> will be accepted in the working group without re-chartering.
> 
> Milestones
> 
> (standards track)

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 6 Aug 2014 12:55:04 +0000

Bing, 

The "solutions" section is high level what needs to be covered. Identity, security, etc. 
The "goals" are putting the above abstract concepts into concrete deliverables, and there is an  (implicit) mapping between the two. 

We could drop the first part, because it seems a bit redundant, but my worry is that as we modify the goals / deliverables we may miss one of the above points. 

Suggestions welcome if you have an idea how to frame it better.
Michael

> From: Liubing (Leo) [mailto:[email-masked]]
> Sent: 06 August 2014 12:28
> To: Michael Behringer (mbehring); [email-masked]
> It seems like the solution areas are distributed into the 3 documents? But
> some of the items such as "identity of nodes" might be common issues, so
> I'm not sure whether the 3 documents could cover all the targeted
> solutions?
> 
> Best regards,
> Bing
> 
> > At the BoF in Toronto there was rough consensus to continue the work
> > on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and I
> > have now drafted a potential WG charter with the input of our ADs.
> > Note that this is not yet a formal charter proposal, it's for discussion only
> so far.
> >
> > The assumption is that more general aspects of autonomics will
> > continue to be discussed in the NMRG group.
> >
> > An autonomic function works in a distributed way across various
> > network elements, allowing however central guidance and reporting.
> > Autonomic functions already exist today, for example IGP routing
> > protocols such as OSPF. However, all such functions have their own
> > discovery, transport, messaging and security mechanisms.
> >
> > model are defined in draft-irtf-nmrg-autonomic-network-definitions;
> > the gap analysis for AN is described in
> > draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF
> > architecture and design goals defined in draft-irtf-nmrg-autonomic-
> network-definitions.
> > Future work may include a more detailed systems architecture to
> > support the development of autonomic service agents. The Anima
> working
> > group will initially focus on enterprise, ISP networks and IoT.
> >
> > submissions, but are not planned as working group deliverables for
> > now. No additional work items will be accepted in the working group
> without re-chartering.
> >
> > Milestones
> >
> > (standards track) Oct 2015 - WGLC draft-keyinfrastructure-bootstrap
> > Dec 2015 - submit draft-keyinfrastructure-bootstrap to IESG
> > (standards
> > track)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2014 08:33:00 +1200

I'm not sure I would change the document plan, but Bing is correct
that some features have global importance. I would expect that
the documents will all have normative dependencies on the others,
and it is part of the work to ensure that they are consistent.

    Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Aug 2014 02:56:23 +0000

Hi Brian & Michael,

Thanks for your explanations. I have some rough thoughts as following, which maybe already addressed by former discussion that I haven't followed.

There might be two ways for the global features in "Solutions" section:
1. The global features are unified, e.g., the node identities in config-negotiation-protocol, bootstrapping-keyinfrastructures, and autonomic-control-plane are exactly the same.
2. The global features are covered in each specific mechanism, but they might have different designs to respectively fit their goals more sufficiently.
I think maybe we need to make it more clearer.

Personally, I'm a little concerned that whether choice 1 could be achieved in real design. May I ask your thoughts?

Best regards,
Bing
 
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, August 07, 2014 4:33 AM
> Cc: Liubing (Leo); [email-masked]
> Subject: Re: [Anima] ANIMA draft charter
> 
> I'm not sure I would change the document plan, but Bing is correct that
> some features have global importance. I would expect that the documents
> will all have normative dependencies on the others, and it is part of the work
> to ensure that they are consistent.
> 
>     Brian
> 
> > The "goals" are putting the above abstract concepts into concrete
> deliverables, and there is an  (implicit) mapping between the two.
> >
> > We could drop the first part, because it seems a bit redundant, but my
> worry is that as we modify the goals / deliverables we may miss one of the
> above points.
> >
> >>> o a secure and logically separated communications channel o an
> >>> example for an autonomic management model
> >>>
> >> It seems like the solution areas are distributed into the 3
> >> documents? But some of the items such as "identity of nodes" might be
> >> common issues, so I'm not sure whether the 3 documents could cover
> >> all the targeted solutions?
> >>
> >> Best regards,
> >> Bing
> >>
> >>> on an autonomic infrastructure. Brian, Sheng, Toerless, Laurent and
> >>> I have now drafted a potential WG charter with the input of our ADs.
> >>> achievable set of deliverables, and, if successful and useful,
> >>> expand after
> >> re-chartering.
> >>> concrete, realisable requirements, the first stage, undertaken in
> >>> the Network Management Research Group (NMRG) of the IRTF, was to
> >>> define terminology and design goals, and to derive a high-level gap
> analysis.
> >>> 90 discussed use cases and some existing solutions. All the above
> >>> work serves as a baseline for this working group.
> >>>
> >>> This working group defines solutions for an initial set of
> >>> components of an autonomic networking infrastructure, based on the
> >>> simple architecture and design goals defined in
> >>> draft-irtf-nmrg-autonomic-
> >> network-definitions.
> >>> o a secure and logically separated communications channel o an
> >>> example for an autonomic management model
> >>>
> >>> focused and avoid "boiling the ocean". Additional documents
> >>> concerning policy intent, other autonomic infrastructure components,
> >>> use cases or autonomic service agents are strongly encouraged, as
> >>> individual submissions, but are not planned as working group
> >>> deliverables for now. No additional work items will be accepted in
> >>> the working group
> >> without re-chartering.
> >>> Milestones
> >>>
> >>> Aug 2015 - submit draft-generic-discovery-negotiation-protocol to
> >>> IESG (standards track) Oct 2015 - WGLC
> >>> draft-keyinfrastructure-bootstrap Oct 2015 - WGLC draft-use-case-tbd
> >>>            - Nov IETF -

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Aug 2014 03:00:14 +0000

Hi Michael & All,

>   Starting point: draft-use-case-tbd

Will the use case(s) be selected before or after the WG formation?

Best regards,
Bing

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Aug 2014 15:21:10 +1200

Hi Bing,

We did have a list of criteria for use cases, included in Michael's
slides at the BOF. We can look at the known use cases to find one that
fits the criteria. My personal preference is to choose one before
the WG is chartered - but if there isn't an obvious consensus, it might
have to wait so that the WG chairs could judge the rough consensus.

Just as a reminder, Michael's list:
A function is a good candidate for autonomic work at the IETF if:
– There is operator interest
– Distribution
  (The function cannot be completely centralised, or
  there are advantages with distribution)
– Sharing infrastructure
– There are other functions that require similar functionality or benefit
from the proposed function
– Abstraction
  (There is an easy way to describe the function, high-level, network wide)
– Simplicity to implement
– Makes it easier to get started

Regards
   Brian Carpenter

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Thu, 7 Aug 2014 06:58:34 +0000

Hi All,

> for an autonomic management model

I think 2-3 typical use cases may be better.

BR
Yu

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Liubing (Leo)
Sent: Thursday, August 07, 2014 11:00 AM
To: Michael Behringer (mbehring); [email-masked]
Subject: [Anima] About use case-//RE: ANIMA draft charter

Hi Michael & All,

Best regards,
Bing

> Note that this is not yet a formal charter proposal, it's for discussion only so far.
> 
> architecture and design goals defined in draft-irtf-nmrg-autonomic-network-definitions.
> support the development of autonomic service agents. The Anima working 
> now. No additional work items will be accepted in the working group without re-chartering.
> 
> Milestones
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Aug 2014 04:44:14 -0700

Leo,

I am not sure what you imply with "exactly the same" in 1. Maybe you can give
the most simple example where we are not doing it "exactly he same" and
that you think might be useful ?

To me, i can see a lot of functions that "naturally" might use different identities.
Eg: LAN protocol where the MAC address is the "natural" identity of a node.
L3 protocols where the IP address is a natural identity of the node. But then
you want to make sure there is security and protection against errors/duplicate
address/identity, and you end up creating a mapping to a more trustworthy identity.

Example ACP: I can run protocols via IPv6 inside the ACP between nodes. So
the IPv6 address becomes the natural node identity. So, how do i secure this ?
Well, i do not need to add a separate layer of security to each such protocol,
because all those packets within the ACP have been received via secured ACP channels,
and that underlying channel is secured - with the secure node identity, eg: S-UDI.
So i have an implicit mapping between S-UDI as the primary, secure node identity,
and some protocol specific identity such as the IPv6 address it has inside the ACP.

Does this match your "exatly the same" - or not ?

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Aug 2014 05:04:53 -0700

> use case (you could say that it's autonomic networking eating its

Thanks, Brian

To put this into perspective: 

Brian asked originally before the BOF for a clear separation of use-case and
solution drafts. an we didn't get that done in time for Toronto due to ENOTIME,
so we had both aspects in one draft.  We could of course still do this now before 
Honolulu if thats still desirable.

The ACP definition in the charter would be the standards track target
solution/technology.

The use-cases for ACP would be what we showed during the BOF and potentially
even more:

What we showed:

  1. "Virtual DCE" or "free Autonomic inband OAM network"
  
  2. avoidance of incremental pre-stating configuring during boostrap 
     of larger topologies. 

     This is "eat your own dog-food", because it allows to improve the bootstrap.

The "even more" refers to further autonomic functions like autonomic agents,
or expanding the negotiation protocol to become more like eg: a bus between
the autonomic agents across a larger topology. For both of those
purposed, the ACP would also be reuseable/beneficial.

So, if folks feel we should separate out a use-case draft for the ACP,
maybe with exactly those two points listed above (as we presented at the BOF),
that would be fine. I think after having gone through the exercise of the BOF
and slides there i have a clearer idea how we can cut end appropriately expand
the text to have two documents.

Cheers
    Toerless

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 7 Aug 2014 15:11:51 +0200

Hello,

I agree with Toerless. Nice example.

What we need is:
     -a unique definition of the concept "node identity" in the scope of 
the autonomic network infrastructures. I not even sure that we should 
talk about "_node_ identify" but rather "_function_ identity" - or a 
hierarchy of identities e.g. atomic function identity + group of 
functions identity. also, are we clear that we talk about identity or 
identifier?

     -consistency across the actors/layers/protocols/whatever is 
involved about the identities being used.

     -translation mechanisms to ensure the above consistency.

But maybe before debating this "details": to what the "node identity" 
initially defined in the charter do refers to...?

Regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 NOZAY | France

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 7 Aug 2014 15:16:33 +0200

Toerless,

I think it will be more clear for the future discussions to have two 
separate documents.

Just my two cents. Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Aug 2014 06:25:50 -0700

Thanks, Lauren

I think i may have failed my PhD in word smithing, 
and you reminded me of the term identifier:

So: in the examples i used, should we call the MAC and IP addresses
the "identifier", and the only node identity is only AN domain S-UDI 
and then we can talk about "secure linkage" between node identity and 
various identifiers we may want to use ?

With this terminology, should we call the MIC (Manufacturing Installed
Certificate) a secure identifier that we use during bootstrap to
assign the node identity (AN domain S-UDI) to the device ?

Any certified word smith PhDs, please ? ;-))

Cheers
   
On Thu, Aug 07, 2014 at 03:11:51PM +0200, Laurent Ciavaglia wrote:
> >>Thanks for your explanations. I have some rough thoughts as following, 
> >>which maybe already addressed by former discussion that I haven't 
> >>followed.
> >>
> >>1. The global features are unified, e.g., the node identities in 
> >>config-negotiation-protocol, bootstrapping-keyinfrastructures, and 
> >>autonomic-control-plane are exactly the same.
> >>2. The global features are covered in each specific mechanism, but they 
> >>might have different designs to respectively fit their goals more 
> >>sufficiently.
> >>Personally, I'm a little concerned that whether choice 1 could be 
> >>achieved in real design. May I ask your thoughts?
> >>
> >>Best regards,
> >>Bing
> >>  
> >>>>The "solutions" section is high level what needs to be covered. 
> >>>>Identity,
> >>>security, etc.

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 7 Aug 2014 16:28:35 +0200

Overall I think that we should provide more details on what is 
meant/covered by the list
o identity of nodes
o common security model
o discovery model
o negotiation model
o a secure and logically separated communications channel
o an example for an autonomic management model

how have these elements been selected (i.e. outcome of the gap analysis 
draft?), why are they important? and what are the design/operation 
implications behind those elements, how do they relate together (if they 
do)?

Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 7 Aug 2014 16:47:21 +0200

Toerless,

Sorry, not answering directly your question and adding more noise to 
this (interesting) discussion ;)

I think we are starting to touch on some design aspects with identity.
The question of identifiers is for me more of the level of 
solution/implementation (yet still important to understand and address).

Beyond the identity, we can relate the concept of policy/intent, and 
manifest (or descriptor) of the node/function capabilities (i.e. think 
also of the link with the "self-knowledge" in the model from 
draft-irtf-nmrg-autonomic-network-definitions).
     -policy/intent because even if we do not target individual 
nodes/functions, there is at some point the notion of area, group of 
entities that shall understand what has to be done to match the intent. 
In this process, something has to translate/target the area/group down 
to the individual nodes/functions.
     -manifest/descriptor because if we aim negotiating something among 
autonomic entities, there shall be a proper description of what (e.g. 
parameters, KPIs, capabilities) and what for (mission, purpose, 
objectives). this also applies for the other interactions/coordination 
among autonomic functions at run-time (i.e. ability to model, exchange 
and regulate a seamless interworking of multiple autonomic functions 
behaviors.

So, I know it is still early in the WG (pre-)life but the sooner we 
discuss and clarify/describe unambiguously those key elements, the 
better for the design phase of the protocols and solutions (as I wrote 
on the use cases and requirements: "unclear requirements, poor design 
(if not wrong)", same stands here, unclear concepts may lead us to 
partial/inappropriate design choices).

Regards, Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Thu, 7 Aug 2014 16:03:26 +0000

I agree with Laurent, having two separate documents would be more clear.
Thanks
Roberta
From: Anima [mailto:[email-masked]] On Behalf Of Laurent Ciavaglia
Sent: Thursday, August 07, 2014 3:17 PM
To: [email-masked]
Subject: Re: [Anima] ANIMA draft charter

Toerless,

I think it will be more clear for the future discussions to have two separate documents.

-----Original Message-----

Cc: [email-masked]<mailto:[email-masked]>

Hi Michael,

Use cases drafts are usually informational documents: any reasons to

propose this one as standard track?

own dog food).

Thanks, Brian

solution/technology.

even more:

What we showed:

     of larger topologies.

Cheers

    Toerless

Anima mailing list

[email-masked]<mailto:[email-masked]>

--

Laurent Ciavaglia

phone: +33 160 402 636
email: [email-masked]<mailto:[email-masked]>
linkedin: laurentciavaglia<http://fr.linkedin.com/in/laurentciavaglia/>
address: Route de Villejust | 91620 NOZAY | France

---

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

> Does only one use case could cover all key areas as defined below: 

I think there is a good chance, but analysis will be needed.

> I think 2-3 typical use cases may be better.

We are in fact proposing 2, this TBD case and the Autonomic
Control Plane case.

   Brian

---

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

On 08/08/2014 02:28, Laurent Ciavaglia wrote:
> draft?), why are they important?

I would say that they come partly from the gap analysis and partly from
some insights during solutions work (both by Huawei and Cisco). But this
could be integrated in the gap analysis draft, I think.

> and what are the design/operation

Those points are more on the solutions side IMHO.

   Brian

>>> Identity, security, etc.
>>> We could drop the first part, because it seems a bit redundant, but
>>> my worry is that as we modify the goals / deliverables we may miss
>>> one of the above points.
>>>
>>>> documents? But
> ------------------------------------------------------------------------
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 8 Aug 2014 07:18:24 +0000

Hi Toerless,

Please see replies inline.

> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Thursday, August 07, 2014 7:44 PM
> To: Liubing (Leo)
> Cc: Brian E Carpenter; Michael Behringer (mbehring); [email-masked]
> I am not sure what you imply with "exactly the same" in 1. Maybe you can
> give the most simple example where we are not doing it "exactly he same"
> and that you think might be useful ?
> 
> you want to make sure there is security and protection against
> errors/duplicate address/identity, and you end up creating a mapping to a
> more trustworthy identity.

> because all those packets within the ACP have been received via secured ACP
> channels, and that underlying channel is secured - with the secure node
> identity, eg: S-UDI.
> So i have an implicit mapping between S-UDI as the primary, secure node
> identity, and some protocol specific identity such as the IPv6 address it has
> inside the ACP.

[Bing] I also agree with that "identifier" should be a more proper word.
My own understanding is that "identifier" is just numbers; it is not clear to me whether we need something beyond numbers, for example, we could make "identity" relate to something such as role/capability/features .etc.
In this sense, I also consider the S-UDI as "identifier". But it is a device identifier than L2/L3 interface identifier.

> Does this match your "exatly the same" - or not ?
[Bing] Sorry for the ambiguous wording. Let me have a redundant explanation: some features in "solution" section of the charter might be common to all the three chartered documents/mechanisms (ACP, config-negotiation-protocol, and bootstrapping-keyinfrastructures). When I said "exactly the same", I meant the three mechanisms will share the same design of the common features (This is choice 1 in my previous mail). For example, assuming we choose S-UDI as the identity design, then ACP, negotiation-protocol and bootstrapping-keyinfrastructures would use exactly the same format and semantic of the S-UDI. 

Best regards,
Bing

> which maybe already addressed by former discussion that I haven't followed.
> >
> might have different designs to respectively fit their goals more sufficiently.
> > > that some features have global importance. I would expect that the
> > > documents will all have normative dependencies on the others, and it
> > > is part of the work to ensure that they are consistent.
> > >
> > >     Brian
> > >
> > > worry is that as we modify the goals / deliverables we may miss one
> > > of the above points.
> > > >
> > > >>>    Starting point:
> > > >>> draft-pritikin-bootstrapping-keyinfrastructures
> > > >> documents? But some of the items such as "identity of nodes"
> > > >> might be common issues, so I'm not sure whether the 3 documents
> > > >> could cover all the targeted solutions?
> > > >>
> > > >> Best regards,
> > > >> Bing
> > > >>
> > > >>> At the BoF in Toronto there was rough consensus to continue the
> > > >>> work on an autonomic infrastructure. Brian, Sheng, Toerless,
> > > >>> Laurent and I have now drafted a potential WG charter with the
> input of our ADs.
> > > >>> protocols such as OSPF. However, all such functions have their
> > > >>> own discovery, transport, messaging and security mechanisms.
> > > >>>
> > > >>> concrete, realisable requirements, the first stage, undertaken
> > > >>> in the Network Management Research Group (NMRG) of the IRTF,
> was
> > > >>> to define terminology and design goals, and to derive a
> > > >>> high-level gap
> > > analysis.
> > > >>> The definitions and design goals, as well as a simple
> > > >>> architecture model are defined in
> > > >>> draft-irtf-nmrg-autonomic-network-definitions;
> > > >>> 90 discussed use cases and some existing solutions. All the
> > > >>> above work serves as a baseline for this working group.
> > > >>>
> > > >>> components of an autonomic networking infrastructure, based on
> > > >>> the simple architecture and design goals defined in
> > > >>>    Starting point:
> > > >>> draft-pritikin-bootstrapping-keyinfrastructures
> > > >>> In addition, autonomic service agents will need to be defined
> > > >>> for specific use cases. The working group will initially
> > > >>> consider one simple example as a test case for further work.
> > > >>>
> > > >>> The initial set of work items is limited to the above list to
> > > >>> stay focused and avoid "boiling the ocean". Additional documents
> > > >>> concerning policy intent, other autonomic infrastructure
> > > >>> components, use cases or autonomic service agents are strongly
> > > >>> encouraged, as individual submissions, but are not planned as
> > > >>> working group deliverables for now. No additional work items
> > > >>> Aug 2015 - submit draft-generic-discovery-negotiation-protocol
> > > >>> to IESG (standards track) Oct 2015 - WGLC
> > > >>> Jan

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 8 Aug 2014 16:05:59 +0200

Dear all,

During some exchanges on ANIMA, a colleague of mine pointed out the 
following:
Quoting (with slight modifications):

    "Autonomic functions already exist today, for example IGP routing
    protocols such as OSPF."

    -This statement is discussable: I would have said OSPF is adaptive
    (from the current state only --not previous states- and by means of
    OSPF PDU's only) but certainly not autonomous (in the sense: it
    can't by itself tune its parameter space, in particular to operate
    in its current form OSPF requires that all parameters are identical
    in a given area).

    -Might be worth rephrasing "Limited versions of autonomic
    functions..." or
    "Partially autonomic functions..."

End of quote.

The overall argument being if the starting point of ANIMA (or conclusion 
from NMRG) is the statement that the routing system (one of the most 
prominent function) is already autonomic, then it might cut short 
several areas of work.

Thanks, Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

  * English - detected
  * English
  * French

  * English
  * French

<javascript:void(0);>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 8 Aug 2014 14:30:25 +0000

Hi, Toerless,

Yes, two separated document would be much more clearer. However, the use case description documents was mainly for BoF discussion purpose. For the potential WG, I don't think an informational use case document would be included as a milestone.

So, the best way may be to reorganize the document: start from the description as an use case, then explain the technical requirements, then design logic for a solution, at the end it is the necessary protocol extensions. 

Best regards,

Sheng

>From: Anima [mailto:[email-masked]] On Behalf Of Toerless Eckert
>Sent: Thursday, August 07, 2014 8:05 PM
>To: Brian E Carpenter
>Cc: Roberta Maglione (robmgl); [email-masked]; Michael Behringer (mbehring)
>> > Thanks for your support Roberta. I wouldn't read too much into the details
>at this point ;-) There are a number of things to look. A use case could be
>either an informative description how an autonomic service agent acts, using
>standard protocols; in which case it would be informational; if it requires
>some protocol extension or similar, there may be some standards track
>involved as well. We'll see once we have the use case clear.
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Aug 2014 08:01:44 +1200

Laurent,

I think we already discussed the point that our aim is not to
aim for something like mathematical perfection where every autonomic
device meets every criterion for autonomic behaviour. Maybe this needs
to be explicit in the charter? In any case I would slightly rewrite
the first paragraph:

Autonomic Networking focuses on self-management of network elements.
An autonomic function works in a distributed way across various network
elements, but allowing central guidance and reporting, and co-existence
with non-autonomic methods of management. Elements of autonomic functions
already exist today, for example IGP routing protocols such as OSPF.
However, all such functions have their own discovery, transport, messaging
and security mechanisms as well as non-autonomic management interfaces.

    Brian

On 09/08/2014 02:05, Laurent Ciavaglia wrote:
>> draft-irtf-nmrg-an-gap-analysis. The UCAN BoF at IETF 90 discussed use
>> cases and some existing solutions. All the above work serves as a
>> baseline for this working group.
>>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 8 Aug 2014 23:46:41 +0000

The running of OSPF is autonomic. But the initial configuration process of OSPF is not autonomic, yet. This should be clearly distinguished in the example description. Maybe, we could modified the text to be more precise:

"Elements of autonomic functions already exist today, for example IGP routing protocols such as OSPF (although the initial configuration process of OSPF is not autonomic, yet.)"

Regards,

Sheng
________________________________________
From: Anima [[email-masked]] on behalf of Brian E Carpenter [[email-masked]]
Sent: 09 August 2014 4:01
To: Laurent Ciavaglia
Cc: [email-masked]
Subject: Re: [Anima] About OSPF // ANIMA draft charter

Laurent,

    Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 12 Aug 2014 11:38:58 +0200

Hi Brian,

Yes, I think this needs to be explicit, and the proposed rephrasing is fine.

To clear out some possible misunderstandings, the issue is not to aim 
for perfect autonomic mechanisms, but to capture that there are 
different autonomic properties (and levels) and to clearly state which 
of those will be covered by the work in ANIMA in a first phase (with 
potential for more in the future if success/support/interest).

My current understanding is that ANIMA is looking to solve initial 
configuration and secure bootstrapping problems and to make them 
automatic/autonomic.
This is fine - but - this is not touching at the self-healing, 
self-optimizing, learning... properties of an autonomic system.

If, rightfully, we aim to set the scope of ANIMA to "only" the 
(self-)configuration aspect, again this is fine, but should be made 
explicit in the charter, and we should check if there is enough support 
in the community to work on this single aspect.

Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 12 Aug 2014 11:44:14 +0200

Sheng,

OSPF has a certain level of self-healing (i.e. ensure a routable 
topology in case of failure), however, OSPF is not capable of adapting 
its parameters to different contexts.
A lot can be done to augment/enhance the routing protocols with more 
autonomic properties. This as the point made below.

Beyond that, I agree with you that the initial configuration can also be 
improved (and generalized to other protocols), i.e. the goal of the 
discovery and negotiation draft.

Regards, Laurent.

-- 

*Laurent Ciavaglia*

phone: +33 160 402 636