On 08/10/2014 03:23, Mark Townsley wrote:
>> On Oct 2, 2014, at 9:18 PM, Brian E Carpenter <[email protected]>
>> 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
>>>>> 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)
>> Exactly. And that is pretty close to Turing-complete so it
>> could be used very generally.
>>
>>> 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?
>> Yes. I noticed that when considering Rene's comment about state
>> synchronization and it needs more work. Nobody is saying that
>> it is fully baked yet.
>>
>>> 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.
>> It's intentionally peer-to-peer so network-wide requires propagation;
>> but I don't understand how HNCP could do some of the other things we
>> want. There will be a revised requirements in a forthcoming draft, so
>> I'd rather have that discussion later.
>>
>> Let me be clear: if HNCP can be generalised to do what we need (which
>> would probably mean changing its name slightly) I'd be delighted.
>> There is absolutely nothing to be gained by having two protocols if
>> one will work.
>>
>> Brian
>>
>> _______________________________________________
>> Anima mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/anima
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
