Subject: [Anima] Homenet feedback on the ANIMA charter

From: Benoit Claise <[email-masked]>
Date: Wed, 01 Oct 2014 15:20:46 +0200

Dear all,

Based on the previous UCAN BoF, we are considering having an ANIMA WG: 
Autonomic Networking Integrated Model and Approach
This is now a proposed charter, under consideration by the IESG.
This is your chance to provide feedback on 
http://datatracker.ietf.org/wg/anima/charter/
Note also that a BoF has been requested, just in case.
Since HOMENET was mentioned during the UCAN BoF, I thought of 
double-checking with you guys.

Regards, Benoit

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 1 Oct 2014 19:27:03 +0300

On 1.10.2014, at 16.20, Benoit Claise <[email-masked]> wrote:
> Based on the previous UCAN BoF, we are considering having an ANIMA WG: Autonomic Networking Integrated Model and Approach
> This is your chance to provide feedback on http://datatracker.ietf.org/wg/anima/charter/
> Since HOMENET was mentioned during the UCAN BoF, I thought of double-checking with you guys.

TL;DR: Please either add homenet (and solutions already in the WG) to the WG goals, or drop IoT too and just focus on enterprise.

Looking at the milestones, I am very curious about lack of requirements or architecture work before promoting solutions and even WGLCing them. 

Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.

It is not also clear to me how well the suitability of the solution has been evaluated. For implementation of some autonomic, distributed algorithms, point-to-point negotiation protocol such as the suggested solution is far from optimal. In case of homenet, we moved from hierarchical DHCPv6 PD (point-to-point hierarchy) to a distributed algorithm (draft-ietf-homenet-prefix-assignment*) which was result of over two years of draft updates, academic proving of correctness etc. 

Also, while dropping homenet from list of target things is _a_ way to solve the conflict that we already have autonomic solution for that particular problem which works (it was mentioned there before in e.g. IETF 90 not-quite-WG-forming BoF), even better would be to have a general solution that _also_ works in a homenet. Especially as IoT is just specialized type of homenet, I assume, although it is covered only by one mention in the whole charter (and the rest does not seem very IoT oriented).

Looking at the solutions, from homenet developer / draft writer point of view, I would welcome a general trust bootstrapping framework. I am not convinced by the current solution draft for that (it assumes too many components for a home network case at least). A lot of the other things seem somewhat enterprise-y (control plane with IPsec, own routing protocol and ULAs? Not in IoT device at least, nor probably in constrained homenet router), or just unsuitable, such as the negotiation protocol that does not seem like a good fit for distributed decision making which is usually the key thing in autonomic networking. 

Cheers,

-Markus

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 1 Oct 2014 15:58:08 +0200

Hello Benoit,

Looks like ANIMA’s goals are quite similar to Homenet’s indeed.
Please allow me to comment the charter.

1. Why would you put the ‘negociation protocol’ in the charter (even last call in the milestones !) ? It seems fair to me that discussions about what should be the approach and solution happen after the WG creation, isn’t it ?

2. "A solution for distributed IPv6 prefix management within a network." -> Please have a look to HNCP (draft-ietf-homenet-hncp) + Prefix Assignment Algorithm (draft-ietf-homenet-prefix-assignement). Ha, and we have running open-source code for all this as well: https://github.com/sbyx/hnetd.

3. "A solution for always-on, data plane independent connectivity between network elements (i.e., stable in the case of mis-configurations)." Sure the ‘data plane independent’ makes it a little bit more buzzy. But in the end this pretty much looks like the problem routing protocols are made to solve (The 'mis-configurations’ part is more about point 2.).

Regards,

- Pierre

Le 1 oct. 2014 à 15:20, Benoit Claise <[email-masked]> a écrit :

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2014 08:25:42 +1300

Pierre,

> Looks like ANIMA’s goals are quite similar to Homenet’s

Except that homenet has a limited scope and is well advanced
in its work.

> 1. Why would you put the ‘negociation protocol’ in the
> charter (even last call in the milestones !) ? It seems fair
> to me that discussions about what should be the approach and
> solution happen after the WG creation, isn’t it ?

Not really. The details are all to be discussed of course, but
the concept is fundamental to autonomics: devices talk to each
other rather than receiving instructions from above. (As Rene
Struik has pointed out, there is another way to look at it,
state synchronization, but that's largely a difference of
terminology.)

> 
> 2. "A solution for distributed IPv6 prefix management within
> a network." -> Please have a look to HNCP
> (draft-ietf-homenet-hncp) + Prefix Assignment Algorithm
> (draft-ietf-homenet-prefix-assignement). Ha, and we have
> running open-source code for all this as well:
> https://github.com/sbyx/hnetd.

Yes, in the homenet context. It's a bit different in the carrier
context. What we are really after is a general mechanism for the
future. If we miss the homenet boat, that's our fault for
starting late. There is a lot to learn from homenet, in my opinion.

> 
> 3. "A solution for always-on, data plane independent
> connectivity between network elements (i.e., stable in the
> case of mis-configurations)." Sure the ‘data plane
> independent’ makes it a little bit more buzzy. But in the end
> this pretty much looks like the problem routing protocols are
> made to solve (The 'mis-configurations’ part is more about
> point 2.).

Yes, for the problem that routing protocols solve, they do a
good job. But we are talking about all the problems that routing
protocols don't solve.

   Brian

>> Based on the previous UCAN BoF, we are considering having
>> an ANIMA WG: Autonomic Networking Integrated Model and
>> Approach This is now a proposed charter, under
>> consideration by the IESG. This is your chance to provide
>> feedback on http://datatracker.ietf.org/wg/anima/charter/ 
>> _______________________________________________ homenet
>> mailing list [email-masked] 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ homenet
> mailing list [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2014 08:44:51 +1300

Markus,

On 02/10/2014 05:27, Markus Stenberg wrote:
> TL;DR: Please either add homenet (and solutions already in
> the WG) to the WG goals, or drop IoT too and just focus on
> enterprise.

Personal comments on this:

1) One reason for not stating homenet as part of the scope is
that we do not want to interfere with the current progress in
homenet. Personally I think there is a lot to learn from
homenet, but as I just said to Pierre, we are too late to affect
homenet's choices. I will be delighted if the results can be
applied to homenets in future, of course.

2) I am also a little nervous about the IoT reference in the
charter. We haven't yet seen a use case description that would
apply to IoT (which has IMHO a much broader scope than home
networks, e.g. building services.)

I think the initial focus is indeed on enterprise and carrier
networks where the OPEX pain is greatest, but we should not
artificially limit the applicability either.

> 
> Looking at the milestones, I am very curious about lack of
> requirements or architecture work before promoting solutions
> and even WGLCing them.

There are the existing NMRG documents and there will be an
overview document, but we are following quite specific direction
from the ADs about this.

> Notably, adoption of a solution (discovery+negotiation
> protocol) before adoption of use cases seems like putting
> cart before the horse.

Again, we are following direction from the ADs.

> It is not also clear to me how well the suitability of the
> solution has been evaluated. For implementation of some
> autonomic, distributed algorithms, point-to-point negotiation
> protocol such as the suggested solution is far from optimal.
> In case of homenet, we moved from hierarchical DHCPv6 PD
> (point-to-point hierarchy) to a distributed algorithm
> (draft-ietf-homenet-prefix-assignment*) which was result of
> over two years of draft updates, academic proving of
> correctness etc.

There is a subtle point here. The idea is to produce generic
components that do *not* imply specific autonomic algorithms. If
we do it correctly, those components will support either a top
down or a distributed mechanism or even a blend of the two
approaches. So actually the solution choices come later: we
don't have to decide in advance between top-down and peer-to-peer.

> Also, while dropping homenet from list of target things is
> _a_ way to solve the conflict that we already have autonomic
> solution for that particular problem which works (it was
> mentioned there before in e.g. IETF 90 not-quite-WG-forming
> BoF), even better would be to have a general solution that
> _also_ works in a homenet. 

If we were having this discussion 5 years ago, I would agree.
But you homenet guys are ahead of us.

> Especially as IoT is just
> specialized type of homenet, I assume, 

As above - I don't think that's right; IoT is much broader.

> although it is covered
> only by one mention in the whole charter (and the rest does
> not seem very IoT oriented).

So should we say in the charter that the scope is everything but
the initial focus is enterprise and carrier?

> 
> Looking at the solutions, from homenet developer / draft
> writer point of view, I would welcome a general trust
> bootstrapping framework. I am not convinced by the current
> solution draft for that (it assumes too many components for a
> home network case at least). A lot of the other things seem
> somewhat enterprise-y (control plane with IPsec, own routing
> protocol and ULAs? Not in IoT device at least, nor probably
> in constrained homenet router), or just unsuitable, such as
> the negotiation protocol that does not seem like a good fit
> for distributed decision making which is usually the key
> thing in autonomic networking.

That means we have explained the negotiation idea badly. It is
not top-down negotiation like
draft-boucadair-network-automation-requirements. It is peer to
peer with top-down as a special case.

Thanks
   Brian

---

From: Rene Struik <[email-masked]>
Date: Wed, 01 Oct 2014 16:04:21 -0400

Dear colleagues:

I think it would be a mistake not to consider highly constrained networks and devices at first. If one would like to get anywhere close to 30-50 billion interconnected objects (the rosy marketing numbers by Cisco and Intel referenced everywhere), there is an absolute requirement to make trust lifecycle management and network management overhead virtually disappear, without the need for human intervention, except in exceptional cases. Without almost zero cost over the *entire* lifecycle of a device, while at the same time assuring a mix of ease of use - flexibility - security, forecasted internet of things type deployments figures may never materialize. Any solution direction that would not consider foremost the constraints of the deployment category that will soon outnumber all others should be discouraged. If one closely examines and designs for the nimble objects in the universe, it would obviously also fit for the less nimble; the other way around, this does not necessarily hold.

As argued before, I do agree with comments that solid footing for the effort needs more work (which, I think, has been echoed by the group during conf calls and by the AD).

Best regards, Rene

==
So should we say in the charter that the scope is everything but the initial focus is enterprise and carrier?

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

---

From: Steven Barth <[email-masked]>
Date: Wed, 01 Oct 2014 22:27:35 +0200

> Except that homenet has a limited scope and is well advanced
Still some of the essential underlying problems are the same and I think 
you should not discard the progress in this working group all too 
quickly. Instead adopting concepts and ideas from homenet  could very 
much benefit ANIMA. The underlying problems of "state synchronization" 
or "negotiation" are the same. Sure we've already built something on top 
of that but why not look at the foundation.

> state synchronization, but that's largely a difference of
Well I think your statement is a bit premature here. Yes, a negotiation 
protocol is certainly necessary.
However even superficially comparing 
draft-jiang-config-negotiation-protocol with draft-ietf-homenet-hncp 
shows that the problem can be tackled by completely different approaches 
and it would surprise me if these were the only ways to do it. Plus I 
can't really tell from a first quick look at it which of these 
approaches is more generic than the other. Perhaps we should try to 
compare both and see what could be improved in either variant or maybe 
find another variant which combines the best of both worlds?

Cheers,

Steven

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2014 11:18:20 +1300

On 02/10/2014 09:04, Rene Struik wrote:
> Dear colleagues:
> 
> I think it would be a mistake not to consider highly constrained
> networks and devices at first. 

That's a good comment and is more precise than the buzzword "IoT". It
would not distress me to see the buzzword removed.

However, my personal impression is that the resource-constrained
devices will be be carrying much management software at all, so
it would be the gateways to a whole cluster of constrained devices
that would be the target systems for Anima.

    Brian

> If one would like to get anywhere close
> to 30-50 billion interconnected objects (the rosy marketing numbers by
> Cisco and Intel referenced everywhere), there is an absolute requirement
> to make trust lifecycle management and network management overhead
> virtually disappear, without the need for human intervention, except in
> exceptional cases. Without almost zero cost over the *entire* lifecycle
> of a device, while at the same time assuring a mix of ease of use -
> flexibility - security, forecasted internet of things type deployments
> figures may never materialize. Any solution direction that would not
> consider foremost the constraints of the deployment category that will
> soon outnumber all others should be discouraged. If one closely examines
> and designs for the nimble objects in the universe, it would obviously
> also fit for the less nimble; the other way around, this does not
> necessarily hold.
> 
> As argued before, I do agree with comments that solid footing for the
> effort needs more work (which, I think, has been echoed by the group
> during conf calls and by the AD).
> 
> Best regards, Rene
> 
> ==

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2014 11:21:11 +1300

> find another variant which combines the best of both worlds?

I quite agree. We will be updating the config-negotiation-protocol draft
but I think there is a lot to learn from HNCP. I hope the words in
the charter don't imply otherwise.

   Brian

---

From: Mark Townsley <[email-masked]>
Date: Thu, 2 Oct 2014 02:26:20 +0200

> But you homenet guys are ahead of us.

Yes and no.

Yes, homenet is ahead of anima in terms of, say, a distributed IPv6 prefix configuration algorithm. This is one of the first things the group began tackling, so there's quite a bit of water under the bridge here. However, while I have seen a lot of recent effort in security, homenet has a long way to go here. This happens to be something I get the impression anima has been working on for quite a while.

You say that you wish to learn from what homenet has done, yet the current proposed anima charter says:

...autonomic service agents will demonstrate the usage of the above
mentioned autonomic infrastructure components with two use cases:

o A solution for distributed IPv6 prefix management within a network.
Although prefix delegation is currently supported, it relies on human
action to subdivide and assign prefixes according to local requirements,
and this process could become autonomic.

This use case is precisely what draft-ietf-homenet-prefix-assignment does (which has roots all the way back to draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, this is a solved problem - with an algorithm that has been applied not just to HNCP, but to OSPF and ISIS. 

I do think that there is room for a non-distributed algorithm that is tied more to centralized mechanisms, particularly as you move closer to a more tightly managed system. But for a distributed approach, as you observed Brian, homenet is rather far along. 

This is just the most obvious example that jumps out at me. There may be something similar to say about HNCP itself, the use of src+dst routing, etc. In any case, It's not hard to extrapolate from here that in a year's time or so, if we continue on the current trajectory, homenet will have come up with its own non-anima secure bootstrapping, and anima will have come up with its own non-homenet distributed IPv6 prefix configuration.  

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2014 16:16:16 +1300

> This use case is precisely what draft-ietf-homenet-prefix-assignment does (which has roots all the way back to draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet, this is a so…

Well, we have a bug in our short description, because the intention is to
support prefix assignment in a carrier scenario, which is different
in many ways. Good catch.

> This is just the most obvious example that jumps out at me. There may be something similar to say about HNCP itself, the use of src+dst routing, etc. In any case, It's not hard to extrapolate from…

Which we should try to coordinate, since I see no reason in
theory why there can't be common underlying mechanisms between
enterprise, carrier and SOHO. But I don't want to hear in 2 years
time that homenet is stuck because anima hasn't met its milestones.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 2 Oct 2014 15:26:49 +0900

On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter <
[email-masked]> wrote:

> > This use case is precisely what draft-ietf-homenet-prefix-assignment
> does (which has roots all the way back to
> draft-arkko-homenet-prefix-assignment-00 in October 2011). So to homenet,
> this is a solved problem - with an algorithm that has been applied not just
> to HNCP, but to OSPF and ISIS.
>
> in many ways.

Really? Which ways?

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 2 Oct 2014 11:20:17 +0300

> applied to homenets in future, of course.

Well, it sounds as if you plan to WGLC your negotiation protocol probably around the time we WGLC HNCP (or sooner? who knows).

> artificially limit the applicability either.

I would just say that you aim at enterprise networks and leave it at that, then. Considering home networks, and even more so constrained devices in the IoT land have different management model and resources than your typical enterprise devices.

> overview document, but we are following quite specific direction

Well, at least providing links to them in the charter would be probably good idea then. As it is, it looks like ‘we have solution, here is the WG’ to me.

> don’t have to decide in advance between top-down and peer-to-peer.

A protocol (draft-jiang-config-negotiation-protocol) that is essentially point-to-point state push/pull mechanism does not seem like natural fit for that (+- some discovery).

The scalable solutions with such protocol require hierarchies of delegation. For example, given prefix delegation problem, the reasonable (=low number of total message exchanges) solutions wind up subdividing the prefix hierarchically, or alternatively with some ‘god node’(s) that perform the allocations. It becomes harder if you have multiple sources of same resource (=prefix) or want to be robust in case of failure.

> the initial focus is enterprise and carrier?

Or that you are developing enterprise solution and it can work for anything with luck. 

> peer with top-down as a special case.

Sure, it is simple ‘who is there’, ’{can I haz X, (yes|no|no but you can have Y)}+’  protocol as far as I can read the draft anyway (draft-jiang-config-negotiation-protocol-02)

It is not obvious to me how it would be even used to tell other all other nodes about e.g. change in some network parameter (say, NTP server). Is it a ‘request’? Who is it sent to? How to prevent duplication of sending it to nodes that already did receive it?

From my point of view, a general network infra protocol needs

- discovery
- state push/pull _network wide_

HNCP does this; I am not sure how CDNP can be used for this, but I welcome examples.

Cheers,

-Markus

---

From: Benoit Claise <[email-masked]>
Date: Thu, 02 Oct 2014 14:16:47 +0200

> Looking at the milestones, I am very curious about lack of requirements or architecture work before promoting solutions and even WGLCing them.
As mentioned in 
http://www.ietf.org/mail-archive/web/anima/current/msg00246.html

    A few observations, to start with:
    1. Autonomic Networking could be a huge explanatory field.
    2. From the BoF, we heard (among other points):
         There is interest but focus ... focus ... focus on things that
    could be done quickly
    3. The IESG has also been realizing that the process of problem
    statement/use cases/requirements/architecture/protocol takes way too
    long for the industry.
    4. If a great architecture document to rule all autonomic functions
    would have been easy, it would been done already. In NMRG for
    example, which had plenty of time to think about it! So an
    architecture as a starting point is not the right approach.
    5. A WG can always be re-chartered in future phases

    These are the reasons why Joel and I asked the BoF chairs to lead a
    charter discussion, focusing on only 2 use cases

> Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.
Valid point.

Regards, Benoit
> .

---

From: Laurent Ciavaglia <[email-masked]>
Date: Thu, 2 Oct 2014 14:57:15 +0200

Dear Benoit, Markus, all,

>> Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse.

Indeed a valid point, however before concluding here, some insights 
might help:
     -OPS ADs gave guidance to focus on (applicability on) 2 use cases only.
     -The solution adoption milestone shall read as _applicability_ of 
the protocols onto the two proposed/elected use cases (the milestone 
should be rewritten in that sense for more clarity).
     -The WG aims at developing protocols reusable _among __multiple_ 
use cases.
     -An initial step of the WG should be to extract, from these 
multiple use cases, the boundaries / problems these protocols have to 
solve.

HTH, best regards, Laurent.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2014 07:58:34 +1300

>> support prefix assignment in a carrier scenario, which is different

That was the point of draft-jiang-auto-addr-management which was
briefly presented at the UCAN BOF.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Oct 2014 15:07:32 -0400

> http://datatracker.ietf.org/wg/anima/charter/

Thanks.

I have read the charter.
Thank you for trying to restrict it to something focused.
I think you have enough focus, but there still significant space for scope
creap.  Why not build this issue into the charter?

    Mar 2015 - recharter to refocus scope

[In reading it, I was reminded of the SNMP v2 security wars of 1995.  Can
we have enough security present in order to configure the system to have
security, was part of the underlying debate.  I think we can do it now.]

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Oct 2014 15:11:28 -0400

> TL;DR: Please either add homenet (and solutions already in the WG) to
    > the WG goals, or drop IoT too and just focus on enterprise.

I see your point; if you think that much IoT will be in the home.

However, there are significant areas of IoT deployment into industrial
settings which have very different availability of human resources.

While in the home, there is perhaps an IoT : HUMAN ration of 1000:1,
which is to say that in an average home of 100 devices, there is barely
10% of a human available set them up, in industrial settings the ratio
could be even worse (10000:1?), but still that might leave a team of ten
trained humans available to create Intents.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2014 08:18:15 +1300

> Well, it sounds as if you plan to WGLC your negotiation protocol probably around the time we WGLC HNCP (or sooner? who knows).

I have no idea. The homenet milestones haven't been updated for
2 years, but I would expect HNCP to be much sooner than Anima.

> I would just say that you aim at enterprise networks and leave it at that, then. Considering home networks, and even more so constrained devices in the IoT land have different management model and…

Yes, but we are (to be frank) trying to disrupt the current enterprise
model and I don't want to constrain the thinking by constraining
the scope.

> Well, at least providing links to them in the charter would be probably good idea then. As it is, it looks like ‘we have solution, here is the WG’ to me.

The NMRG drafts are cited in the charter. We are trying to avoid
claiming that existing solution proposals *are* the draft solutions,
because that's the WG's choice to make.
> A protocol (draft-jiang-config-negotiation-protocol) that is essentially point-to-point state push/pull mechanism does not seem like natural fit for that (+- some discovery).

Well, I disagree, but that again is a job for the WG.

> The scalable solutions with such protocol require hierarchies of delegation. For example, given prefix delegation problem, the reasonable (=low number of total message exchanges) solutions wind up…

If a resource needs a hierarchy you would contstruct that on top of
the negotiation protocol, not as an intrinsic feature of the protocol.

> Or that you are developing enterprise solution and it can work for anything with luck. 

No, not with luck, if we do it right. That would be like saying that
DHCP(v4) was designed for campus networks but would work for
home networks with luck.

> Sure, it is simple ‘who is there’, ’{can I haz X, (yes|no|no but you can have Y)}+’  protocol as far as I can read the draft anyway (draft-jiang-config-negotiation-protocol-02)

Exactly. And that is pretty close to Turing-complete so it
could be used very generally.

> It is not obvious to me how it would be even used to tell other all other nodes about e.g. change in some network parameter (say, NTP server). Is it a ‘request’? Who is it sent to? How to prevent d…

Yes. I noticed that when considering Rene's comment about state
synchronization and it needs more work. Nobody is saying that
it is fully baked yet.

> HNCP does this; I am not sure how CDNP can be used for this, but I welcome examples.

It's intentionally peer-to-peer so network-wide requires propagation;
but I don't understand how HNCP could do some of the other things we
want. There will be a revised requirements in a forthcoming draft, so
I'd rather have that discussion later.

Let me be clear: if HNCP can be generalised to do what we need (which
would probably mean changing its name slightly) I'd be delighted.
There is absolutely nothing to be gained by having two protocols if
one will work.

   Brian

---

From: Mark Townsley <[email-masked]>
Date: Tue, 7 Oct 2014 11:00:50 +0200

The charter as written now aims to develop building blocks which can be applied commonly across a wide range of networks including enterprise, SP, (home?), and IOT, yet the very first use-case listed in order to provide WG focus is restricted to carrier-only? (and, to Lorenzo's point, what does that actually mean with respect to IP address assignment?)

If a carrier-only use-case is doing its job of focusing the WG, it will naturally lead to carrier-centric building blocks, contradictory to the stated goal of the group.

- Mark

> On Oct 2, 2014, at 8:26 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
>> On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter <[email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Oct 2014 08:44:09 -0400

Mark Townsley <[email-masked]> wrote:
    > The charter as written now aims to develop building blocks which can be
    > applied commonly across a wide range of networks including enterprise,
    > SP, (home?), and IOT, yet the very first use-case listed in order to
    > provide WG focus is restricted to carrier-only? (and, to Lorenzo's
    > point, what does that actually mean with respect to IP address
    > assignment?)

    > If a carrier-only use-case is doing its job of focusing the WG, it will
    > naturally lead to carrier-centric building blocks, contradictory to the
    > stated goal of the group.

I want to change the word "carrier-only" for "professionally-managed" in your
wording, and therefore agree, and say, "Good"

Managed networks, be they in ISPs or industrial IoT settings have different
(perhaps simpler) solutions than in the home.   I think the assumption that
"IoT" implies homenet networks is incorrect: there are lots of IoT which is
not in the home; and I totally agree that managed-solutions are inappropriate
in the home.

I don't think one-size fits-all here.

I suggest that ANIMA focus on "professionally-managed" networks first, with
"Homenet" being a secondary consideration, akin to IPv4 is in the homenet WG.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 7 Oct 2014 16:13:24 +0200

> On Oct 7, 2014, at 2:44 PM, Michael Richardson <[email-masked]> wrote:
> 

I like that suggestion, with a caveat. The caveat being that I think there is room for a "professionally managed" home network as well - something homenet to date has touched on,  but for the most part avoided. 

It should be up to the user to decide to have their home network professionally managed of course, but as long as that choice is made, a "professionally managed network" WG might be able to provide tooling equally as well for the home as for an enterprise (or SOHO, etc, to Leddy's point). Here is where including what homenet has already done is important for a new WG, if nothing else but to coexist properly between the two solutions. For example, Homenet has had to spend quite a bit of cycles dealing with what we think the home network will look like by the time HNCP arrives (Hierarchical DHCPv6-PD,  HIPNET, etc.). Anima should be able to make the same consideration for how to operate with HNCP in the network as well - e.g., new "professionally managed" solution when available, "non-managed" via HNCP otherwise.

In terms of scope of work and where it is done, I'm not sure this means the "professionally managed home" work should done in anima or homenet WGs, but I do know we shouldn't do it with blinders on.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 7 Oct 2014 16:23:17 +0200

> On Oct 2, 2014, at 9:18 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>  but I would expect HNCP to be much sooner than Anima.

Then anima is going to have to deal with HNCP one day in any case. The handoff between the distributed manner in which HNCP carves up and allocates IP prefixes will need to mesh with whatever anima comes up with.

The good news is that homenet is far along enough that it has thought about this type of thing, with an algorithm, code, and drafts that include marking individual prefixes by manual "or other means" configuration while still supporting automatic determination of subnets that were not otherwise addressed. This is the kind of thing that I want to be sure anima keeps in mind, lest our worlds collide.

- Mark

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Oct 2014 13:51:07 -0400

Mark Townsley <[email-masked]> wrote:
    >> I suggest that ANIMA focus on "professionally-managed" networks first,
    >> with "Homenet" being a secondary consideration, akin to IPv4 is in the
    >> homenet WG.

    > I like that suggestion, with a caveat. The caveat being that I think
    > there is room for a "professionally managed" home network as well -
    > something homenet to date has touched on, but for the most part
    > avoided.

Sure;  we have avoided it because I think most see the only professional
nearby being the ISP, and few of *us* professionals want them mucking around
in our home.  That's the personal experience of IETF contributors as
individuals.

However, we also see in our architecture that we expect two be able to get
service from two ISPs, so in the end, our pessimism about the ability of the
ISP professional to manage our home network is legitimate.  There can't be
only one --- cooperation is required.

There are other professional organizations that would like to help manage our
homes: Apple, Google and Microsoft come to mind.  Yet, even there, we expect
cooperation.   That's why the secure bootstrap problem is more difficult in
the home than it is, in for instance, an oil refinery.

    > It should be up to the user to decide to have their home network
    > professionally managed of course, but as long as that choice is made, a
    > "professionally managed network" WG might be able to provide tooling
    > equally as well for the home as for an enterprise (or SOHO, etc, to
    > Leddy's point). Here is where including what homenet has already done
    > is important for a new WG, if nothing else but to coexist properly
    > between the two solutions. For example, Homenet has had to spend quite
    > a bit of cycles dealing with what we think the home network will look
    > like by the time HNCP arrives (Hierarchical DHCPv6-PD, HIPNET,
    > etc.). Anima should be able to make the same consideration for how to
    > operate with HNCP in the network as well - e.g., new "professionally
    > managed" solution when available, "non-managed" via HNCP otherwise.

    > In terms of scope of work and where it is done, I'm not sure this means
    > the "professionally managed home" work should done in anima or homenet
    > WGs, but I do know we shouldn't do it with blinders on.

What do you mean "with blinders on" here?
Usually that means that the horse has blinders to avoid distraction by things
that aren't in front of them.   So I think that you mean that professional
managed ideas should be visible to Homenet and ANIMA, but do you really mean:
        ANIMA should pay attention to non-managed networks
        HOMENET should pay attention to managed networks

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Oct 2014 08:10:49 +1300

> in our home.  That's the personal experience of IETF contributors as

As far as the Anima charter goes (see subject line), we need to use the
use cases to *test* the Anima technical choices (when we make them)
against the real world. So eventually we'd need all kinds of use cases,
which is why the charter mentions a wide scope. But we need to start
with a finite task, which is why the charter mentions a couple
of specific cases.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Oct 2014 08:18:40 +1300

> Then anima is going to have to deal with HNCP one day in any case. The handoff between the distributed manner in which HNCP carves up and allocates IP prefixes will need to mesh with whatever anima…

Indeed. It's a given that the anima solutions have to be able to coexist
with what came before.

> The good news is that homenet is far along enough that it has thought about this type of thing, with an algorithm, code, and drafts that include marking individual prefixes by manual "or other mean…

The negotiation model we have in mind for anima would allow one device
to refuse a request from another - I think that is sufficient to allow
a resource such as a prefix  to be marked as assigned by another method
and therefore not available for negotiation.

   Brian

---

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Oct 2014 11:54:07 +0200

> multiple use cases, the boundaries / problems these protocols have to 
The charter has been updated to reflect this.

Regards, Benoit