On Thu, Mar 01, 2018 at 09:49:49AM +0000, Ciavaglia, Laurent (Nokia -
FR/Paris-Saclay) wrote:
> Hello,
>
> Does the need to explicitly distinguish ANIMA work from HOMENET work still
> exist
wg chair hat
I am not sure what would have changed since we came to the conclusion.
contributor hat
I also don't look at "professionally managed" as a bad thing. I quite like it.
Not
sure who thinks its contentuous. I thought the thread just had some discussion
about which
factor we should mention as a reason for something.
> 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).
Well, if IETF asks, my explanation is always the same:
"professionally managed" =>
needs to support networks with highly complex to manage services/policies
understood/expressed by network operations. Large scale, various technologies,
etc.pp.
yada intent yada yada self dependency yada configuration yada operator shoots
himself in foot yada
== need secure inband connectivity plane which we call ACP.
which would have been designed differently if we had either a homenet (small,
limited features,
fully autonomic), or if we could expect ALL existing services in routers be
reimplemented
as ASA and just use GRASP as transport layer AND all the dependency graphing of
one Mr. Ciavaglia ;-)
Of course "professionally managed" is not the technical term equivalent to this
logic,
but its as good a explanation starter to that end that we did find so far. And
i think our
drafts do capture their respective aspects of this accordingly.
Homenet too as a word is the same type of discussion starter (small, simple, no
professional
management, fully autonomic). Hence "autonomic" is not the same good discussion
starter
because it applies to both anima and homenet.
> 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.
Sure. Just haven't seen us need to write down these terminology discussions any
more
to meet our current charter than we have already done. And if i'd look at
possible
next charter, i really think terminology around intent would be more important
(hint hint ;-)
> Best regards, Laurent.
Thanks & Cheers
Toerless
>
> -----Original Message-----
> From: Anima [mailto:[email protected]] On Behalf Of Brian E Carpenter
> Sent: Thursday, March 1, 2018 1:53 AM
> To: Toerless Eckert <[email protected]>
> Cc: [email protected]
> 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
> >>>> [email protected]
> >>>> https://www.ietf.org/mailman/listinfo/anima
> >>>
> >>> _______________________________________________
> >>> Anima mailing list
> >>> [email protected]
> >>> https://www.ietf.org/mailman/listinfo/anima
> >>>
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/anima
> >
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
