>> Another question -- is it possible to participate in Trickle-driven >> flooding without building the full topology graph?
> The current answer based on strict reading of the spec is no. [...] > Is this desirable to be changed? Probably so. There's not only the stub case that you consider, but also the pure client/forwarder node -- a node that doesn't wish to publish any data, but uses static HNCP data, and serves as a link between two parts of the network. Ideally, such a node should not contribute any replicated state. (Note that a Babel/AHCP router that doesn't announce any routes contributes no state whatsoever to non-neighbouring nodes. So you can add arbitrary many intermediary hops with no cost incurred by distant nodes.) The reason I'm asking is somewhat out of scope for Homenet -- I'm looking into deprecating AHCP in mesh networks in favour of a subset implementation of HNCP. AHCP is a very simple protocol, and one can implement an AHCP client/forwarder in constant space. Not so with HNCP -- in HNCP, every node has a copy of the topology, and contributes a vertex to the replicated neighbour graph. HNCP is naive link state, with no network nodes (pseudonodes) and no DR/DIS/MPR election. So its scaling is quadratic in the worst case. Consider a network containing a switched Ethernet backbone consisting a mere 30 routers. Unless I'm missing something, this backbone will contribute no less than 30 vertices and 435 edges in the neighbour graph, and this state will be duplicated in every single node in the network. There's an obvious solution -- it is to have pure client nodes that participate in Trickle but don't contribute a vertex to the neighbour graph. But HNCP doesn't support that. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
