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
On 08/10/2014 03:23, Mark Townsley wrote: >> On Oct 2, 2014, at 9:18 PM, Brian E Carpenter >> 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
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On 08/10/2014 06:51, Michael Richardson wrote: > Mark Townsley 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
Mark Townsley 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 , 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 Oct 2, 2014, at 9:18 PM, Brian E Carpenter > 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 > > >>> 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 distribute
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
> On Oct 7, 2014, at 2:44 PM, Michael Richardson 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 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 , 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
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 wrote: > >> On Thu, Oct 2, 2014 at 12:16 PM, Brian E Carpenter >> 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
On 02/10/2014 21:20, Markus Stenberg wrote: > On 1.10.2014, at 22.44, Brian E Carpenter 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 explai
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
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 1.10.2014, at 22.44, Brian E Carpenter 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/listi
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 > 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
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
On Oct 1, 2014, at 9:44 PM, Brian E Carpenter 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. 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 ___ 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 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 > > == > So should we say in the charter that the scope is everything but the > initial focus is enterprise and carrier? > > On 10/1/2014 3:44 PM, Brian E Carpenter wrote: >> Markus, >> >> On 02/10/2014 05:27, Markus Stenberg wrote: >>> On 1.10.2014, at 16.20, Benoit Claise >>> 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
Re: [homenet] [Anima] Homenet feedback on the ANIMA charter
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? On 10/1/2014 3:44 PM, Brian E Carpenter wrote: Markus, On 02/10/2014 05:27, Markus Stenberg wrote: On 1.10.2014, at 16.20, Benoit Claise 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 poi
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 > 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
