>> This sounds _way_ too specific to me.
> If you are just going to laugh,
Laugh with us, Ted -- it /is/ rather funny.
(I especially liked the "linear sum" touch. What's a non-linear sum?)
> This statement should be inclusive of whatever routing protocols the
> working group is inclined to consider,
I'll do my best. There are at least four issues at hand.
1. Not all routing protocols choose the lowest-metric route -- some
protocols include in their route selection criteria data that are not
encoded in the metric. Examples are BGP flap avoidance, or the
hysteresis algorithm used by Babel. One might argue that this is also
the case of multi-area OSPF (although it is not usually expressed in
that manner).
For BGP and OSPF, you probably know more about the subject than I do.
For Babel, see Section 3.6 of RFC 6126 and Section III.E of
http://arxiv.org/pdf/1403.3488
(As far as I know, there is currently no theoretical understanding of
this kind of techniques. As far as I've been able to work out, neither
Sobrinho's routing algebras nor Griffin's semigroups are able to account
for them.)
The Arch document MUST NOT specify what kind of data the route
selection algorithm is allowed to take as input.
2. Many protocols don't compute metrics as a "linear sum" of the link
costs; as a matter of fact, in many protocols the metric is not a mere
integer, but an element of a richer algebra. This is obviously the
case of BGP (see Griffin and Sobrinho, SIGCOMM 2005), but also of
Babel, which, when run over a radio link layer with interference
avoidance enabled, carries a pair of an integer and (roughly speaking)
a set of interfering radio frequencies.
The Arch document MUST NOT specify the structure of the metric algebra.
It SHOULD NOT even imply that the metric being used is modelisable as
a routing algebra.
3. Finding a satisfactory and implementable metric for radio link layers
is very much an open research problem. Many routing protocols just
punt and expect the link layer to work like an Ethernet, which gets you
horrible performance in rich layer 3 topologies. Some mesh routing
protocols estimate unicast link rate and multicast packet loss and
combine the two using magic, which tends to choose unusable routes in
some cases. There has been a lot of noise around cross-layer
techniques for the last 10 years or so, but I don't know of
a production-quality implementation. (Yeah, I know, I should stop
complaining and try my hand at it.)
Please do not underestimate the importance of this point for Homenet --
how many wired and how many wireless links do you expect there to be in
a typical home ten years from now?
The Arch document MUST NOT specify what kind of data the metric
computation algorithm is allowed to take as input.
4. There exist routing protocols that don't use the notion of a metric at
all. We metric-based people like to jestingly call them "longest-path
routing" algorithms, however we're still keeping an eye open to see if
anything useful comes out from that line of research.
The Arch document SHOULD NOT even imply that a metric is being used.
Hope this helps,
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
