>> (1) it is impossible to reliably snoop the protocol without contributing
>> a Node-State TLV and a full set of Neighbor sub-TLVs;
> This is not true, at least assuming the profile specifies even partially
> multicast-using profile. In pure unicast setup, you have to poll,
> I guess. (HNCP isn’t doing this, as it uses multicast also.)
Ah -- you mean that an HNCP node will reply to a Node/Network state
request even if it's not in the link state database of the requestee?
That makes sense, much more than the assumption I had made that you ignore
any nodes that you don't have in your link-state database.
Please make this explicit in Section 5.2.
>> (2) it is impossible to publish data within DNCP without contributing
>> a full set of Neighbor sub-TLVs;
>
> Full set is not required. _One_ bidirectional one per link is enough.
How do you ensure that the graph remains connected? Suppose you have this
topology:
--- A --+-- B
|
C
where B and C try to minimise state. What prevents B from picking C,
C from picking B, so that the (B,C) clique becomes disconnected from the
rest of the network?
>> (3) it is impossible to act as a dumb DNCP forwarder without publishing
>> a Node-State TLV and a full set of Neighbor sub-TLVs.
> This is not true. Given basic bridging of ‘remember one guy on end of
> each link’, you can do essentially bridging.
Same issue as above.
>> This will require changing the algorithm in Section 5.4 (since the
>> neighbor graph is no longer necessarily connected).
> That will result in state hanging around forever unless we introduce
> some TTL scheme alongside it. Considering the main design goal of DNCP
> is _not_ to have TTLs in the protocol,
Ah. Right. I'm an idiot.
Please make this rationale more explicit in the draft -- it's said in the
introduction, please repeat it in Section 5.4.
I'll think about it some more, but I think you've convinced me -- I don't
see a good way to avoid the state explosion without giving up on the
link-state nature of DNCP. (Which I understand is not likely to happen.)
-- Juliusz
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
