Speaking with people at this week's IETF meeting, I've realised that some are confused about why configuration and routing are implemented by different protocols in Homenet. Contrary to what might seem, this is not some sort of weird political compromise, but a conscious technical decision.
Routing and configuration have very different dynamics -- configuration is much more static. If a link becomes lossy, the prefix it is assigned by the configuration protocol does not change, but its routing metric must increase and be propagated across the metric. If a router crashes, it doesn't harm if the prefixes it assigned to its interfaces remain marked as used for a few minutes; the routing protocol, on the other hand, must be able to reroute within a fraction of a second. On the other hand, the configuration protocol must be able to carry a fairly large amount of data (on the order of 1kB per node in the current implementation of HNCP), while the routing protocol does not -- it only carries a single metric per address, or, in the case of link state, a single metric per interface. Because of that, it is best to implement routing and configuration in different protocols, each of which is carefully designed for its intended usage. What is more, it avoids the need to include large amounts of non-routing code in a routing daemon, something that the routing people, who have spent years fine-tuning their implementation, are not likely to take in a friendly manner (and, IMHO, rightly so). Please let me know if you're still unconvinced. I love arguing. Regards, -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
