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 <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
--
email: rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
