Re: [homenet] [Anima] Homenet feedback on the ANIMA charter

[Brian E Carpenter <[e-mail]>]

On 08/10/2014 03:23, Mark Townsley wrote:
>> On Oct 2, 2014, at 9:18 PM, Brian E Carpenter <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
>