Subject: [Anima] Ted Lemon's Block on charter-ietf-anima-00-15: (with BLOCK)

From: "Ted Lemon" <[email-masked]>
Date: Wed, 29 Oct 2014 17:23:38 -0700

Ted Lemon has entered the following ballot position for
charter-ietf-anima-00-15: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-anima/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

The thing I still see missing in this charter is an explanation of how
"professionally managed" and "autonomic" mesh.   What does it mean for an
autonomic network to be professionally managed?   What distinguishes an
anima network from a homenet, for example?   The charter still reads as
though it's solving the same problem as homenet; I realize that this
isn't what the proponents actually have in mind, but some greater clarity
would be nice: it's still not clear in my mind from reading the charter
or from my discussion with Joel and Benoit.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Oct 2014 14:20:28 +1300

Ted,

> autonomic network to be professionally managed?   

I think the question is the other way round: what does it take for
a professionally managed network to be (partially) autonomic?
Which of course is intended to reduce the tedious part of the
management work, without removing managerial control. Answering
that question is the WG's purpose.

So, a professionally managed network is one that has professional
managers. I don't think we mean anything more subtle than that.

> What distinguishes an
> though it's solving the same problem as homenet; 

It is, but it's solving it for a different type of network: for example,
a network that's a thousand times bigger than a homenet, has many more
types of parameter to configure, has paying customers with contracts,
has staff on duty 24x7, and a 99.999% availability target.

That doesn't logically exclude common components in the solution,
of course. But there are IMHO strong reasons not to create any dependency
of homenet on results from anima.

   Brian

> I realize that this
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 21:28:53 -0400

> of homenet on results from anima.

I agree.  I just don't see that in the charter.   To be clear, simply saying "we will consult homenet" and "we are interested in professionally managed networks" doesn't really convey that point, because you haven't said how what you are doing is different.  If the only difference is the size of the network, that's pretty weak, and I don't think that _is_ the only difference.   I think you intend to do something that looks a lot different, even if there are some common elements at the bottom.   I'm just asking you to articulate what that difference is in the charter.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 29 Oct 2014 18:33:27 -0700

> http://datatracker.ietf.org/doc/charter-ietf-anima/

It implies to me that the parameters governing the system were applied
by a manager and not the product of a set of extrinsic initial
conditions and the expression of a set of algorithms.  That fact that
you can configure your homenet is not a necessary condition for it's
operation, and and fact you hope to have something operates in the
absence of signficant deliberate intent.

so to contrast.

...
Additionally, management and optimisation of operational device
configurations is
expensive, tedious, and prone to human error.
...
This WG is intended to mitigate this duplication of similar mechanisms
and heavy
dependency on human actions, in particular by facilitating secure
closed-loop
interaction directly between network elements to satisfy management intent.
This motivates the introduction of a control paradigm where network
processes,
driven by objectives (or intent), coordinate their local decisions,
autonomically translate them into local actions, and adapt them
automatically
according to various sources of information including external
information and
protocol information bases.
...

Speaks to the nature of managed, deliberately designed and laid out but
automatically triggered set of autonomic actions.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 21:46:16 -0400

> automatically triggered set of autonomic actions.

OK, that helps.   I didn't really get that from the text, though.   How about:

 This WG will develop a system of autonomic functions that carry
 out the intentions of the network operator without the need for detailed
 low-level management of individual devices.   This will be done by providing
 a secure closed-loop interaction mechanism whereby network elements
 cooperate directly to satisfy management intent.

 The working group will develop a control paradigm where network
 processes coordinate their decisions and automatically translate
 them into local actions, based on various sources of information
 including operator-supplied configuration information and protocol
 information bases.

But what are protocol information bases?   do you mean MIBs and YANG schemas?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Oct 2014 15:01:05 +1300

below...

>  including operator-supplied configuration information and protocol

Works for me
> But what are protocol information bases?   do you mean MIBs and YANG schemas?

I suppose, but probably these are really part of "operator-supplied configuration
information" anyway.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2014 22:03:48 -0400

> I suppose, but probably these are really part of "operator-supplied configuration

Fewer words is always better. :)

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 30 Oct 2014 02:54:22 +0000

Hi, Ted,

Reply in lines.

> including operator-supplied configuration information and protocol

The above proposed text works for me.

>But what are protocol information bases?   do you mean MIBs and YANG

I have no problem to remove "protocol information bases". My guess is it means the control paradigm will also combine information from the existing protocols, such as routing protocol, etc.

Should we update the online draft charter now (only Benoit has the access)? Or you can clear your BLOCK based on that we have accepted the proposed text?

Best regards,

Sheng

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 Oct 2014 00:07:44 -0400

Dear colleagues:

I do appreciate word smything, but do not understand how the stated 
goals mentioned in the draft charter (charter-ietf-anima-00-15) tie into 
the text below and correlate with the "analyzed technical gaps in 
draft-irtf-nmrg-an-gap-analysis"?

The text below seems to be entirely "operator" centric, which is 
contrary to what is mentioned in the 
"draft-irtf-nmrg-autonomic-network-definitions" and 
"draft-irtf-nmrg-an-gap-analysis-02" documents (the word "operator" is 
only mentioned in the "definition" draft in sections about non-goals;  
it is not mentioned in the "features needed" section of the 
"gap-analysis" draft).

More importantly (to me), but I already made this point, is that it 
seems to exclude from the scope the ultimate environment where 
semi-automatic networking could prove itself: constrained networks. If 
those networks are supposed to dwarf all other networks 10 years from 
now, wouldn't it be somewhat imprudent to put language in that is 
seemingly aimed at circumventing that area?

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 08:16:12 -0400

> I have no problem to remove "protocol information bases". My guess is it means the control paradigm will also combine information from the existing protocols, such as routing protocol, etc.

Ah, perhaps you should say that, then.

> Should we update the online draft charter now (only Benoit has the access)? Or you can clear your BLOCK based on that we have accepted the proposed text?

Let's get the text the way we want in the charter, and then I will clear.   There's no rush here--we have all agreed to the path forward, and I think we're pretty clearly on track for the meeting in Honolulu to be a WG meeting and not a BoF.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 08:18:42 -0400

On Oct 30, 2014, at 12:07 AM, Rene Struik <[email-masked]> wrote:
> More importantly (to me), but I already made this point, is that it seems to exclude from the scope the ultimate environment where semi-automatic networking could prove itself: constrained networks. If those networks are supposed to dwarf all other networks 10 years from now, wouldn't it be somewhat imprudent to put language in that is seemingly aimed at circumventing that area?

I don't see where in the current charter constrained networks are excluded.   Indeed, I don't even find the word "constrained" in the charter.   Why do you think they are excluded?

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 Oct 2014 08:44:10 -0400

There was a thread on a draft charter change that suddenly happened 
between version 14 and 15:

See, e.g.,  my earlier message 
http://www.ietf.org/mail-archive/web/anima/current/msg00499.html in 
response to this. Brian Carpenter et al also weighed in here.

[excerpt email Benoit Claise, 
http://www.ietf.org/mail-archive/web/anima/current/msg00496.html]
It seems to us that "professionally-managed networks" is what ANIMA is
after. And it's potentially a distraction to try to segment the scope
based on enterprise, ISP, homenet, or IoT. What is IoT after all?

OLD:     The ANIMA working group will initially focus on enterprise,
ISP networks and IoT.
NEW:    The ANIMA working group focuses on professionally-managed
networks

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 08:54:06 -0400

> based on enterprise, ISP, homenet, or IoT. What is IoT after all?

Right.   The problem is that IoT is not a good class distinction to make, not that IoT is out of scope.   Some IoTs are in scope; others are not.   What distinguishes the two is whether they are top-down ("professionally") managed, or are expected to self-configure without operator intervention.   The latter case is out of scope.

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 Oct 2014 09:07:42 -0400

Hi Ted:

There is virtually never almost complete self-configuration, even in not 
professionally managed networks (whatever the term means - see, e.g., 
http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html).

More importantly to charter discussions: none of the "professionally 
managed"  and strictly "operator base" was brought during the Anima conf 
calls I have been on. Either I have missed this (please provide a 
pointers to Anima charter discussions and consensus conclusion there) or 
there is some backroom discussion where this was discussed. In case of 
the latter that is fine, but still up to debate in Anima chartering sense.

Best regards, Rene

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 09:13:14 -0400

On Oct 30, 2014, at 9:07 AM, Rene Struik <[email-masked]> wrote:
> More importantly to charter discussions: none of the "professionally managed"  and strictly "operator base" was brought during the Anima conf calls I have been on. Either I have missed this (please provide a pointers to Anima charter discussions and consensus conclusion there) or there is some backroom discussion where this was discussed. In case of the latter that is fine, but still up to debate in Anima chartering sense.

That's between you and the ops ADs.   I'm just telling you what we've discussed.   If you want unmanaged ad-hoc configuration, that's already in homenet's charter, so I think it's out of scope for a new working group.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 30 Oct 2014 15:16:35 +0100

Thanks Ted for your proposed text.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Thu, 30 Oct 2014 15:48:59 +0100

Hi René,

> Hi Ted:
>
> There is virtually never almost complete self-configuration, even in 
> not professionally managed networks (whatever the term means - see, 
> e.g., 
Do you have better wording for "professionally managed"?
This is the boundary as explained by Ted:

    The problem is that IoT is not a good class distinction to make, not that IoT is out of scope.   Some IoTs are in scope; others are not.   What distinguishes the two is whether they are top-down ("professionally") managed, or are expected to self-configure without operator intervention.   The latter case is out of scope.

> managed"  and strictly "operator base" was brought during the Anima 
> conf calls I have been on. 

> Either I have missed this (please provide a pointers to Anima charter 
> discussions and consensus conclusion there) or there is some backroom 
> discussion where this was discussed. In case of the latter that is 
> fine, but still up to debate in Anima chartering sense.
Note that participants to the ANIMA conf calls were ANIMA people, even 
if there were open to anybody.
When the charter review was introduced, we took into account the 
feedback from the homenet people.
In terms of "backroom discussion", there were none. Ted, Joel, and I had 
a call, during which we tried to clarify the situation/open issues.
Note sure 3 ADs discussing can be classified " backroom discussion".

Regards, Benoit
>> Right.   The problem is that IoT is not a good class distinction to 
>> make, not that IoT is out of scope.   Some IoTs are in scope; others 
>> are not.   What distinguishes the two is whether they are top-down 
>> ("professionally") managed, or are expected to self-configure without 
>> operator intervention.   The latter case is out of scope.
>>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 30 Oct 2014 08:57:46 -0700

> That's between you and the ops ADs.   I'm just telling you what we've discussed.   If you want unmanaged ad-hoc configuration, that's already in homenet's charter, so I think it's out of scope for…

An ad-hoc network for a trade-show, a battlefield, city, factory etc is
in scope for homenet ? Whats exactly the line between homenet and 
manet then ? "Do not move this router from bedroom to kitchen,
it would step on manet's toes" ?

Sorry for the lame joke, but i do not think we can scope WGs reasonably
against others adjacent work by pattern matching words like ad-hoc.

Wrt. to "professionally managed" vs. "fully/semi-autonomic": I think
that are not two sides of a coin, but a continuum. IMHO, we step over
a line when we do somthing that is too experimental into the far
end of that spectrum to achieve successful near/mid-term deployments. 

Let me try to put in my words and explanation of ad-hoc, distinction
to homenet and the impact of "professional" management.

Homenet allows me to throw together routers and get an autonomically 
running network for all attached endpoints. And i thought this was
primarily for networks like you would build them for a private residence
and manage between Mrs Jones and her internet SPs.

For an anima network i throw together routers, L2 switches and other 
network equipment for a factory, city, enterprise, service-provder 
network. I take into account "professional" security/inventory management
aspects and try to get that process as much zero-touch as feasible.

When its done, i do not necessarily want default transparent end-to-end
IP connectivity for all attached devices. Instead, i just want transparent
OAM connectivity for all "professional" operations (ssh/cli...provisioning
tools...SDN controller).  I then want simplification/automation of these
"professional" processes.  And i want indestructible failsafe inband OAM
connectivity whenever the "professional" operations  makes mistakes
with eg: vpn/vrf, routing, security/access and other policies in the
network - and would in a current network disconnect themselves from
those devices they mean to manage. 

Cheers
    Toerless

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 Oct 2014 15:00:38 -0400

[apologies for the 4 hr delayed response - client meetings (my day job)]

Hi Benoit:

Unfortunately, I do not have an easy substitute for "professionally 
managed". The term itself is almost meaningless to scope discussions and 
suggests a dichotomy that does not really exist (imho). Please see the 
earlier remarks on how ambiguous this term is, including my reference 
earlier today to, e.g., 
http://www.ietf.org/mail-archive/web/homenet/current/msg04008.html.

Network management should not be type cast and put into squares. In this 
respect, I think Toerless Eckert worded this as well in his email this 
morning, October 30, 2014, see 
http://www.ietf.org/mail-archive/web/anima/current/msg00552.html.

The granularity of network management is more a continuum and should not 
be something type-cast according to key words (that is simply 
territorial infighting and would seem to be detrimental to trying to 
come up with a network management architecture that would unite an 
entire spectrum). I expect the main differences (at least from a 
security perspective) between what some present as "professional" vs. 
"nonprofessional" to be in terms of security policy initialization and 
maintenance, not so much protocol algorithmic. Hence, my perspective 
that this dichotomy is false (at least with security glasses on [I see 
networks as security engines]).

I think this term has no place in the charter, nor any other term that 
seems to suggest an artificial problem partitioning.

Last point: indeed, the Anima calls were by definition participated in 
by people interested in the topic area. Here, to my knowledge, this 
artificial dichotomy did not come up.

> conf calls I have been on. Either I have missed this (please provide a 
> pointers to Anima charter discussions and consensus conclusion there) 
> or there is some backroom discussion where this was discussed.

Best regards, Rene

On 10/30/2014 10:48 AM, Benoit Claise wrote:
> In terms of "backroom discussion", there were none. Ted, Joel, and I 
> had a call, during which we tried to clarify the situation/open issues.
>>> ("professionally") managed, or are expected to self-configure 
>>> without operator intervention. The latter case is out of scope.
>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Oct 2014 12:58:54 +1300

> That's between you and the ops ADs.   I'm just telling you what we've discussed.   If you want unmanaged ad-hoc configuration, that's already in homenet's charter, so I think it's out of scope for…

In my mind it was always implicit in the discussions that we were
going first for networks where human-based OPEX was a major concern.
I can well believe that this was not obvious in the charter text
until recently.

Purely personally, I don't want to produce solution elements that
cannot be applied in networks that don't fit that profile, whether
they are IOT or homenet or whatever. But (getting back to some
earlier discussion) we must not attempt to boil the ocean in one go,
so the initial WG charter scope has to be modest.

    Brian

---

From: Laurent Ciavaglia <[email-masked]>
Date: Fri, 31 Oct 2014 10:21:25 +0100

Dear Ted, all,

> But what are protocol information bases?   do you mean MIBs and YANG schemas?

e.g. LSDB for OSPF.
the protocol information bases are the set of (internal) information 
used by the protocols for their functioning -by contrast to the external 
information bases/sources that can be used to improve/augment their 
capabilities e.g. using traffic measurements (TE routing)...
This latter part on external information was "dropped" from the charter 
text but was useful to explain the "levels" of autonomic functions.

Hope it helps.
Best regards, Laurent.

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Advanced Internet Research

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

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

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

address: Route de Villejust | 91620 Nozay | France