Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 14:57, Laurent Ciavaglia wrote: Dear Benoit, Markus, all, On 02/10/2014 14:16, Benoit Claise wrote: On 01/10/2014 18:27, Markus Stenberg wrote: Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit 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. The charter has been updated to reflect this. Regards, Benoit HTH, best regards, Laurent. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
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 lore...@google.com wrote: On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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. 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. Really? Which ways? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Mark Townsley m...@townsley.net 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. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgp1C7U5I_7MV.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On Oct 7, 2014, at 2:44 PM, Michael Richardson mcr+i...@sandelman.ca 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Mark Townsley m...@townsley.net 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 -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpHOKRSQH0IV.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 08/10/2014 03:23, Mark Townsley wrote: On Oct 2, 2014, at 9:18 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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. 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 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. 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 - Mark 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. 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. 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. 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. 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. 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. 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 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. If a resource needs a hierarchy you would contstruct that on top of the negotiation protocol, not as an intrinsic feature of the protocol. 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? 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. 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
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 1.10.2014, at 22.44, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
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.
Well, it sounds as if you plan to WGLC your negotiation protocol probably
around the time we WGLC HNCP (or sooner? who knows).
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.
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.
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.
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.
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.
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.
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?
Or that you are developing enterprise solution and it can work for anything
with luck.
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.
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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Dear Benoit, Markus, all, On 02/10/2014 14:16, Benoit Claise wrote: On 01/10/2014 18:27, Markus Stenberg wrote: Notably, adoption of a solution (discovery+negotiation protocol) before adoption of use cases seems like putting cart before the horse. Valid point. Regards, Benoit 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 19:26, Lorenzo Colitti wrote: On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter brian.e.carpen...@gmail.com 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. 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. Really? Which ways? That was the point of draft-jiang-auto-addr-management which was briefly presented at the UCAN BOF. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 21:20, Markus Stenberg wrote: On 1.10.2014, at 22.44, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 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. 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. 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. 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. 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. 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. 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. 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. 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 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. If a resource needs a hierarchy you would contstruct that on top of the negotiation protocol, not as an intrinsic feature of the protocol. 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? 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. 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
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Markus, On 02/10/2014 05:27, Markus Stenberg wrote: On 1.10.2014, at 16.20, Benoit Claise bcla...@cisco.com wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 02/10/2014 13:26, Mark Townsley wrote: On Oct 1, 2014, at 9:44 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 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. If we were having this discussion 5 years ago, I would agree. 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. 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. 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
