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 <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
>
>
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
