Re: [Anima] ANIMA when there is a system-wide issue

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hi Brian,

Thanks for sharing interesting incidents and reflecting on the role of ANIMA 
technologies.

Reading the report, it seems the outage results from a series of indirectly 
linked events 
leading to isolation of a portion of the GCP network.

For the incident you refer here, how/where would you see ANIMA components to 
have (helped) avoided the outage?
Could we expect ANIMA networks to provide better/longer data plane operation in 
case of failed control plane/control plane functions? Beyond the pure ability 
to do so, there is a gain/risk trade-off to let a DP run out of sync of its CP.
Could we expect ANIMA components to have reacted differently and circumvent the 
issue, preventing the full disconnection of the GCP network portion? Or 
mitigated at intermediate points? 
The incident seems to have been triggered by a legitimate/valid configuration 
change but with resulting with a functionality loosing its access to files it 
needed to perform. The config. change validation basically didn't notice there 
was a possible issue.
Would such a miss been caught by ANIMA components? (e.g. via a different 
validation-dependencies approach?)

Why I'm a bit doubtful here is because even if we deploy robust autonomic 
functions/agents, the above problem seems to originate from an issue in how the 
system has been configured.
And even ASAs would still need to get some form/level of initial configuration 
or guidance.


Best regards, 
Laurent

> -Original Message-
> From: Anima  On Behalf Of Brian E Carpenter
> Sent: Thursday, December 17, 2020 02:47
> To: Anima WG 
> Subject: Re: [Anima] ANIMA when there is a system-wide issue
> 
> And here's what happens when the control plane itself falls over:
> 
> https://status.cloud.google.com/incident/zall/20011#20011006
> 
> It seems pretty clear that Cloud needs ANIMA.
> 
> Regards
>Brian
> 
> On 01-Dec-20 11:02, Brian E Carpenter wrote:
> > "AWS reveals it broke itself by exceeding OS thread limits"
> >
> > https://www.theregister.com/2020/11/30/aws_outage_explanation/
> >
> > Especially:
> > "The TIFU-like post also outlines why Amazon's dashboards offered only
> scanty info about the incident – because they, too, depend on a service
> that depends on Kinesis."
> >
> > Perhaps there is something we should specify in ANIMA to prevent the
> ANIMA infrastructure falling into this sort of trap: when there is a
> system-wide issue (such as hitting an O/S resource limit everywhere at the
> same time) it also prevents the autonomic mechanisms from working.
> >
> > Regards
> >Brian Carpenter
> >
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adoption call for draft-carpenter-anima-asa-guidelines-09, ends October 29th 2020

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

I'm a co-author of this draft.
I support its adoption as WG document.

Best regards, 
Laurent

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Thursday, October 15, 2020 12:37
> To: Anima WG 
> Cc: anima-cha...@ietf.org; Rob Wilton (rwilton) 
> Subject: [Anima] Adoption call for draft-carpenter-anima-asa-guidelines-
> 09, ends October 29th 2020
> 
> Dear ANIMA WG
> 
> This message starts a two-week adoption call, ending on October 29th,
> 2020.
> 
> draft-carpenter-anima-asa-guidelines-09 has been progressed by the authors
> with help of the WG for a long while and the WG showed good interest. It
> was last presented at IETF108 and had no opposition. The draft is now
> clearly in scope of ANIMA charter 2 that was adopted around IETF106. The
> authors asked for adoption of the document at IETF108.
> 
> We therefore are asking the ANIMA working group for adoption of the
> following work:
> 
> Title:Guidelines for Autonomic Service Agents
> Name: draft-carpenter-anima-asa-guidelines-09
> Authors:  B. E. Carpenter, L. Ciavaglia, S. Jiang, P. Peloso
> URL:  https://datatracker.ietf.org/doc/draft-carpenter-anima-asa-
> guidelines/
> 
> This document is intended to become an informational ANIMA WG document.
> 
> Please express your support or rejection.
> If you think this document should _not_ be adopted, please also explicitly
> indicate the reasons.
> 
> Regards,
> 
> Toerless
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] ANIMA: Reminder: Re: Call for agenda ANIMA @ IETF 108, online

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Dear ANIMA WG Chairs,

We'd like to ask for a short slot on draft-carpenter-anima-asa-guidelines.
The main purpose is to present the status of the I-D (no change, stable 
version) and ask for WG document adoption.

Best regards, 
-Laurent

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Tuesday, July 21, 2020 05:55
> To: Sheng Jiang 
> Cc: anima-cha...@ietf.org; anima@ietf.org
> Subject: [Anima] ANIMA: Reminder: Re: Call for agenda ANIMA @ IETF 108,
> online
> 
> Reminder. Please bring forward for any agenda items you want to see.!
> 
> Thanks
> Toerless
> 
> On Fri, Jul 10, 2020 at 07:51:34AM +, Sheng Jiang wrote:
> > Hi, all anima,
> >
> >
> >
> > We have been allocated a sessions of 1 hour 40 minutes for the ANIMA WG
> meeting for IETF-108 (online). It is on Thursday, July 30, 2020?? 11:00-
> 12:40 (UTC). We are now starting to collect agenda items for the session.
> Please send your request for agenda by July 21th, Tuesday, to anima-
> cha...@ietf.org and both chairs' email. Please note that email to a single
> chair may cause single-point failure.
> >
> >
> >
> > As normal, the priority among these non-charter work items would be:
> these that have active discussion in mail list, then these have submitted
> drafts, and topics without drafts.
> >
> >
> >
> > Please send us (anima-chairs at ietf.org) requests for time slot by July
> 21th, Tuesday and include:
> >
> >
> >
> > Name of time slot:
> >
> > Name of draft(s):
> >
> > Time requested:
> >
> > Presenter name(s):
> >
> >
> >
> > More details about the IETF 108 can be found at:
> >
> >
> >
> > https://www.ietf.org/how/meetings/108/
> >
> >
> >
> > Again, presenters and draft authors please invoke active discussions in
> the ANIMA list. Mail list is a very good place to discuss and reach
> consensus on technical issues.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Sheng + Toerless
> >
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Pending ANIMA drafts

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hi Bria, All,

Re: https://tools.ietf.org/html/draft-carpenter-anima-asa-guidelines

As a co-author, I also believe we need to make a decision on the next step for 
this document.
We have proposed options for content evolution in previous ANIMA meetings.

Maybe a call for adoption as WG document will "force" us to take a decision.

Best regards, Laurent.


> -Original Message-
> From: Anima  On Behalf Of Brian E Carpenter
> Sent: Wednesday, April 8, 2020 07:14
> To: Anima WG 
> Subject: [Anima] Pending ANIMA drafts
> 
> Hi everybody,
> 
> Comments on the following drafts have been sadly lacking since IETF 106.
> As a result I have not asked for time on the April 9th agenda, especially
> since it will be 3 a.m. on April 10th for me.
> 
> As a reminder, the base GRASP specification is sitting quietly in the RFC
> Editor queue waiting for a missing normative reference (the ACP draft).
> 
> https://tools.ietf.org/html/draft-ietf-anima-grasp-api
> 
> This version was based on several reviews and there were no changes
> requested during IETF 106. I would like to ask for WG Last Call *now* on
> this draft to see if there is consensus. (It's Informational, like most
> IETF work on APIs. It is also about to expire; I would rather get some
> more comments before refreshing it.)
> 
> 
> https://tools.ietf.org/html/draft-carpenter-anima-asa-guidelines
> https://tools.ietf.org/html/draft-carpenter-anima-grasp-bulk
> https://tools.ietf.org/html/draft-carpenter-anima-l2acp-scenarios
> 
> I would really like more feedback on these drafts. The first two are old
> enough that either the WG should adopt them, or they should be discarded.
> Without your feedback, nothing will happen.
> 
> The l2acp draft has just expired, and will be revised shortly.
> 
> Stay well
>Brian Carpenter
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs]

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

> -Original Message-
> From: Anima  On Behalf Of Michael Richardson
> Sent: Saturday, October 12, 2019 23:02
> To: anima@ietf.org
> Subject: Re: [Anima] Call for agenda ANIMA @ IETF 106, Singapore [ASAs]
> 
> 
> Brian E Carpenter  wrote:
> > It seems time for the WG to discuss seriously what to do about the
> > environment for Autonomic Service Agents (ASAs). We could have this
> > discussion around an existing draft, but the main goal would be to
> > discuss what the WG needs to do in this area.
> 
> +1
> 
> I think that we need to spend some high-level time discussing what happens
> next, now that we have completed the ACP work (ACP, BRSKI, architecture)
> 

+1 too.
I think documents draft-carpenter-anima-asa-guidelines and 
draft-peloso-anima-autonomic-function bring some views about the question. 
Agree with Brian we should not limit to these docs for the discussion.
There is also recent work started in ETSI ZSM ISG on Enablers (ZSM009-1), 
Solutions (ZSM009-2) and Advanced Topics (ZSM009-3) for Closed-Loop Automation 
(not far from the definition of an ASA).

Best regards, Laurent.
 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Intent: -> NMRG -> ANIMA -> NMRG -> (ANIMA?)!) Re: proposed anima charter (was; Re: New work item proposal / agenda request)

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Friday, February 22, 2019 12:00
> To: Brian E Carpenter 
> Cc: Michael Richardson ; anima@ietf.org
> Subject: Re: [Anima] Intent: -> NMRG -> ANIMA -> NMRG -> (ANIMA?)!) Re:
> proposed anima charter (was; Re: New work item proposal / agenda request)
> 
> On Thu, Feb 21, 2019 at 08:37:43AM +1300, Brian E Carpenter wrote:
> > To put it bluntly, we know how to distribute Intent in an ANIMA network
> > (GRASP flooding if it's small, GRASP bulk transfer if it's big). We can
> > even guess that it's likely to look exactly like JSON, which is trivial
> to
> > represent in GRASP/CBOR. But we have no idea what it actually *is*.
> 
> Yes, thats the easy part and we have a draft waiting to be revived when
> we can conclude that that part of work is needed. But right now we have
> the larger issue of not knowing WHAT would be Intent, or how much of
> Intent could really usefully be flooded as opposed to requiring
> different distribution mechanism.

Indeed one of the challenges is to define "what" intent is, but we should not 
limit our view/understanding to the "intent" itself.
IP networking is not only the IP address, same for Intent-based networking, it 
is not only the intent format that is of importance. Other mechanisms, and a 
comprehensive view/understanding is required to know how to design the right 
thing(s).

I think where ANIMA could help NMRG is in "scoping" the problem (what intent 
means in an ANIMA context/network) and/or with use cases/examples of 
intent-driven operations/behaviors.

Best regards, laurent.

> 
> > That indeed seems to be a research problem.
> 
> I think terminology is more a political issue, but yes, NMRG is the more
> appropriate place to solve this.
> 
> Cheers
> Toerless
> 
> > Regards
> >Brian
> >
> > On 2019-02-21 02:57, Toerless Eckert wrote:
> > > On Tue, Feb 19, 2019 at 11:19:58AM -0500, Michael Richardson wrote:
> > >> I find it slightly confusing that we say that Intent is part of the
> framework, but
> > >> that we don't work on it without a recharter, but I guess the goal is
> not to
> > >> forget it, but not to go down a rathole.
> > >
> > > Wanted to reassert what i hope is the WG agreement about Intent, and
> we
> > > had discussed this since at least IETF102:
> > >
> > > Intent was given to us (ANIMA) from NMRG as part of the initial chater
> > > scope. We did include it into the reference model, but we failed to
> find
> > > enough actionable agreement on what Intent is and what to do about it.
> > >
> > > We therefore for now would like to punt the next steps of work on
> Intent
> > > back to NMRG and hope we can make enough progress there to later bring
> > > it back into ANIMA.
> > >
> > > I had given a more detailed presentation to this effect at the friday
> > > NMRG workshop at IETF101 in Montreal, but somehow i can not find any
> > > slides from that friday meeting. Maybe Laurent can comment were that
> > > NMRG workshop notes are. There where more really good presentations.
> > >
> > > I have appended the one i gave to this email.
> > >
> > > Cheers
> > > Toerless
> > >
> > >
> > > ___
> > > Anima mailing list
> > > Anima@ietf.org
> > > https://www.ietf.org/mailman/listinfo/anima
> > >
> 
> --
> ---
> t...@cs.fau.de
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Intent: -> NMRG -> ANIMA -> NMRG -> (ANIMA?)!) Re: proposed anima charter (was; Re: New work item proposal / agenda request)

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

Materials of the NMRG interim meeting at ETS Montreal, July 2018 are here: 
https://datatracker.ietf.org/meeting/interim-2018-nmrg-03/session/nmrg

If you think NMRG should work on a survey on IBN or other proposals, please 
feel free to send e-mail messages / make your case to the NMRG mailing list 
(n...@irtf.org) and/or the NMRG chair (me😉).
FYI: NMRG will hold a virtual meeting very soon (week 4-8 March) where 
IBN/other topics of interest could be discussed before IETF 104.

Thanks, Laurent.


> -Original Message-
> From: Anima  On Behalf Of Toerless Eckert
> Sent: Friday, February 22, 2019 11:57
> To: Michael Richardson 
> Cc: anima@ietf.org
> Subject: Re: [Anima] Intent: -> NMRG -> ANIMA -> NMRG -> (ANIMA?)!) Re:
> proposed anima charter (was; Re: New work item proposal / agenda request)
> 
> On Wed, Feb 20, 2019 at 02:30:43PM -0500, Michael Richardson wrote:
> > > Intent was given to us (ANIMA) from NMRG as part of the initial
> chater
> > > scope. We did include it into the reference model, but we failed
> to find
> > > enough actionable agreement on what Intent is and what to do about
> it.
> >
> > I thought that we make it out of scope so that SUPA would do the work,
> but
> > SUPA failed. (I'm reminded by the "POLICY" WG of 20 years ago...)
> 
> Hah. I skipped the SUPA episode because i don't remember if we really
> ever made specific decisions in that case as opposed to just observing
> it.
> 
> > > We therefore for now would like to punt the next steps of work on
> Intent
> > > back to NMRG and hope we can make enough progress there to later
> bring
> > > it back into ANIMA.
> >
> > Fair enough.  I don't know if the charter should refer readers to NMRG.
> 
> Seems the guidance we got in IETF103 was to start short and let
> qualified charter reviewers ask for what they feeel missing. Where
> qualified charter reviewers would i think be IESG.
> 
> > I also wonder if there are any proprietary efforts to define Intent that
> > could be referenced?
> 
> Sure, but for now that collection of information should be done in NMRG.
> 
> > > I had given a more detailed presentation to this effect at the
> friday
> > > NMRG workshop at IETF101 in Montreal, but somehow i can not find
> any
> > > slides from that friday meeting. Maybe Laurent can comment were
> that
> > > NMRG workshop notes are. There where more really good
> presentations.
> >
> > Maybe in the proceedings?  I guess there is a youtube video too.
> 
> No, the friday NMRG workshop was hosted at the university, so no
> standard IETF video gear was there. Let me ping Laurent directly.
> 
> Cheers
> Toerless
> 
> > ]   Never tell me the odds! | ipv6 mesh
> networks [
> > ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> > ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
> >
> >
> > --
> > Michael Richardson , Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> >
> 
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Test... Please ignore

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Just running some tests as I'm not receiving emails for IETF mailing lists.

-Laurent.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Call for agenda ANIMA @ IETF 102, Montreal

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Dear ANIMA WG chairs, ANIMA WG participants,

I can offer to present again, shortly, on the concepts for: [1] coordination 
between autonomic functions ; [2] knowledge exchange (relates to other drafts 
being discussed in ANIMA WG), and [3] autonomic functions lifecycle management 
(relates to draft-asa-guidelines).

On another point, we have been regularly touching the "intent" topic in the WG. 
Maybe it is time/worth to give it another try and determine what the WG would 
be willing (or not) to investigate in that space.
FYI, the NMRG will hold a 1-day technical workshop on Friday 20 July 2018 on 
Intent Based Networking at ETS Montreal (a few blocks from IETF 102 headquarter 
hotel).
The goal of the meeting is to go into important topics such as :
- What IBN enables, and how?
- Design goals and challenges
- Are intent-based and policy-based management different?

Best regards, Laurent.
---

[1] (expired) Autonomic Functions Coordination 
https://datatracker.ietf.org/doc/draft-ciavaglia-anima-coordination/
[2] (expired) Knowledge Exchange in Autonomic Networks 
https://datatracker.ietf.org/doc/draft-ciavaglia-anima-knowledge/
[3] (expired) A Day in the Life of an Autonomic Function 
https://datatracker.ietf.org/doc/draft-peloso-anima-autonomic-function/



From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Sheng Jiang
Sent: Saturday, June 23, 2018 2:59 PM
To: anima@ietf.org
Cc: anima-cha...@ietf.org
Subject: [Anima] Call for agenda ANIMA @ IETF 102, Montreal


Hi, all anima,



We have been allocated a session of 2.5-hour for the ANIMA WG meeting for 
IETF-102 (Montreal) and are starting to collect agenda items for the session.. 
Please send your request for agenda by July 5th, Thursday.



Giving that most of our chartered work items have been sent to IESG for 
publication by the meeting, we expect short time slots for only two or three of 
them. For this coming meeting, we would like to discuss potential future ANIMA 
works.



As normal, the priority among these non-charter work items would be: these that 
have active discussion in mail list, then these have submitted drafts, and 
topics without drafts.



Please send us (anima-chairs at ietf.org) requests for 
time slot by July 5th, Thursday and include:



Name of time slot:

Name of draft(s):

Time requested:

Presenter name(s):



More details about the IETF 102, Montreal can be found at:



https://www.ietf.org/how/meetings/102/



Again, presenters and draft authors please invoke active discussions in the 
ANIMA list. Mail list is a very good place to discuss and reach consensus on 
technical issues.



Best regards,



Toerless & Sheng
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Comments from Alex G. on draft-carpenter-anima-asa-guidelines

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hi Alex,

Thanks for your comments on draft-carpenter-anima-asa-guidelines.

If I get it correctly you raised the following points:

  1.  -better describe what ASA are: rather application or network service, and 
better describe the border between the two and implications for ASA 
designers/developers in the draft.

I think it is an important (and not so simple) topic and worth being discussed.

Would welcome views from the group.



  1.  -NFV is an important area for future networks, and more focus for ANIMA 
and ASA should be devoted.

Agreed; However, I'm not aware that NFV community is following ANIMA work and 
guidelines on autonomic VNF design/development. Although there are several 
autonomic/self-* behavior/functionality being developed in NFV.

There is clearly a gap here, and a difference in approach.



  1.  -You mentioned something about the decoupling of self-* functionality 
(self-configuration, self-healing...)

Not sure I get fully what was your comment on this aspect. Could you clarify / 
develop?

Thank you.
Best regards, Laurent.

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

[Anima] Related work for draft-carpenter-anima-asa-guidelines

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

Sheng you mentioned two works we should liaise to, which could help getting 
deployment experience.
Bing mentioned an ID but I cannot find it under the ANIMA related docs (not 
T2TRG ones).

Could you share the pointers or contacts, please?

Thanks, Laurent.


___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] "professionally managed" and the reference model

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

Does the need to explicitly distinguish ANIMA work from HOMENET work still exist
If not, then why not remove/forget about this possibly contentious terminology. 
(the goal would be to avoid unnecessary difficulties for ANIMA documents 
publication at IESG review or IETF last call stages).

FWIW, my understanding of "professionally managed" is "managed _BY_ a 
professional". 
Here the person or entity being the "professional" is providing a service (paid 
or free) to manage a given network as part of her job (or contract). 
In the mission of her job (or contract) the professional is "external" to the 
user of the network being managed (i.e. act as a first/third party).

* note: a homenet can well be very professionally managed in the sense that it 
follows BCP but it does not mean it is managed by someone for which it is the 
job to do this (e.g. John Doe, who is a skilled engineer, manage its homenet 
for himself, or manage homenets for his friends/relatives...)
** note: a homenet can well be completely unmanaged, i.e. relying exclusively 
on full plug-and-play mechanisms.

Best regards, Laurent.

-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Thursday, March 1, 2018 1:53 AM
To: Toerless Eckert 
Cc: anima@ietf.org
Subject: Re: [Anima] "professionally managed" and the reference model

in line (all IMHO):

On 01/03/2018 04:51, Toerless Eckert wrote:
> On Wed, Feb 28, 2018 at 10:40:55AM +1300, Brian E Carpenter wrote:
>> (a) Undoubtedly we will have changes to make after IETF Last Call, so 
>> we can put this on ice until then.
>> (b) Yes, I think the text here and in RFC7575 is fine. Maybe it's the 
>> WG charter which is wrong :-). As you know, the point was to avoid 
>> any clash with HOMENET. But "traditionally managed" is a better 
>> phrase than "professionally managed", I think.
> 
> Interesting aside!
> 
> Is a network with an SDN controller traditionally managed ?

If the SDN controller is configured by a NOC or an NMS database managed by the 
NOC, yes. I think we are talking about configured by a human in the NOC when we 
say "traditional" or "professional". 

> If the SDN controller uses the ACP, does this change the result ?

No. But if the SDN controller is configured by an ASA, not by a human, it's 
autonomic.

> Long term NMS'ler would say controller/orchestrator are just fancy new 
> words for mostly the provisioning part of NMS, but:
> 
> Good controllers/orchestrator would also be intent based only that the 
> rendering of the intent would not necessarily be autonomic. But then 
> we have never IMHO well described what criteria are required to call a 
> particular method of intent rendering autonomic.

One reason why "intent" is still a buzzword left for future study.

> Some for example would make distribution the key criteria while i 
> would just look at the observable resilience of a function.
> 
> To use a militaristic explanation: When doing PIM-SM, defense 
> customers asked us what happens when the enemy shoots down the RP. And 
> then shoot down its replacement. An so on. Now replace RP with SDN controller.
> 
> Aka: resilient = able to automatically restart in one of enough places 
> to make the solution survive all covered incidents.
> 
> The "ability to shoot down anything" was btw. the original 1st 
> requirement by DoD against Arpanet, so i would be careful to call 
> autonomic networks non-traditional (managed). I would not know what 
> would be more traditional than meeting this expectation for an IP network.

Right. That's why the GRASP draft used to contain a riff about how routing 
algorithms were the original autonomic mechanisms. If you remember, we had to 
remove that to satisfy the Routing Area people.

If ANIMA succeeds, we will have simply extended that original DARPA requirement.

   Brian

> 
> Cheers
> Toerless
> 
>>Brian
>>>
>>> Michael
>>>
>>>
>>>
>>> On 26/02/18 22:21, Brian E Carpenter wrote:
 While looking at Pascal's ACP review, I noticed that although ANIMA 
 scope is limited by charter to "professionally managed" networks, 
 we do not mention that scope in draft-ietf-anima-reference-model.
 It seems like something to be added to the Introduction.

 Comments?

 Regards
 Brian Carpenter


 ___
 Anima mailing list
 Anima@ietf.org
 https://www.ietf.org/mailman/listinfo/anima
>>>
>>> ___
>>> Anima mailing list
>>> Anima@ietf.org
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>
>> ___
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://w

Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

We are currently 8 "co-authors" for this draft.
My preferences, in priority order, are:
1) Michael as Editor, all other authors listed as authors, no 
contributors.
2) Michael as Editor, all other authors listed as contributors.

Given how this document originated and has developed over time, this would 
reflect, from my viewpoint, a "fair representation".

We may discuss our approach for representation of contributors versus RFC 
editor guidelines.
I think it can be important for the "external readership" that the diversity of 
people that took part in this document is visible, although I understand (and 
fully support) that IETF is not affiliation-driven. Nevertheless, showing 
industry and academia mix is good, and also several vendors co-signing. But 
this may not be our only driver for deciding how to list authors.

Side question: how are contributors associated with an RFC in the datatracker? 
I mean if I search on the datatracker with someone's name, will the RFC where 
he has been contributors appear?

Thanks, Laurent.

-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Wednesday, January 31, 2018 8:16 PM
To: Michael H. Behringer ; anima@ietf.org
Subject: Re: [Anima] Review comments//RE: WGLC on 
draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

On 30/01/2018 07:58, Brian E Carpenter wrote:
...
> On 29/01/2018 22:03, Michael H. Behringer wrote:
>> OK, the time for the last call is over. I'll produce a -06 version, 
>> working through the following issues:
>>
>> - Sheng's review from 18 Jan (Thanks Sheng)
>> - Michael's response to Sheng's mail.
>> - the author issue. I think I'll follow Brian's suggestion, listing 
>> me as editor and all other co-authors under contributors. At least I see no 
>> better way...

On looking at that again, please consider that what I actually wrote was:

>> To answer to Brian comments on co-authors: if we have one or more Editors, 
>> should all other "authors" be listed as contributors?
> 
> That is the option suggested by the RFC Editor site, and Michael has been the 
> editor all along.
> Personally I would be quite happy to be listed as a contributor.

I think it's perfectly fine to list one or two editors, then three or four 
authors of substantial text, to a maximum of 5, and then list the rest as 
contributors. If you really can't cut the list at 5, we'd need to justify it to 
the AD.

   Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

I'm a co-author of the draft.
I believe the document is ready to progress and several iterations of the 
document have tried to capture the evolution of the other technical work done 
in ANIMA. 
The document fulfills its intent 😉 to explain how the different components of 
ANIMA fits together, and is thus very useful for the general understanding 
around autonomic networking.

As mentioned by Brian, future work in ANIMA should probably be reflected in a 
second edition.

Best regards, Laurent.

-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Toerless Eckert
Sent: Thursday, January 11, 2018 12:09 AM
To: Michael H. Behringer 
Cc: anima@ietf.org
Subject: Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by 
January 22nd, 2018

As another co-author i agree to everything Michael said except that it should 
be said without HTML obfuscating it ;-)

Cheers
Toerless

On Wed, Jan 10, 2018 at 10:07:39PM +0100, Michael H. Behringer wrote:
> 
>   
> 
>   
>   
> I guess I've made my point before, but
>   just in case: I'm also co-author, and also think this doc is ready
>   to move forward. 
>   
>   Michael
>   
>   On 10/01/18 22:06, Jéferson Campos Nobre wrote:
> 
>  cite="mid:cabv6xlvgxlh1izs2zavcty-h13oqaydofq3brprkfrmugv6...@mail.gmail.com">
>   Dear Anima.
> I am also a co-author of this draft and I think it is in a
>   good shape to advance. Besides that, I believe the publication
>   of the reference model is an important step for the WG.
> Best.
> Jéferson
>   
>   
> Em ter, 9 de jan de 2018 às 19:32, Brian E
>   Carpenter  moz-do-not-send="true">brian.e.carpen...@gmail.com>
>   escreveu:
> 
> Hi,
>   
>   I am a co-author of this draft. I do believe that it is
>   ready to advance, and that it's useful to get it published
>   soon so that it can indeed act as a reference model. We
>   know that a second edition will probably be needed to
>   include future work.
>   
>   (At least one minor correction is pending in the XML
>   source:
>href="https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599";
> rel="noreferrer" target="_blank" 
> moz-do-not-send="true">https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599
>   )
>   
>   Regards
>      Brian Carpenter
>   
>   On 09/01/2018 19:26, Sheng Jiang wrote:
>   > Hi all,
>   >
>   > This message starts the two-week ANIMA Working Group
>   Last Call to advance draft-ietf-anima-reference-model-05,
>   A Reference Model for Autonomic Networking. This
>   document's intended status is Informational. At present,
>   there is no IPR file against this document.
>   >
>   > Please send your comments by January 22nd, 2018. If
>   you do not feel this document should advance, please state
>   your reasons why.
>   >
>   > Sheng JIANG is the assigned document shepherd.
>   >
>   > Regards,
>   >
>   > Sheng (co-chair, Toerless who as a co-author stayed
>   neutral on the content side)
>   >
>   >
>   >
>   >
>   > ___
>   > Anima mailing list
>   > mailto:Anima@ietf.org"; target="_blank"
> moz-do-not-send="true">Anima@ietf.org
>   >  href="https://www.ietf.org/mailman/listinfo/anima";
> rel="noreferrer" target="_blank" 
> moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/anima
>   >
>   
>   ___
>   Anima mailing list
>   mailto:Anima@ietf.org"; target="_blank"
> moz-do-not-send="true">Anima@ietf.org
>   https://www.ietf.org/mailman/listinfo/anima";
> rel="noreferrer" target="_blank" 
> moz-do-not-send="true">https://www.ietf.org/mailman/listinfo/anima
> 
>   
> 
>   
>   
>   
>   
>   ___
> Anima mailing list
>  href="mailto:Anima@ietf.org";>Anima@ietf.org
>  href="https://www.ietf.org/mailman/listinfo/anima";>https://www.ietf.or
> g/mailman/listinfo/anima
> 
> 
> 
>   
> 
> 

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
___

Re: [Anima] Warren Kumari's No Objection on draft-ietf-anima-prefix-management-06: (with COMMENT)

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

> 
> Firstly, a global concern:
> This technique (and I suspect many automated prefix allocations where 
> a device uses space, and then requests more) is likely (I think) to 
> result in fragmentation of the address space - this will lead to more 
> routing entries in the IGP, which may be an issue for smaller routers 
> or "L3 switches". I think that it would be useful to note this.

That devil is in the details, but you're correct, that is a risk. How big a 
risk depends on the algorithms and policies used. If we get to update the 
draft, this would be a good point to add.

>>Laurent: not providing a definitive answer / solution, but if we see more 
>>deployment of autonomic functions (such as automatic/autonomic prefix 
>>management), we can imagine to also have functions taking care of the 
>>fragmentation and re-aggregation in an automatic/autonomic way. Thus, the 
>>risk _could_ _eventually_ be minimized.

>>Laurent: if the issue for small(er) routers / L3 switches is on performance, 
>>then there is usually Moore's law that can help address it in a few years 
>>span (even with degraded Moore's law). If the issue is complexity, then this 
>>is an additional case to have more autonomic (read: intelligent) functions 
>>running simultaneously in the network / in the devices.

Best regards, Laurent.




-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Brian E Carpenter
Sent: Thursday, December 14, 2017 1:49 AM
To: Warren Kumari ; The IESG 
Cc: tte+an...@cs.fau.de; fredbaker.i...@gmail.com; anima-cha...@ietf.org; 
Toerless Eckert ; draft-ietf-anima-prefix-managem...@ietf.org; 
anima@ietf.org
Subject: Re: [Anima] Warren Kumari's No Objection on 
draft-ietf-anima-prefix-management-06: (with COMMENT)

On 14/12/2017 09:48, Warren Kumari wrote:
...
> --
> COMMENT:
> --
> 
> Thank you.
> 
> I did have some comments / questions.
> I'd also like to draw both the authors, and AD's attention to Fred 
> Bakers excellent thoughts in his OpsDir review - 
> https://datatracker.ietf.org/doc/review-ietf-anima-prefix-management-0
> 6-opsdir-lc-baker-2017-10-23/
> 
> Firstly, a global concern:
> This technique (and I suspect many automated prefix allocations where 
> a device uses space, and then requests more) is likely (I think) to 
> result in fragmentation of the address space - this will lead to more 
> routing entries in the IGP, which may be an issue for smaller routers 
> or "L3 switches". I think that it would be useful to note this.

That devil is in the details, but you're correct, that is a risk. How big a 
risk depends on the algorithms and policies used. If we get to update the 
draft, this would be a good point to add.
 
> 
> I also wanted to make sure that the author of this document were aware 
> of the CASM BoF from IETF98 - I've just checked, and see that at least 
> Qiong Sun was associated with the work 
> (draft-xie-ps-centralized-address-management).

Yes, in fact it would mesh quite nicely with CASM. That's the main reason I 
pushed to have the C in CASM mean "coordinated" instead of "centralized".
 
> I had a question -- I don't really understand what: [Page 9] "A 
> gateway router in a hierarchical network topology normally provides 
> prefixes for routers within its subnet, ..." is trying to say. I've 
> seen many "hierarchical network topologies" and don't believe this to 
> be true, nor do I really understand what "its subnet" means. In some 
> cases a router will announce an aggregate for customers behind it, but 
> I don't really view that as a general case. I'm guessing I'm just not 
> understanding - can you please educate me?

Hmm. In a manually designed network (especially with v6) I'd expect the initial 
design would be done in something close to a binary tree, but in the real world 
things tend to drift from that starting point over the lifetime of the network. 
But I think the phrasing is probably trying to say too much in too few words. 
All it's really trying to say is that the ability to negotiate with an 
arbitrary peer is more powerful than only being able to ask your upstream for 
more prefixes.

Again, happy to clarify the wording if we update the draft again.

   Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017

[Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)]

Hello,

I think this work is of interest and should continue, either as an individual 
or working group document.

Laurent.

-Original Message-
From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Diego R. Lopez
Sent: Tuesday, December 12, 2017 10:36 AM
To: Toerless Eckert ; Sheng Jiang ; 
anima@ietf.org
Cc: anima-cha...@ietf.org; Carsten Bormann 
Subject: Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 
12, 2017

Hi,

I support the adoption. As said at the meeting, I think it is about time the 
IETF starts considering APIs, or at least general interfaces (as it is doing in 
other WGs, like TAPS), especially when we think of the increasing momentum 
software-enabled solutions are gaining. And the case of GRASP is especially 
relevant for this, so there is a clear interface for extension modules. And 
yes, let's make it F&F

Regarding Toerless' comments, I'd have no problem in looking for a wording that 
becomes more palatable to the non-API purists. We could even make this a 
general approach to the problem...

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--
On 12/12/2017, 09:37, "Anima on behalf of Toerless Eckert" 
 wrote:

+1 supporting adoption of this document.
Also interested to contribute to the effort.

+1 on Mcr/Carstens suggestion to be fast & furios (don't drag this out for 
long).

Wrt. to APIs and IETF: I expect that we may need to refine terminology
to pass IESG review, such as maybe requiring us to more often emphasize how
this is an "abstract API", or definition of "northbound service features"
or the like (even in the title).

[ Any time we use the term "API" without further
atribute, there are folks wanting to misinterpret it as a "concrete API"
(for  specific programming language). Which is what the IETF does not like
(and has no real expertise in), and which the draft also not attempts to 
specify. ]

Cheers
Toerless

On Sat, Dec 09, 2017 at 05:57:48PM +0100, Carsten Bormann wrote:
> On Nov 29, 2017, at 12:35, Sheng Jiang  wrote:
> >
> > During the IETF100, there was a consensus that 
draft-liu-anima-grasp-api is fully consistent with the current ANIMA charter, 
under the condition it intends to be an Informational document. After the 
meeting, the authors have updated the document. The current intended status is 
Informational. There was an adoption call on this document as a ANIMA working 
group document in the ANIMA session, IETF100. There were supports and no 
objection as far as chairs heard. As an official procedure, we now confirm the 
adoption in the ANIMA mailing list.
>
> I wasn???t in the room when this was discussed.
>
> I believe it is a good thing that the IETF is not in the habit of 
automatically creating an API for each protocol that it defines (???IETF 
doesn???t do APIs???).  However, there are specific situations when creating 
APIs is useful:
>
> ??? adoption of a new technology may benefit from a common API being 
available.  E.g., RFC 2292/3542 has helped IPv6 adoption a lot by making 
applications possible that would have had to use IPv4 otherwise.  Similar, RFC 
6458 for SCTP.
> ??? the API may clarify the ???northbound interface??? of the protocol 
implementation.  Sometimes it is not clear from a protocol what the actual 
meaning of running the protocol is supposed to be.  While we probably don???t 
want to automatically define a ???service interface??? like in the OSI model 
for each protocol, a more innovative protocol may be hard to understand without 
the image of such an API in the mind of the reader.
>
> I believe both of these effects can be had here, so it is good that the 
authors have written up the API.
>
> I also agree that there should be an intent of finishing this quickly to 
aid adoption, and of revisiting the API again after a few years of getting 
experience ??? after all, this is not intended as a ???Standard".  This 
probably does not justify going for ???Experimental???: First, this isn???t 
really a protocol, and second, there is no formal experiment being run here 
that will be done at some point: This API is supposed to last unless we learn 
that it can be improved.
>
> So I completely agree with (what I understand was) the in-room consensus 
at IETF 100 and the sentiments that were expressed here.
>
> Grüße, Carsten

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima





Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad d