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

From: "Ciavaglia, Laurent (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Thu, 1 Mar 2018 09:49:49 +0000

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:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, March 1, 2018 1:53 AM
To: Toerless Eckert <[email-masked]>
Cc: [email-masked]
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-masked]
>>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>
>> _______________________________________________
>> Anima mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/anima
> 

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Mar 2018 18:07:00 +0100

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

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.

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

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 01 Mar 2018 17:10:55 -0500

> Does the need to explicitly distinguish ANIMA work from HOMENET work

yes. It's not just because we want to stay out of HOMENET's hair.
It's because we have a different set of assumptions.   In ANIMA we may
reasonably say, "THERE WILL BE AN X" (which will properly run, etc.).
We assume a budget for equipment and for people, and we assume that there are
more than two people involved.   We also assume that a goal we have is to
reduce the amount of effort (and travel!) required by the most senior of the
people.

While in HOMENET, you can not postulate an X unless you can determine
who will provide it, how many will be provided, and which one will be elected
as the master-X.   HOMENET also can generally assume that the network is
relatively small: if not in number of nodes, then at least in extent.
For instance,. a rural school with 200 chromebooks and no support from a
centralized IT person falls into HOMENET.

While a boutique global ISP might have only 100 routers, two in each of 50
cities, and clearly falls into ANIMA, despite having fewer nodes than the
rural school.

At the same time, a (inter)network of rural school(s), being managed
centrally by an IT person is again, ANIMA.

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

We argued about the term, and concluded that this term was sufficiently
inclusive that it covered Tier-1 ISPs, Residential ISPs, as well as big
and medium sized enterprises.   It's unlikely that a small enterprise would
on it's own count, unless they had outsourced their management.   We just
don't care how the profession is involved.

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

So, again, in your home or mine, our home networks are likely more
professionally managed than many enterprise networks.  Am I more likely to
use ANIMA than HOMENET protocols in *MY* home?  Maybe.
That's why we didn't write "home" or "enterprise" networks.

Having said this, there is interest in trying to find a way to make BRSKI
work in a HOMENET.  The problem is that X=JRC, and how will it be provided?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-