I've reordered your comments. > I would say each proposed extension needs a pretty clear use case, > a specification, and then an implementation report (if available), and > possibly some form of deployment experience draft (if available).
That's not the way we work, here at Babel Towers. We don't usually develop an extension without an actual feature request from our users, and we never freeze the protocol until we have both working code and deployment experience. We're very serious about that. > A protocol version? It would be simpler to have some sort of capabilities > negotiation here, possibly. That's not how Babel works. A Babel router simply ignores any routes it doesn't grok. In other words, capability negotiation happens at route granularity, not at neighbour relationship granularity. > Note that choosing a route across two metrics is, as I understand it, > unsolvable. This is the reason EIGRP uses the K values to merge the > metrics A given router must use a single metric (at least in the absence of TOS-specific routing and similar), granted, but distinct routers may use different metrics. This is analogous to routing policies in BGP. > Note also there needs to be some way to prevent oscillation between the > control plane and the data plane when you start playing with delay, > bandwidth utilization, etc., in the real world. These are nasty > problems. Absolutely. We have worked really hard on stability, this is described in detail in Baptiste Jonglez, Matthieu Boutier (PPS), Juliusz Chroboczek. A delay-based routing metric. Unpublished draft. 2014. http://arxiv.org/pdf/1403.3488 -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
