Subject: [Anima] Select Use cases for charter

From: Sheng Jiang <[email-masked]>
Date: Fri, 22 Aug 2014 05:44:04 +0000

Hi, all,

In order to complete our anima draft charter, we need to choose two more use cases. Currently, they are still in the form of placeholder in the draft charter, as below.

  o Definition of solutions for one or two selected use cases
    Starting points: draft-use-case-tbd1&2

  Apr 2015 - adoption of draft-use-case-solution-tbd1&2
  Oct 2015 - WGLC draft-use-case-solution-tbd1&2
  Dec 2015 - submit draft-use-case-solution-tbd1&2 to IESG

Our OPS ADs suggested that the two use cases should be specifically called out in the charter.

For now, we have the below use cases besides autonomic bootstrap and autonomic control plane that are already included in the draft charter. Since we need to make decision in around 10 days, it may be late for new use cases. It is better that we limit our selection from only the existing use cases.

 - Home networks
 - Assign IPv6 prefixes
 - Assign IPv4 pools
 - Detection of SLA Violations
 - Microwave Mobile Backhaul
 - Risk Aware Routing

We also have some selection criteria, as below. (Note: the selection criteria is mainly for distinguish use cases. They are different from requirements)

 - Operator interest
 - Distributed function is necessary or useful
 - Share infrastructure (dependency on/by other AN functions)
 - Simple to implement (easier to get started)

Ideally, the selected use cases should use AN infrastructure components, such as generic discovery/negotiation protocol or autonomic control plane. One more potential criteria is to give priority to the use cases that affect many or all networks.

Best regards,

Sheng

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 22 Aug 2014 08:19:06 +0000

o) I have sent comments y'day on the current version of the charter. I have put them here below 
to initiate discussion on the list (instead of conf.calls via Webex) concerning the current state on the charter which still requires major rework.

o) I have an additional comment (related to point 3) here below) concerning cross-fertilization which is part of the old truths of IETF not reflected throughout this BoF group --why statements like "It is better that we limit our selection from only the existing use cases." From when there is prescription that the work should be limited to what has been initially realized beforehand ?

o) Practically speaking, the use case set should include in my opinion: 

- Path (segment) monitoring: this concerns all monitoring probes configuration (sampling rate) and placement inline with the routing decision (and it would be interesting to confront how autonomics would help automating/adapting such task with current practices).

- Traffic anomaly detection, routing anomalies detection (diagnostic out of a large set of information) which could help configuring ACL, routing adjacencies or others.

- AQM parameters (re)configuration out of traffic measure 

- Shared risk (hidden risk) detection out of routing/topological information analysis, the output of such process should prevent that protecting routing path fail together with their primary path or that an alternate path fails right after its selection due to delay in propagation of routing information.

- Instead of bringing big words like SLA, consider a simple process by which the bandwidth x delay of running path segments could be measured and estimated in order to anticipate possible effects out of outages.

-----

The charter still requires (re)work in my opinion:

- it doesn't state the overall objective of this effort, neither motivates it appropriately (what does it solve ? what's missing today ? what are the "operational" burdens it aims at addressing ? etc.)

- assuming OPS area doesn't put major focus on architecture itself but on functionality, the question stems as of why the "solution target" section of the charter is mostly about protocol machinery (discovery, negotiation, etc.) and not on the functionality each of the use cases would provide/solve (or more efficiently than we could today by other means) 

- why the charter lists starting point documents next to each of the goals ? it reads as if focus is on validating these protocols but it should work the other around (essence of the previous point). This being said the two first documents have never been discussed so why consider them as starting point ? --note: for the third one, see comment below. 

- the charter states "Definition of a solution for a separated Autonomic Control Plane" why from the start the architectural decision is to have a "separated" control plane ? and separated from what (to start with) ? Again if OPS area is not focusing on architecture why all these architectural decisions have to be carved in stone in the charter ? shouldn't they be documented at the end (as part of the last work item of the charter) instead of the beginning ?

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Friday, August 22, 2014 7:44 AM
> To: [email-masked]
> Subject: [Anima] Select Use cases for charter
> 
> Hi, all,
> 
> In order to complete our anima draft charter, we need to choose two more
> use cases. Currently, they are still in the form of placeholder in the
> draft charter, as below.
> 
> For now, we have the below use cases besides autonomic bootstrap and
> autonomic control plane that are already included in the draft charter.
> Since we need to make decision in around 10 days, it may be late for new
> use cases. It is better that we limit our selection from only the existing
> use cases.
> 
>  - Home networks
>  - Assign IPv6 prefixes
>  - Assign IPv4 pools
> We also have some selection criteria, as below. (Note: the selection
> criteria is mainly for distinguish use cases. They are different from
> requirements)
> 
>  - Operator interest
> Ideally, the selected use cases should use AN infrastructure components,
> such as generic discovery/negotiation protocol or autonomic control plane.
> One more potential criteria is to give priority to the use cases that
> affect many or all networks.
> 
> Best regards,
> 
> Sheng
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Fri, 22 Aug 2014 08:27:33 +0000

-----

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 22 Aug 2014 10:11:50 +0000

Hi Sheng & All,

>  - Microwave Mobile Backhaul

I basically agree with Brian's use case analysis (check the mail on Aug 10th). Among the above use cases, "Assign IPv6 prefixes" seems to fit all the criteria. 
I think it is a very basic operation in a network. And since we already have DHCP-PD to convey the prefixes assignment, what we need might be some "glue" approaches which could utilize the Discovery/Negotiation protocol or Autonomic Control Plane.

Besides above use case, if we allow another, I'd prefer the Home networks. Because I think the home networks has been very clear on requirements. 
Nevertheless, according to yesterday's tele-conf, I heard someone said the home networks use case had caused a lot trouble? I wasn't in Toronto for Anima BoF, so please pardon me if I kicked the trouble again.

Best regards,
Bing

> Sent: Friday, August 22, 2014 1:44 PM
> To: [email-masked]
> use cases. Currently, they are still in the form of placeholder in the draft
> charter, as below.
> 
> autonomic control plane that are already included in the draft charter. Since
> we need to make decision in around 10 days, it may be late for new use
> cases. It is better that we limit our selection from only the existing use cases.
> 
>  - Home networks
>  - Assign IPv6 prefixes
>  - Assign IPv4 pools
> We also have some selection criteria, as below. (Note: the selection criteria
> is mainly for distinguish use cases. They are different from requirements)
> 
>  - Operator interest
> One more potential criteria is to give priority to the use cases that affect
> many or all networks.
> 
> Best regards,
> 
> Sheng

---

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

> Nevertheless, according to yesterday's tele-conf, I heard someone said the home networks use case had caused a lot trouble? I wasn't in Toronto for Anima BoF, so please pardon me if I kicked the tr…

Well, there are three aspects to that:

1. I messed up my short presentation of the use case. I didn't make
it clear that it was not a plan to attack homenet's existing work,
but instead a clearly defined problem area that obviously needs to
be self-managing, and therefore an ideal test case for AN ideas.

2. It is actually quite complex with many separate aspects. So
personally I don't think it's a good use case for initial solutions
work - we would have to split it up into many separate pieces.

3. And finally, by the time we are ready (Dec 2015 proposed
in the charter) I really hope that Homenet will have finished
their work on HNCP already. We would be too late.

So I'm going to disagree with Bing on this one.

I'd like people to make critical comments on my spreadsheet
comparing the use cases. One person's opinion isn't sufficient,
and I didn't fill in all the squares. I also think that one or two
other use cases would still be useful.

    Brian

---

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

On 22/08/2014 20:19, Papadimitriou, Dimitri (Dimitri) wrote:
...
> - Instead of bringing big words like SLA, consider a simple process by which the bandwidth x delay of running path segments could be measured and estimated in order to anticipate possible effects o…

That's great. Could you put together a quick draft (or 5 separate drafts, but
that seems a bit silly) expanding on each of these? The headings we
used in the previous set of use case drafts are not of course binding,
but looked like this:

Problem Statement
Intended User and Administrator Experience
Analysis of Parameters and Information Involved:
  Parameters each device can decide for itself
  Information needed from policy intent
Interaction with other devices:
  Information needed from other device
  Monitoring, diagnostics and reporting
Comparison with current solutions

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 22 Aug 2014 23:31:21 +0000

Hi, Dimitri and all,

It looks for me that there is a misunderstanding for selecting use cases. It has been consensus that in the early stage of anima WG (if we successfully form it), we will focus on an common infrastructure for autonomic network. And we just need one or two simple use cases to demonstrate the usage of the common AN infrastructure. The other AN use cases, even new AN use cases in the future are still in the scope. But we will not include them in the initial charter (since we won't have enough energe to biol the ocean). Since the work item in the charter means we MUST deliver them.

I think your suggested use cases are valuable and in the scope. But they looks not simple to solve them. First, we need details, probably in a written draft, analysis to understand and evaluate. Then, we need to make sure somebody are willing to work on solution to solve them and promise to deliver solution in time. So far, we do NOT have these to consider your suggested use cases, yet. We need to make choice in short time in order to get the WG start. However, as I explained, they are in the general scope of AN. We could still discuss them in the WG and may take them on board in later stage. 

Best regards,

Sheng

________________________________________
From: Anima [[email-masked]] on behalf of Papadimitriou, Dimitri (Dimitri) [[email-masked]]
Sent: 22 August 2014 16:27
To: [email-masked]
Subject: Re: [Anima] Select Use cases for charter

-----

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 23 Aug 2014 01:04:24 +0000

My goal is to synthesize a 5 page doc (one per use case), with references including work realized involving closed-loop adaptive control/multi-agent control/etc. and for most the information elements are available. 

--The exception is what you refer as information needed from "policy intent" as it still not clear to me in which sense these words are used: in the common sense a policy is a mapping from state to action whereas an intent (from Webster) is defined as 'the thing you plan to do or achieve: an aim or purpose', so do you mean "lookahead policies" (as considered in model-predictive control, rolling horizon, etc.) or something else ? note here that the IRTF document mentions "intent: an abstract high level policy..." thus not sure I would be able to put the pieces altogether.

This being said, over past years (and decades) numerous effort have worked on similar topics/cases but most of them aimed at evaluating potential gain, validating underlying procedures/algorithms, etc. but not (necessarily) the underlying "system design". As the high level outline of this design has just been issued, it shouldn't come at a surprise that I consider such cross-validation as work to be realized (modalities and timeline should be lined up accordingly).

Last point, I see the charter refers to "solution", may be "evaluation" could be more inline with type of work to be conducted.

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, August 22, 2014 10:34 PM
> To: Papadimitriou, Dimitri (Dimitri)
> Cc: Sheng Jiang; [email-masked]
> > - Path (segment) monitoring: this concerns all monitoring probes
> configuration (sampling rate) and placement inline with the routing
> decision (and it would be interesting to confront how autonomics would
> help automating/adapting such task with current practices).
> >
> > - Traffic anomaly detection, routing anomalies detection (diagnostic out
> of a large set of information) which could help configuring ACL, routing
> adjacencies or others.
> >
> > - Shared risk (hidden risk) detection out of routing/topological
> information analysis, the output of such process should prevent that
> protecting routing path fail together with their primary path or that an
> alternate path fails right after its selection due to delay in propagation
> of routing information.
> >
> > - Instead of bringing big words like SLA, consider a simple process by
> which the bandwidth x delay of running path segments could be measured and
> estimated in order to anticipate possible effects out of outages.
> 
> That's great. Could you put together a quick draft (or 5 separate drafts,
> but that seems a bit silly) expanding on each of these? The headings we
> used in the previous set of use case drafts are not of course binding, but
> looked like this:
> 
> Problem Statement
> Intended User and Administrator Experience Analysis of Parameters and
> Information Involved:

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Aug 2014 14:28:02 +1200

> --The exception is what you refer as information needed from "policy intent" as it still not clear to me in which sense these words are used: in the common sense a policy is a mapping from state to…

I think Michael needs to comment on this. It is a question of what
we mean by the word "policy" I guess. In BGP-4 for example,
"filter out all /24s from APNIC space" might be considered an intent but
"filter out 123.123.123.0/24" might be considered a specific policy.
I'm not sure there is anything more subtle than that.

Regards
   Brian

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 23 Aug 2014 10:46:13 +0000

> Sent: Saturday, August 23, 2014 4:28 AM
> > --The exception is what you refer as information needed from "policy
> intent" as it still not clear to me in which sense these words are used:
> in the common sense a policy is a mapping from state to action whereas an
> intent (from Webster) is defined as 'the thing you plan to do or achieve:
> an aim or purpose', so do you mean "lookahead policies" (as considered in
> model-predictive control, rolling horizon, etc.) or something else ? note
> here that the IRTF document mentions "intent: an abstract high level
> policy..." thus not sure I would be able to put the pieces altogether.
> 
> I think Michael needs to comment on this. It is a question of what we mean
> by the word "policy" I guess. In BGP-4 for example, "filter out all /24s
> from APNIC space" might be considered an intent but "filter out
> 123.123.123.0/24" might be considered a specific policy.

On the other hand, one could see it as a scoped objective "minimize memory space consumed by the routing entries to route to APNIC" (rather than a global objective which would state "minimize memory space consumed by routing entries"). Then service agents deciding to "filter out all /24s from APNIC space". 

In between the lines, it boils down to the question which entity decides out of the feasible class of actions (service agents via negotiation, vs. central entity); note if it is the latter it's coming very close to the DMTF/Policy-based management framework (of the early 2000's).

Thanks,
-d.
> > My goal is to synthesize a 5 page doc (one per use case), with
> references including work realized involving closed-loop adaptive
> control/multi-agent control/etc. and for most the information elements are
> available.
> >
> > --The exception is what you refer as information needed from "policy
> intent" as it still not clear to me in which sense these words are used:
> in the common sense a policy is a mapping from state to action whereas an
> intent (from Webster) is defined as 'the thing you plan to do or achieve:
> an aim or purpose', so do you mean "lookahead policies" (as considered in
> model-predictive control, rolling horizon, etc.) or something else ? note
> here that the IRTF document mentions "intent: an abstract high level
> policy..." thus not sure I would be able to put the pieces altogether.
> >
> > This being said, over past years (and decades) numerous effort have
> worked on similar topics/cases but most of them aimed at evaluating
> potential gain, validating underlying procedures/algorithms, etc. but not
> (necessarily) the underlying "system design". As the high level outline of
> this design has just been issued, it shouldn't come at a surprise that I
> consider such cross-validation as work to be realized (modalities and
> timeline should be lined up accordingly).
> >
> > Last point, I see the charter refers to "solution", may be "evaluation"
> could be more inline with type of work to be conducted.
> >
> >> decision (and it would be interesting to confront how autonomics
> >> would help automating/adapting such task with current practices).
> >> of a large set of information) which could help configuring ACL,
> >> routing adjacencies or others.
> >> protecting routing path fail together with their primary path or that
> >> an alternate path fails right after its selection due to delay in
> >> propagation of routing information.
> >> which the bandwidth x delay of running path segments could be
> >> measured and estimated in order to anticipate possible effects out of
> outages.
> >>
> >> That's great. Could you put together a quick draft (or 5 separate
> >> drafts, but that seems a bit silly) expanding on each of these? The
> >> headings we used in the previous set of use case drafts are not of
> >> course binding, but looked like this:
> >>
> >> Problem Statement
> >>   Information needed from policy intent Interaction with other
> >> devices:
> >>   Monitoring, diagnostics and reporting Comparison with current
> >> solutions
> >>
> >>    Brian
> >

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 23 Aug 2014 12:58:01 +0000

I have checked mailing list and minutes out of the first BoF. The statement "It has been consensus that in the early stage of anima WG (if we successfully form it)... we just need one or two simple use cases to demonstrate the usage of the common AN infrastructure. The other AN use cases, even new AN use cases in the future are still in the scope. But we will not include them in the initial charter." can't be valid as there is no trace of consensus reached on this point (neither call for consensus from the chairs on the mailing list). 

All the contrary: the minutes of the BoF state "Chair asked for submissions of new use cases" reading behind this statement i) existing use cases would be insufficient to motivate this effort and its objective of commonality (are they sufficiently representative ? how many do we need ?), and ii) trying increase involvement (20 out of the 200 participants to the BoF raising hands when it comes to contribution).

This group would be well advised to see first what's on the table and see which use cases could help this goal, and which would be seen as involving source of information/processes which might not be commonly available to make their trialing and deployment possible in a shorter term (and possibly team up with NMRG).

Note: the statement in current version of the charter "stay focused and avoid boiling the ocean" and what comes thereafter has anyway to be replaced by a technically objective statement.

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Saturday, August 23, 2014 1:31 AM
> To: Papadimitriou, Dimitri (Dimitri); [email-masked]
> Subject: RE: Select Use cases for charter
> 
> Hi, Dimitri and all,
> 
> It looks for me that there is a misunderstanding for selecting use cases.
> It has been consensus that in the early stage of anima WG (if we
> successfully form it), we will focus on an common infrastructure for
> autonomic network. And we just need one or two simple use cases to
> demonstrate the usage of the common AN infrastructure. The other AN use
> cases, even new AN use cases in the future are still in the scope. But we
> will not include them in the initial charter (since we won't have enough
> energe to biol the ocean). Since the work item in the charter means we
> MUST deliver them.
> 
> I think your suggested use cases are valuable and in the scope. But they
> looks not simple to solve them. First, we need details, probably in a
> written draft, analysis to understand and evaluate. Then, we need to make
> sure somebody are willing to work on solution to solve them and promise to
> deliver solution in time. So far, we do NOT have these to consider your
> suggested use cases, yet. We need to make choice in short time in order to
> get the WG start. However, as I explained, they are in the general scope
> of AN. We could still discuss them in the WG and may take them on board in
> later stage.
> 
> Best regards,
> 
> Sheng
> 
> From: Anima [[email-masked]] on behalf of Papadimitriou, Dimitri
> (Dimitri) [[email-masked]]
> o) I have sent comments y'day on the current version of the charter. I
> have put them here below to initiate discussion on the list (instead of
> conf.calls via Webex) concerning the current state on the charter which
> still requires major rework.
> 
> o) I have an additional comment (related to point 3) here below)
> concerning cross-fertilization which is part of the old truths of IETF not
> reflected throughout this BoF group --why statements like "It is better
> that we limit our selection from only the existing use cases." From when
> there is prescription that the work should be limited to what has been
> initially realized beforehand ?
> 
> - it doesn't state the overall objective of this effort, neither motivates
> it appropriately (what does it solve ? what's missing today ? what are the
> "operational" burdens it aims at addressing ? etc.)
> 
> - assuming OPS area doesn't put major focus on architecture itself but on
> functionality, the question stems as of why the "solution target" section
> of the charter is mostly about protocol machinery (discovery, negotiation,
> etc.) and not on the functionality each of the use cases would
> provide/solve (or more efficiently than we could today by other means)
> 
> - why the charter lists starting point documents next to each of the goals
> ? it reads as if focus is on validating these protocols but it should work
> the other around (essence of the previous point). This being said the two
> first documents have never been discussed so why consider them as starting
> point ? --note: for the third one, see comment below.
> 
> - the charter states "Definition of a solution for a separated Autonomic
> Control Plane" why from the start the architectural decision is to have a
> "separated" control plane ? and separated from what (to start with) ?
> Again if OPS area is not focusing on architecture why all these
> architectural decisions have to be carved in stone in the charter ?
> shouldn't they be documented at the end (as part of the last work item of
> the charter) instead of the beginning ?
> 
> > In order to complete our anima draft charter, we need to choose two
> > more use cases. Currently, they are still in the form of placeholder
> > in the draft charter, as below.
> >
> > Since we need to make decision in around 10 days, it may be late for
> > new use cases. It is better that we limit our selection from only the
> > existing use cases.
> >
> >  - Home networks
> >  - Assign IPv6 prefixes
> >  - Assign IPv4 pools
> > Ideally, the selected use cases should use AN infrastructure
> > components, such as generic discovery/negotiation protocol or autonomic
> control plane.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Aug 2014 08:38:39 +1200

> I have checked mailing list and minutes out of the first BoF. The statement "It has been consensus that in the early stage of anima WG (if we successfully form it)... we just need one or two simple…

It's a draft charter, not a consensus statement yet. That's why we're discussing it here ;-)

> All the contrary: the minutes of the BoF state "Chair asked for submissions of new use cases" reading behind this statement i) existing use cases would be insufficient to motivate this effort and i…

You're reading more into it that was in my mind as a BOF co-chair.

> This group would be well advised to see first what's on the table and see which use cases could help this goal, and which would be seen as involving source of information/processes which might not…

Well yes: if you'd like us to set a firm deadline for use case proposals
we can do so, but I'm not sure why we would do that. Of course we need
firm deadlines for submitting a charter to the ADs and submitting
a request for a meeting slot at the next IETF, and we have proposed
those dates.

> Note: the statement in current version of the charter "stay focused and avoid boiling the ocean" and what comes thereafter has anyway to be replaced by a technically objective statement.

I disagree. A statement like that is perhaps redundant - it should apply
to every WG, after all - but refer to particular risks for this topic. The
technically objective statements are the deliverables and milestones.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 23 Aug 2014 23:24:34 +0000

Dimitri>> Note: the statement in current version of the charter "stay focused and avoid boiling the ocean" and what >comes thereafter has anyway to be replaced by a technically objective statement.
Brian>I disagree. A statement like that is perhaps redundant - it should apply
>technically objective statements are the deliverables and milestones.

Agree with Brian. Actually, "too wide, not focus" and "do not boil the ocea" were the most montioned comments during the IETF week regarding to our Autonomic Network. From our OPS ADs, we need an explicit focus to initiate a WG and deliver the milestones. Focusing on an common infrastructure for autonomic network is the result among BoF proponents.

More use cases and their solutions will be more than welcome, of course. But at this stage, it does not help to convience OPS ADs and IESG that we have clear focus and will deliver the milestones. If we successfully formed a WG, use cases regarding to Autonomic Network should be in scope to be discussed and may be adopted in later stage. I guess we could add some clarifying text into the draft charter.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 23 Aug 2014 23:44:15 +0000

HI, Bing,

Please see my replies in lines.
_______________________________________
>From: Liubing (Leo)
>Sent: 22 August 2014 18:11
>To: Sheng Jiang; [email-masked]
>I basically agree with Brian's use case analysis (check the mail on Aug 10th). Among the above use cases, >"Assign IPv6 prefixes" seems to fit all the criteria.
>I think it is a very basic operation in a network. And since we already have DHCP-PD to convey the >prefixes assignment, what we need might be some "glue" approaches which could utilize the >Discovery/Negotiation protocol or Autonomic Control Plane.

To be accurate, the use case should be "autonomically manage IPv6 prefix in large networks" rather than "Assign IPv6 prefix", which can already do by DHCP-PD.

I agree it is the best fitted use case for our criteria. It is simple, fundamental and has clear carrier interests. The only thing we need is to make sure the solution use either Discovery/Negotiation protocol or autonomic control plane. Personally, I see no problem to combine them together.

>Besides above use case, if we allow another, I'd prefer the Home networks. Because I think the home >networks has been very clear on requirements.
>Nevertheless, according to yesterday's tele-conf, I heard someone said the home networks use case had >caused a lot trouble? I wasn't in Toronto for Anima BoF, so please pardon me if I kicked the trouble again.

It was me who said home network had caused a lot trouble and should be ruled out first. HomeNet WG has just developed their own control protocols. We would not want any overlap with their ongoing work. This has been discussed and made very clear during IETF week, mostly by discussion among BoF chairs, OPS ADs and HomeNet chairs.

Best regards,

Sheng

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sun, 24 Aug 2014 09:53:05 +0000

> > This group would be well advised to see first what's on the table and
> see which use cases could help this goal, and which would be seen as
> involving source of information/processes which might not be commonly
> available to make their trialing and deployment possible in a shorter term
> (and possibly team up with NMRG).
> 
> we can do so, but I'm not sure why we would do that. 

Referring to the title of this email (and what I understood out of your email of Aug.7/<www.ietf.org/mail-archive/web/anima/current/msg00093.html>) if use cases would be precisely recorded in the charter then a call for use case and selection period should be considered (with a consensus call).

My preference: list a set of (sub-)domains of potential applicability (out of the (to be) documented use cases) and leave collection of evaluation results at drafting time (2H 2015). As long as one representative per (sub-)domain can be identified at starting time, this would lead to a more robust charter and enable to accommodate additional results without having to modify it. 

> Of course we need
> firm deadlines for submitting a charter to the ADs and submitting a
> request for a meeting slot at the next IETF, and we have proposed those
> dates.
>
> > Note: the statement in current version of the charter "stay focused and
> avoid boiling the ocean" and what comes thereafter has anyway to be
> replaced by a technically objective statement.
> 

What I mean is a set of documents is a necessary but not sufficient condition to determine the objective is reached; the charter would better state the process/means foreseen to provide evidences we have "boiled the lake" at the end of the evaluation phase. In other terms there could be something missing in between Dec.2015 and 1H 2016.

> >> demonstrate the usage of the common AN infrastructure. The other AN
> >> use cases, even new AN use cases in the future are still in the
> >> scope. But we will not include them in the initial charter (since we
> >> won't have enough energe to biol the ocean). Since the work item in
> >> the charter means we MUST deliver them.
> >>
> >> I think your suggested use cases are valuable and in the scope. But
> >> they looks not simple to solve them. First, we need details, probably
> >> in a written draft, analysis to understand and evaluate. Then, we
> >> need to make sure somebody are willing to work on solution to solve
> >> them and promise to deliver solution in time. So far, we do NOT have
> >> these to consider your suggested use cases, yet. We need to make
> >> choice in short time in order to get the WG start. However, as I
> >> explained, they are in the general scope of AN. We could still
> >> discuss them in the WG and may take them on board in later stage.
> >>
> >> Best regards,
> >>
> >> Sheng
> >>
> >> o) I have sent comments y'day on the current version of the charter.
> >> I have put them here below to initiate discussion on the list
> >> (instead of conf.calls via Webex) concerning the current state on the
> >> charter which still requires major rework.
> >>
> >> concerning cross-fertilization which is part of the old truths of
> >> IETF not reflected throughout this BoF group --why statements like
> >> "It is better that we limit our selection from only the existing use
> >> cases." From when there is prescription that the work should be
> >> limited to what has been initially realized beforehand ?
> >>
> >> - Traffic anomaly detection, routing anomalies detection (diagnostic
> >> out of a large set of information) which could help configuring ACL,
> >> - Instead of bringing big words like SLA, consider a simple process
> >> by which the bandwidth x delay of running path segments could be
> >> - it doesn't state the overall objective of this effort, neither
> >> motivates it appropriately (what does it solve ? what's missing today
> >> ? what are the "operational" burdens it aims at addressing ? etc.)
> >>
> >> - assuming OPS area doesn't put major focus on architecture itself
> >> but on functionality, the question stems as of why the "solution
> >> target" section of the charter is mostly about protocol machinery
> >> (discovery, negotiation,
> >> - why the charter lists starting point documents next to each of the
> >> goals ? it reads as if focus is on validating these protocols but it
> >> should work the other around (essence of the previous point). This
> >> being said the two first documents have never been discussed so why
> >> consider them as starting point ? --note: for the third one, see
> comment below.
> >>
> >> - the charter states "Definition of a solution for a separated
> >> Autonomic Control Plane" why from the start the architectural
> >> decision is to have a "separated" control plane ? and separated from
> what (to start with) ?
> >> shouldn't they be documented at the end (as part of the last work
> >> item of the charter) instead of the beginning ?
> >>
> >>> new use cases. It is better that we limit our selection from only
> >>> the existing use cases.
> >>>
> >>>  - Home networks
> >>>  - Assign IPv6 prefixes
> >>>  - Assign IPv4 pools
> >>> One more potential criteria is to give priority to the use cases
> >>> that affect many or all networks.
> >>>
> >>> Best regards,
> >>>
> >>> Sheng

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Sun, 24 Aug 2014 20:41:30 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 22 August 2014 20:28
> Cc: [email-masked]; Sheng Jiang
> intent" as it still not clear to me in which sense these words are used: in the
> common sense a policy is a mapping from state to action whereas an intent
> (from Webster) is defined as 'the thing you plan to do or achieve: an aim or
> purpose', so do you mean "lookahead policies" (as considered in model-
> predictive control, rolling horizon, etc.) or something else ? note here that
> the IRTF document mentions "intent: an abstract high level policy..." thus
> not sure I would be able to put the pieces altogether.
> 
> by the word "policy" I guess. In BGP-4 for example, "filter out all /24s from
> APNIC space" might be considered an intent but "filter out

For reference, this is what draft-irtf-nmrg-autonomic-network-definitions-02 states about intent: 

   Intent: An abstract, high level policy used to operate the network
   autonomically.  Its scope is an autonomic domain, such as an
   enterprise network.  It does not contain configuration or information
   for a specific node (see Section 3.2 on how intent co-exists with
   alternative management paradigms).  It may contain information
   pertaining to nodes with a specific role.

To respond to Dimitri's comment, what we had in mind when we came up with the notion of "intent" is indeed the Webster definition above. Intent defines the "aim or purpose" of the network, rather than individual actions to achieve those. Each element receives intent, and takes it as the "aim" that the admin has defined for the network. My favourite example is "this network has guestnet". Which is a general aim. Each network element needs to translate this into specific actions that will result in the aim stated in intent. 

We didn't want to re-use the word "policy", because there are plenty of policy languages that are setting detailed local variables. "aim or purpose of the network" is what we were after. 

Does this description make sense? Maybe we should then re-phrase the above definition to 

   Intent: An abstract, high level policy defining the aim or overall purpose
   of the network. (rest unchanged)

Is that better? If the above rough description makes sense, how can we define it better? Please provide suggestions, happy to incorporate in the next version of the definitions draft. 

Michael

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sun, 24 Aug 2014 21:22:13 +0000

As "Each network element needs to translate this into specific actions that will result in the aim stated in intent." the mapping (translation) from state to actions is left locally at the node level, which is the most general definition of policy. 

Hence, in the definition of intent, instead of referring to "high-level policy" you could refer to "high-level objective". This would avoid overloading the term policy and would settle a clearer demarcation line with DMTF/policy-based management models which uses different level of policies (high-/low-level, network/node-specific, etc.).

Thanks,
-d.

> From: Michael Behringer (mbehring) [mailto:[email-masked]]
> Sent: Sunday, August 24, 2014 10:42 PM
> To: Brian E Carpenter; Papadimitriou, Dimitri (Dimitri)
> Subject: RE: [Anima] Select Use cases for charter
> 
> > intent" as it still not clear to me in which sense these words are
> > used: in the common sense a policy is a mapping from state to action
> > whereas an intent (from Webster) is defined as 'the thing you plan to
> > do or achieve: an aim or purpose', so do you mean "lookahead policies"
> > (as considered in model- predictive control, rolling horizon, etc.) or
> > something else ? note here that the IRTF document mentions "intent: an
> > abstract high level policy..." thus not sure I would be able to put the
> pieces altogether.
> >
> > I think Michael needs to comment on this. It is a question of what we
> > mean by the word "policy" I guess. In BGP-4 for example, "filter out
> > all /24s from APNIC space" might be considered an intent but "filter
> > out 123.123.123.0/24" might be considered a specific policy.
> To respond to Dimitri's comment, what we had in mind when we came up with
> the notion of "intent" is indeed the Webster definition above. Intent
> defines the "aim or purpose" of the network, rather than individual
> actions to achieve those. Each element receives intent, and takes it as
> the "aim" that the admin has defined for the network. My favourite example
> is "this network has guestnet". Which is a general aim. Each network
> element needs to translate this into specific actions that will result in
> the aim stated in intent.
> 
> We didn't want to re-use the word "policy", because there are plenty of
> policy languages that are setting detailed local variables. "aim or
> purpose of the network" is what we were after.
> 
> Is that better? If the above rough description makes sense, how can we
> define it better? Please provide suggestions, happy to incorporate in the
> next version of the definitions draft.
> 
> Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2014 10:53:19 +1200

Yes. If I was king, the word "policy" would be forbidden in the
IETF, because it has so many possible interpretations.

Regards
   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 25 Aug 2014 07:12:30 +0000

Hi Brian & Sheng,

Thanks for your detailed explanation, now I'm clear on the Homenet use case situation.

Regards,
Bing

> Sent: Saturday, August 23, 2014 4:23 AM
> To: Liubing (Leo)
> > I basically agree with Brian's use case analysis (check the mail on Aug 10th).
> Among the above use cases, "Assign IPv6 prefixes" seems to fit all the
> criteria.
> > I think it is a very basic operation in a network. And since we already have
> DHCP-PD to convey the prefixes assignment, what we need might be some
> "glue" approaches which could utilize the Discovery/Negotiation protocol or
> Autonomic Control Plane.
> >
> > Besides above use case, if we allow another, I'd prefer the Home networks.
> Because I think the home networks has been very clear on requirements.
> > Nevertheless, according to yesterday's tele-conf, I heard someone said the
> home networks use case had caused a lot trouble? I wasn't in Toronto for
> Anima BoF, so please pardon me if I kicked the trouble again.
> 
> 1. I messed up my short presentation of the use case. I didn't make it clear
> that it was not a plan to attack homenet's existing work, but instead a clearly
> defined problem area that obviously needs to be self-managing, and
> therefore an ideal test case for AN ideas.
> 
> 2. It is actually quite complex with many separate aspects. So personally I
> don't think it's a good use case for initial solutions work - we would have to
> split it up into many separate pieces.
> 
> 3. And finally, by the time we are ready (Dec 2015 proposed in the charter) I
> really hope that Homenet will have finished their work on HNCP already. We
> would be too late.
> 
> I'd like people to make critical comments on my spreadsheet comparing the
> use cases. One person's opinion isn't sufficient, and I didn't fill in all the
> squares. I also think that one or two other use cases would still be useful.
> 
>     Brian
> 
> > Best regards,
> > Bing
> >
> >
> >> autonomic control plane that are already included in the draft
> >> charter. Since we need to make decision in around 10 days, it may be
> >> late for new use cases. It is better that we limit our selection from only
> the existing use cases.
> >>
> >>  - Home networks
> >>  - Assign IPv6 prefixes
> >>  - Assign IPv4 pools
> >> components, such as generic discovery/negotiation protocol or
> autonomic control plane.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 25 Aug 2014 12:11:44 +0000

We could change "high-level policy" to "high-level objective". If everybody feels like it, let's do it. 

I'm still slightly (!) hesitant, because it *is* a form of policy, as you state yourself in your first paragraph, Dimitri. And in an informal sense people understand what policy means. 

But if the rough consensus is "high level objective", I'll change it. 

Any last opinions? 
Michael

> Sent: 24 August 2014 15:53
> Cc: Michael Behringer (mbehring); [email-masked]; Sheng Jiang
> Yes. If I was king, the word "policy" would be forbidden in the IETF, because
> it has so many possible interpretations.
> 
> Regards
>    Brian
> 
> > As "Each network element needs to translate this into specific actions that
> will result in the aim stated in intent." the mapping (translation) from state
> to actions is left locally at the node level, which is the most general
> definition of policy.
> >
> > Hence, in the definition of intent, instead of referring to "high-level
> policy" you could refer to "high-level objective". This would avoid
> overloading the term policy and would settle a clearer demarcation line
> with DMTF/policy-based management models which uses different level of
> policies (high-/low-level, network/node-specific, etc.).
> >
> > Thanks,
> > -d.
> >
> >>> whereas an intent (from Webster) is defined as 'the thing you plan
> >>> to do or achieve: an aim or purpose', so do you mean "lookahead
> policies"
> >>> (as considered in model- predictive control, rolling horizon, etc.)
> >>> or something else ? note here that the IRTF document mentions
> >>> "intent: an abstract high level policy..." thus not sure I would be
> >>> able to put the
> >> pieces altogether.
> >>> we mean by the word "policy" I guess. In BGP-4 for example, "filter
> >>> out all /24s from APNIC space" might be considered an intent but
> >> For reference, this is what
> >> draft-irtf-nmrg-autonomic-network-definitions-
> >> 02 states about intent:
> >>
> >> To respond to Dimitri's comment, what we had in mind when we came up
> >> with the notion of "intent" is indeed the Webster definition above.
> >> Intent defines the "aim or purpose" of the network, rather than
> >> individual actions to achieve those. Each element receives intent,
> >> and takes it as the "aim" that the admin has defined for the network.
> >> My favourite example is "this network has guestnet". Which is a
> >> general aim. Each network element needs to translate this into
> >> specific actions that will result in the aim stated in intent.
> >>
> >> We didn't want to re-use the word "policy", because there are plenty
> >> of policy languages that are setting detailed local variables. "aim
> >> or purpose of the network" is what we were after.
> >>
> >> Is that better? If the above rough description makes sense, how can
> >> we define it better? Please provide suggestions, happy to incorporate
> >> in the next version of the definitions draft.
> >>
> >> Michael
> >
> >

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 25 Aug 2014 08:07:11 -0700

Dimitri,

Wrt to your thoughts about including what i would call monitoring/reporting
use cases (as you wrote below):

AFAIK there is a lot of work in pulling performance information from the network,
and doing aggrgation and analytics on it. I am not sure what aspects are covered
where in the IETF, and there may be a lot of (IETF) gaps in operationalizing comprehensive
solutions. But i wonder how we would best justify of taking on that work in Anima:

It seems a lot of this analytics could be well built as an overlay/"SDN" solution,
with controller(s) pulling in the information, eg: using methods like NETFLIX and
others. And potentially having a hierarchy of such controllers/agents do do aggregation,
and incremental stages of pre-analytics.

To me, the autonomic aspects would not be the model of that hierarchy of
information gasthering, analytics/agregation, but rather how to autonomously
orchestrate the active components in that model - hopefully as agents inside
the network. But without some pre-existing model, i think we would have to
do a lot more work in Anima than just those autonomic aspects - we might need
to come up with the model first. A model that maybe better is defined first
non-autonomic by a better group of experts in that subjet matter ?

Cheers
    Toerless

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 25 Aug 2014 16:10:45 +0000

Toerless,

The AN chain includes analytics enabling to derive actual states via cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution. 

I should clarify though considering cases involving e.g. information out of traffic/flow monitoring/measurement in addition to source of information provided/exchanged by current protocols (note: there are use cases that can limit their processing to the latter), does not mean ANIMA would have to work on metrology and related infrastructure, one can rely on existing sources, feeders, etc. 

The point is the latter shouldn't scope the former (AN is a "client" of such information but can't be client of close-loop state derivation and consistent state to action mapping because this is what AN is all about).

Now compared to SDN and other declinations --something which would need clarification in the charter-- is that it misses (referring to my previous email on the AN dimensions): "autonomy" and "distribution" and in terms of realization it assumes as prerequisite the transformation and homogeneization of the underlying infrastructure. AN aims at maximizing the gain in operational/control logic while minimizing the infrastructure change (SDN looks all the contrary to me).

Thanks,
-d.
> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Monday, August 25, 2014 5:07 PM
> Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for
> charter)
> 
> Dimitri,
> 
> Wrt to your thoughts about including what i would call
> monitoring/reporting use cases (as you wrote below):
> 
> AFAIK there is a lot of work in pulling performance information from the
> network, and doing aggrgation and analytics on it. I am not sure what
> aspects are covered where in the IETF, and there may be a lot of (IETF)
> gaps in operationalizing comprehensive solutions. But i wonder how we
> would best justify of taking on that work in Anima:
> 
> It seems a lot of this analytics could be well built as an overlay/"SDN"
> solution, with controller(s) pulling in the information, eg: using methods
> like NETFLIX and others. And potentially having a hierarchy of such
> controllers/agents do do aggregation, and incremental stages of pre-
> analytics.
> 
> information gasthering, analytics/agregation, but rather how to
> autonomously orchestrate the active components in that model - hopefully
> as agents inside the network. But without some pre-existing model, i think
> we would have to do a lot more work in Anima than just those autonomic
> aspects - we might need to come up with the model first. A model that
> maybe better is defined first non-autonomic by a better group of experts
> in that subjet matter ?
> 
> Cheers
>     Toerless
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 25 Aug 2014 09:38:02 -0700

Thanks, Dimitri,

Whats the most simple actual autonomous implementation instance
of the chain you imagine ? One that solves an actual use-case ?

Your remark about SDN requring more infrastructure changes than AN is interesting,
i wish it was true, but i am not so sure. I have a seen significant SDN work that
very pragmatically leverages existing CLI into network devices to build next-gen
central orchestration in the NOC, and only in parallel will new protocols
(eg: Netconf/RESTconf) and data models be defined to provide product/vendor
independent interfaces.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2014 12:33:20 +1200

Dimitri,

On 26/08/2014 04:10, Papadimitriou, Dimitri (Dimitri) wrote:
> Toerless,
> 
> The AN chain includes analytics enabling to derive actual
> states via cross-information processing from multiple sources
> (e.g., traffic/flow monitoring, protocol information bases,
> etc.) This is critical step to achieve what can't be derived
> out of individual protocol information that subsequently
> enables mapping/translating states to actions. The
> orchestration of these actions is part of the execution.

Yes, but that process isn't going to be specified by the IETF,
is it? It's internal to the implementation of a single AN
service agent, and that's where there is scope for
implementations to be different and to compete.

In the IETF we have to focus on the external interactions of the
nodes involved in the AN.

> 
> I should clarify though considering cases involving e.g.
> information out of traffic/flow monitoring/measurement in
> addition to source of information provided/exchanged by
> current protocols (note: there are use cases that can limit
> their processing to the latter), does not mean ANIMA would
> have to work on metrology and related infrastructure, one can
> rely on existing sources, feeders, etc.

Indeed - just as we will rely on existing north-south management
protocols when they can do the job.

> The point is the latter shouldn't scope the former (AN is a
> "client" of such information but can't be client of
> close-loop state derivation and consistent state to action
> mapping because this is what AN is all about).

Agreed. But the protocol that mediates the closed loop when more
 than one node is part of the loop is surely our business.

> Now compared to SDN and other declinations --something which
> would need clarification in the charter-- is that it misses
> (referring to my previous email on the AN dimensions):
> "autonomy" and "distribution" and in terms of realization it
> assumes as prerequisite the transformation and
> homogeneization of the underlying infrastructure. AN aims at
> maximizing the gain in operational/control logic while
> minimizing the infrastructure change (SDN looks all the
> contrary to me).

Well yes, but since we live in the real world we can't exclude
cases where, for example, an AN service agent might also be the
SDN controller for a certain domain. (I agree with you about
SDN, by the way, but it is part of the landscape.)

    Brian

> 
> Thanks, -d.
>> -----Original Message----- From: Toerless Eckert
>> [mailto:[email-masked]] Sent: Monday, August 25, 2014
>> 5:07 PM To: Papadimitriou, Dimitri (Dimitri) Cc: Sheng
>> Jiang; [email-masked] Subject: Re: [Anima] Monitoring use
>> cases (was: Select Use cases for charter)
>> 
>> Dimitri,
>> 
>> AFAIK there is a lot of work in pulling performance
>> information from the network, and doing aggrgation and
>> analytics on it. I am not sure what aspects are covered
>> where in the IETF, and there may be a lot of (IETF) gaps in
>> operationalizing comprehensive solutions. But i wonder how
>> we would best justify of taking on that work in Anima:
>> 
>> It seems a lot of this analytics could be well built as an
>> overlay/"SDN" solution, with controller(s) pulling in the
>> information, eg: using methods like NETFLIX and others. And
>> potentially having a hierarchy of such controllers/agents
>> do do aggregation, and incremental stages of pre- 
>> analytics.
>> 
>> To me, the autonomic aspects would not be the model of that
>> hierarchy of information gasthering, analytics/agregation,
>> but rather how to autonomously orchestrate the active
>> components in that model - hopefully as agents inside the
>> network. But without some pre-existing model, i think we
>> would have to do a lot more work in Anima than just those
>> autonomic aspects - we might need to come up with the model
>> first. A model that maybe better is defined first
>> Cheers Toerless
>> configuration (sampling rate) and placement inline with the
>> routing decision (and it would be interesting to confront
>> how autonomics would help automating/adapting such task
>> with current practices).
>> of a large set of information) which could help configuring
>> ACL, routing adjacencies or others.
>> information analysis, the output of such process should
>> prevent that protecting routing path fail together with
>> their primary path or that an alternate path fails right
>> after its selection due to delay in propagation of routing
>> information.
>> which the bandwidth x delay of running path segments could
>> be measured and estimated in order to anticipate possible
>> effects out of outages.
> 
> _______________________________________________ Anima mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/anima .
>

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Tue, 26 Aug 2014 08:26:49 +0000

Hi Dimitri and all,

>The AN chain includes analytics enabling to derive actual states via cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that
> subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution.

Totally agree. I think the AN chain include performance measurement segment (e.g. probe )and information collection segment from the measurement. Then analytics and filtration from this information is needed to enable the policy adjustment for network configuration adjustment for the QoS. The orchestration of these processing is important for the monitoring use cases.

BR
Yu

-----Original Message-----
From: Anima [mailto:[email-masked]] On Behalf Of Papadimitriou, Dimitri (Dimitri)
Sent: Tuesday, August 26, 2014 12:11 AM
To: Toerless Eckert
Cc: [email-masked]; Sheng Jiang
Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for charter)

Toerless,

Thanks,
-d.
> AFAIK there is a lot of work in pulling performance information from
> the network, and doing aggrgation and analytics on it. I am not sure
> what aspects are covered where in the IETF, and there may be a lot of
> (IETF) gaps in operationalizing comprehensive solutions. But i wonder
> how we would best justify of taking on that work in Anima:
>
> solution, with controller(s) pulling in the information, eg: using
> methods like NETFLIX and others. And potentially having a hierarchy of
> such controllers/agents do do aggregation, and incremental stages of
> pre- analytics.
>
> To me, the autonomic aspects would not be the model of that hierarchy
> of information gasthering, analytics/agregation, but rather how to
> autonomously orchestrate the active components in that model -
> hopefully as agents inside the network. But without some pre-existing
> model, i think we would have to do a lot more work in Anima than just
> those autonomic aspects - we might need to come up with the model
> first. A model that maybe better is defined first non-autonomic by a
> better group of experts in that subjet matter ?
>
> Cheers
>     Toerless
>
> On Fri, Aug 22, 2014 at 08:19:06AM +0000, Papadimitriou, Dimitri
> (Dimitri)
> wrote:
> > out
> > by
> which the bandwidth x delay of running path segments could be measured
> and estimated in order to anticipate possible effects out of outages.
> >

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 26 Aug 2014 09:02:40 +0000

>Now compared to SDN and other declinations --something which would need
>clarification in the charter-- is that it misses (referring to my previous email on
>the AN dimensions): "autonomy" and "distribution" and in terms of realization
>it assumes as prerequisite the transformation and homogeneization of the
>underlying infrastructure. AN aims at maximizing the gain in
>operational/control logic while minimizing the infrastructure change (SDN
>looks all the contrary to me).

Hi, Dimitri,

It is in our mind from the very beginning: to create a reusable infrastructure for Autonomic Network based on distributed devices. That's also the reason we would like to focus on only the AN infrastructure at the initial stage of the WG, rather than working on complex use cases. In the initial stage, we would only like one or two simple use case to demonstrate the usage of the common AN infrastructure. I guess we have not emphases this enough in the draft charter. 

Thanks,

Sheng

>and

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Tue, 26 Aug 2014 10:07:46 +0000

Brian,

> Sent: Tuesday, August 26, 2014 2:33 AM
> Cc: Toerless Eckert; [email-masked]; Sheng Jiang
> Subject: Re: [Anima] Monitoring use cases
> 
> Dimitri,
> 
> > The AN chain includes analytics enabling to derive actual states via
> > cross-information processing from multiple sources (e.g., traffic/flow
> > monitoring, protocol information bases,
> > etc.) This is critical step to achieve what can't be derived out of
> > individual protocol information that subsequently enables
> > mapping/translating states to actions. The orchestration of these
> > actions is part of the execution.
> 
> Yes, but that process isn't going to be specified by the IETF, is it? It's
> internal to the implementation of a single AN service agent, and that's
> where there is scope for implementations to be different and to compete.

What's "external" (and thus part of IETF work) : on the incoming side, service agent to have the means to select and parametrize the arrival of information (this includes native sources, but also other agents) and on the outgoing side, the scheduling/sequencing of actions and optionally verification of their utility. Do we agree on this ?
 
> In the IETF we have to focus on the external interactions of the nodes
> involved in the AN.
>
> > information out of traffic/flow monitoring/measurement in addition to
> > source of information provided/exchanged by current protocols (note:
> > there are use cases that can limit their processing to the latter),
> > does not mean ANIMA would have to work on metrology and related
> > infrastructure, one can rely on existing sources, feeders, etc.
> 
> Indeed - just as we will rely on existing north-south management protocols
> when they can do the job.

Yes. Following the above statement concerning "incoming information", one specific aspect is the combination of local information and remote information selection. This is one of the benefits out of AN and underlying autonomy/distribution: processing of locally significant information can be kept local. 

> > The point is the latter shouldn't scope the former (AN is a "client"
> > of such information but can't be client of close-loop state derivation
> > and consistent state to action mapping because this is what AN is all
> > about).
> 
> Agreed. But the protocol that mediates the closed loop when more  than one
> node is part of the loop is surely our business.

Yes. 

> > Now compared to SDN and other declinations --something which would
> > need clarification in the charter-- is that it misses (referring to my
> > previous email on the AN dimensions):
> > "autonomy" and "distribution" and in terms of realization it assumes
> > as prerequisite the transformation and homogeneization of the
> > operational/control logic while minimizing the infrastructure change
> > (SDN looks all the contrary to me).
> 
> Well yes, but since we live in the real world we can't exclude cases
> where, for example, an AN service agent might also be the SDN controller
> for a certain domain. (I agree with you about SDN, by the way, but it is
> part of the landscape.)

It is part of the "landscape" indeed but one of the properties of AN is its ability to accommodate heterogeneous "infrastructure" without requiring global abstraction (because AN is function-driven, it is the service agent function who drives information exchanges/processing, compared to models that are information-driven). 

> >> 5:07 PM To: Papadimitriou, Dimitri (Dimitri) Cc: Sheng Jiang;
> >> [email-masked] Subject: Re: [Anima] Monitoring use cases (was: Select
> >> Use cases for charter)
> >>
> >> Dimitri,
> >>
> >> potentially having a hierarchy of such controllers/agents do do
> >> aggregation, and incremental stages of pre- analytics.
> >>
> >> (Dimitri) wrote:
> > _______________________________________________ Anima mailing list
> > [email-masked] https://www.ietf.org/mailman/listinfo/anima .
> >

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Tue, 26 Aug 2014 16:51:58 -0300

http://www.inf.ufrgs.br/~jcnobre
I don't think that changing the term will solve this "policy issue".
I suppose many people that will read the anima charter will think of
policies even if the specific word is not present.
Cheers.

Jeferson

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Tue, 26 Aug 2014 20:57:25 +0000

Jefferson,  

AN is objective-function driven (the term autonomic function appropriately translates this) and keeps policing, i.e., mapping from state to possible action, local. 

This is what makes the fundamental difference with other approaches which aim at deriving global network states (out of inward information), translate them to actions (or actionable rules) and push the result downward to nodes.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jéferson Campos Nobre
> Sent: Tuesday, August 26, 2014 9:52 PM
> To: Michael Behringer (mbehring)
> Cc: Brian E Carpenter; Papadimitriou, Dimitri (Dimitri); [email-masked];
> Sheng Jiang
> > I'm still slightly (!) hesitant, because it *is* a form of policy, as
> you state yourself in your first paragraph, Dimitri. And in an informal
> sense people understand what policy means.
> >
> >> Yes. If I was king, the word "policy" would be forbidden in the IETF,
> >> because it has so many possible interpretations.
> >>
> >> Regards
> >>    Brian
> >>
> >> will result in the aim stated in intent." the mapping (translation)
> >> from state to actions is left locally at the node level, which is the
> >> most general definition of policy.
> >> >
> >> overloading the term policy and would settle a clearer demarcation
> >> line with DMTF/policy-based management models which uses different
> >> level of policies (high-/low-level, network/node-specific, etc.).
> >> >
> >> > Thanks,
> >> > -d.
> >> >
> >> >>> used: in the common sense a policy is a mapping from state to
> >> >>> action whereas an intent (from Webster) is defined as 'the thing
> >> >>> you plan to do or achieve: an aim or purpose', so do you mean
> >> >>> "lookahead
> >> policies"
> >> >>> (as considered in model- predictive control, rolling horizon,
> >> >>> etc.) or something else ? note here that the IRTF document
> >> >>> mentions
> >> >>> "intent: an abstract high level policy..." thus not sure I would
> >> >>> be able to put the
> >> >> pieces altogether.
> >> >>> I think Michael needs to comment on this. It is a question of
> >> >>> what we mean by the word "policy" I guess. In BGP-4 for example,
> >> >>> "filter out all /24s from APNIC space" might be considered an
> >> >>> intent but "filter out 123.123.123.0/24" might be considered a
> specific policy.
> >> >> To respond to Dimitri's comment, what we had in mind when we came
> >> >> up with the notion of "intent" is indeed the Webster definition
> above.
> >> >> We didn't want to re-use the word "policy", because there are
> >> >> plenty of policy languages that are setting detailed local
> >> >> variables. "aim or purpose of the network" is what we were after.
> >> >>
> >> >> Is that better? If the above rough description makes sense, how
> >> >> can we define it better? Please provide suggestions, happy to
> >> >> incorporate in the next version of the definitions draft.
> >> >>
> >> >> Michael
> >> >
> >> >

---

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

> AN is objective-function driven (the term autonomic function appropriately translates this) and keeps policing, i.e., mapping from state to possible action, local. 

And I think what we want to deduce from "intent" are the
constraints and initial conditions for the objective function.
(Although we have to be a little careful about using terminology
that normally concerns analytic functions.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Aug 2014 13:21:57 +1200

Dimitri,

On 26/08/2014 22:07, Papadimitriou, Dimitri (Dimitri) wrote:
> Brian,
> 
>> -----Original Message----- From: Brian E Carpenter
>> [mailto:[email-masked]] Sent: Tuesday, August
>> 26, 2014 2:33 AM To: Papadimitriou, Dimitri (Dimitri) Cc:
>> Toerless Eckert; [email-masked]; Sheng Jiang Subject: Re:
>> [Anima] Monitoring use cases
>> 
>> Dimitri,
>> 
>>> states via cross-information processing from multiple
>>> sources (e.g., traffic/flow monitoring, protocol
>>> information bases, etc.) This is critical step to achieve
>>> what can't be derived out of individual protocol
>>> information that subsequently enables mapping/translating
>>> states to actions. The orchestration of these actions is
>>> part of the execution.

>> Yes, but that process isn't going to be specified by the
>> IETF, is it? It's internal to the implementation of a
>> single AN service agent, and that's where there is scope
>> for implementations to be different and to compete.
> 
> What's "external" (and thus part of IETF work) : on the
> incoming side, service agent to have the means to select and
> parametrize the arrival of information (this includes native
> sources, but also other agents) and on the outgoing side, the
> scheduling/sequencing of actions and optionally verification
> of their utility. Do we agree on this ?

I think so, except that I have been thinking of the dialogue
between two agents as being pretty symmetrical, although
of course a given conversation will be started by one
side (which Sheng and I have called the negotiation initiator).
> 
>> In the IETF we have to focus on the external interactions
>> of the nodes involved in the AN.
>> 
>>> current protocols (note: there are use cases that can
>>> limit their processing to the latter), does not mean
>>> ANIMA would have to work on metrology and related 
>> Indeed - just as we will rely on existing north-south
>> management protocols when they can do the job.
> 
> Yes. Following the above statement concerning "incoming
> information", one specific aspect is the combination of local
> information and remote information selection. This is one of
> the benefits out of AN and underlying autonomy/distribution:
> processing of locally significant information can be kept
> local.

Exactly, it only needs to be shared with neighbours that
intrinsically need to share it.

> 
>>> The point is the latter shouldn't scope the former (AN is
>>> a "client" of such information but can't be client of
>>> close-loop state derivation and consistent state to
>>> action mapping because this is what AN is all about).
>> Agreed. But the protocol that mediates the closed loop when
>> more  than one node is part of the loop is surely our
>> business.
> 
> Yes.
> 
>>> Now compared to SDN and other declinations --something
>>> which would need clarification in the charter-- is that
>>> it misses (referring to my previous email on the AN
>>> dimensions): "autonomy" and "distribution" and in terms
>>> of realization it assumes as prerequisite the
>>> transformation and homogeneization of the underlying
>>> infrastructure. AN aims at maximizing the gain in 
>>> operational/control logic while minimizing the
>>> infrastructure change (SDN looks all the contrary to me).
>>> 
>> Well yes, but since we live in the real world we can't
>> exclude cases where, for example, an AN service agent might
>> also be the SDN controller for a certain domain. (I agree
>> with you about SDN, by the way, but it is part of the
>> landscape.)
> 
> It is part of the "landscape" indeed but one of the
> properties of AN is its ability to accommodate heterogeneous
> "infrastructure" without requiring global abstraction
> (because AN is function-driven, it is the service agent
> function who drives information exchanges/processing,
> compared to models that are information-driven).

I think we are agreeing. Obviously the current draft
charter has left things unsaid, and that needs to be
fixed.

   Brian

>>>> Jiang; [email-masked] Subject: Re: [Anima] Monitoring
>>>> use cases (was: Select Use cases for charter)
>>>> 
>>>> Dimitri,
>>>> 
>>>> where in the IETF, and there may be a lot of (IETF)
>>>> gaps in operationalizing comprehensive solutions. But i
>>>> wonder how we would best justify of taking on that work
>>>> in Anima:
>>>> 
>>>> It seems a lot of this analytics could be well built as
>>>> an overlay/"SDN" solution, with controller(s) pulling
>>>> in the information, eg: using methods like NETFLIX and
>>>> others. And potentially having a hierarchy of such
>>>> controllers/agents do do aggregation, and incremental
>>>> stages of pre- analytics.
>>>> 
>>>> To me, the autonomic aspects would not be the model of
>>>> that hierarchy of information gasthering,
>>>> analytics/agregation, but rather how to autonomously
>>>> orchestrate the active components in that model - 
>>>> hopefully as agents inside the network. But without
>>>> some pre-existing model, i think we would have to do a
>>>> lot more work in Anima than just those autonomic
>>>> aspects - we might need to come up with the model 
>>>> configuration (sampling rate) and placement inline with
>>>> the routing decision (and it would be interesting to
>>>> confront how autonomics would help automating/adapting
>>>> such task with current practices).
>>>> of a large set of information) which could help
>>>> configuring ACL, routing adjacencies or others.
>>>> their primary path or that an alternate path fails
>>>> right after its selection due to delay in propagation
>>>> of routing information.
>>>> which the bandwidth x delay of running path segments
>>>> could be measured and estimated in order to anticipate
>>>> possible effects out of outages.
>>> _______________________________________________ Anima
>>> mailing list [email-masked]

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 27 Aug 2014 00:02:10 -0300

My point is that the policy concept (explicitly or implicitly) is
necessary in an autonomic networking charter. For example, when Brian
wrote "to deduce from "intent" ... the constraints and initial
conditions", I read policy refinement/translation. I don't think that
just using "intent" or "high level objective" instead of "policy" will
set a "demarcation".

The "distributed or centralized" point is worth mentioning since IMHO
AN could be done in a centralized fashion. I'm not proposing this,
just mentioning it is possible, so it is necessary to state clearly
that distributed AN is a choice.

Jéferson
Jéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 27 Aug 2014 18:21:13 +0000

Yu
On Aug 26, 2014, at 4:26 AM, Fuyu (Eleven) <[email-masked]> wrote:

> Totally agree. I think the AN chain include performance measurement segment (e.g. probe )and information collection segment from the measurement. Then analytics and filtration from this information is needed to enable the policy adjustment for network configuration adjustment for the QoS.
I agree with Dimitri and you on this. Actually, I would suggest to do analysis of the information locally by the agent and agent would send analyzed information to other peering AN agents. Would also suggest that the probes would be very narrow, as the AN agent on the node is in constraint environment and data analytics is computationally expensive. This information can be used for other cases, not just for QoS.

> The orchestration of these processing is important for the monitoring use cases.
> 
> BR
> Yu
>

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Sat, 30 Aug 2014 03:47:59 +0000

Hi Dean,

>>> cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution.
>> 

What use cases ? Would you please take an example?

Cheers
Yu

-----Original Message-----
From: Dean Bogdanovic [mailto:[email-masked]] 
Sent: Thursday, August 28, 2014 2:21 AM
To: Fuyu (Eleven)
Cc: Papadimitriou, Dimitri (Dimitri); Toerless Eckert; [email-masked]; Sheng Jiang
Subject: Re: [Anima] Monitoring use cases (was: Select Use cases for charter)

Yu
On Aug 26, 2014, at 4:26 AM, Fuyu (Eleven) <[email-masked]> wrote:

>> cross-information processing from multiple sources (e.g., traffic/flow monitoring, protocol information bases, etc.) This is critical step to achieve what can't be derived out of individual protocol information that subsequently enables mapping/translating states to actions. The orchestration of these actions is part of the execution.
> 

>> methods like NETFLIX and others. And potentially having a hierarchy 
>> of such controllers/agents do do aggregation, and incremental stages 
>> of
>> pre- analytics.
>> 
>> measured and estimated in order to anticipate possible effects out of outages.
>>> 
>