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
