>> Link quality estimation is in the informative appendix A.2.2.
> This is more than a little bit problematic if we want router vendors to
> be able to produce useful implementations: they generally are not
> interested in doing research, and just ship whatever firmware their wifi
> chip vendor tells them to.
Yeah, it's the old issue of how to encourage vendors to ship quality
implementations. You probably have a lot of experience with that (I hear
you're a DHCP person, ahem).
One approach would be to pepper the spec with MUSTs, and complain loudly
when they are violated. If I were in a nasty mood, I'd call this
attempting to legislate implementation quality. (And if I were in
a really nasty mood, I'd ask how well that worked for OSPF in the 1990s.)
Perhaps I'm being naive, but with Babel I tried to take the opposite
approach: RFC 6126 tries to be very liberal, but we've been making freely
available a reasonably high-quality, liberally licensed implementation.
The expected result is that a lazy or cheap vendor will just take our
implementation and stick it on their hardware, while a smart vendor has
a lot of latitude to improve on our work. The first has happened (there
are at least some commercial vendors who run the reference implementation
while claiming that they use a proprietary routing protocol), while the
second hasn't (unless you count TMS as a vendor).
More precisely, here's the approach I've taken in RFC 6126 (credit to Joel
Halpern for helping me with that):
* if something is required to ensure the integrity of the network, it's
a MUST. In particular, bidirectional reachability detection, loop
avoidance and blackhole avoidance are MUSTs (although one could
conceive a protocol that interoperates with Babel without implementing
any of those).
* if something is needed for good performance, it's a mere SHOULD, so
that it is possible to build an RFC 1217 compliant version of Babel.
* if an algorithm is necessary, but could be implemented in different
ways, then the properties that the algorithm have are MUST in the body
of the document, and a suitable algorithm is described in an
informative appendix.
There's one place where no algorithm is described — it's hysteresis
(Section 3.6). At the time I was using a rather hackish solution, the
current algorithm was done last year.
A good example of the latter would be Section 3.5.2: it merely says that
the metric algebra (M, ⊕, ≤) MUST have the following property
c ⊕ m > m (strict left monotonicity)
and SHOULD have the following property:
if m ≤ m' then c ⊕ m ≤ c ⊕ m' (left distributivity or isotonicity)
An obvious implementation would be to use the bounded integers equipped
with saturating addition, as used in IS-IS or OSPF, and that is what
Appendix A recommends. However, an implementation is free to use
c ⊕ m = c + 256/(battery charge) + m
or even (widest path algorithm):
c ⊕ m = MAX(c, m + 1)
(Aside for the theoretically minded: the required axioms are different for
distance vector and for link state. Dijkstra builds paths from the
destination, so it needs the right-hand-side properties where BF needs the
left-hand-side properties. The impact of distributivity is not well
understood at the moment: in its absence, there is no "shortest path"
solution, analogously to what happens with interesting BGP policies.
There exists a proof that BF converges in the absence of distributivity
(due to a student of Tim Griffin, I forget his name), but it's rather
difficult. Surprisingly enough, Dijkstra appears to converge even in the
absence of distributivity, but it leads to a set of trees that are not
necessarily consistent with next-hop forwarding. End of aside.)
(Aside for the practically minded: the metric used by EIGRP violates
distributivity. At the time, some in the community believed that this
indicated that EIGRP was broken; we now understand better why EIGRP works
as well as it does.)
Ted, I do understand where you're coming from when you say that the
latitude left to implementers worries you, but I really think that the
flexibility of Babel is one of its more appealing properties, and that
providing a high-quality implementation under a liberal license is
a better way to encourage vendors to do the right thing. If I'm being
naive, please don't hesitate to educate me.
— Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
