On 25.2.2015, at 1.10, Juliusz Chroboczek <[email protected]> wrote: >>> 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.)
That sounds like distance vector <> link state tradeoff (and yes, we know HNCP isn’t a routing protocol but it both exists due to politics, and isn’t one due to politics; good luck shoving IS-IS on top of *TLS, or sticking in dozen+ random TLVs there). Suggestions on how to address that are welcome of course. (Forward case is tricky; client isn’t problematic, see below.) > 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. Yep, intentionally so for now; of course, we could turn it even more in the scalable (routing) protocol direction if there is desire. In another draft for a different WG I have specified auto-area extension for it already :p > 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. That shouldn’t be hard to address if it seems desirable, but doing (robust) (stateless) forwarding that way is problematic. Willingness to drop one lets you get the other, but not both I think For the ‘pure client’ (and especially ‘limited client’) case, I would argue that they are not interested in most of the state in HNCP in any case and would want just some sort of request-reply of current state, and possibly notifications about state changes from their first-hop non-client node. As an alternative, some flag to say that ‘I do not want to be your neighbor’ would allow read-only client usage of HNCP state using normal RNS+RNDxN messages, but I think nodes would be more interested in per-TLV state that is applicable, and not retrieving whole network state just to get e.g. assigned addresses. Cheers, -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
