Re: [homenet] Updates to Homenet Architecture Principles doc

[Acee Lindem <[e-mail]>]

I was involved in this discussion and the statement was merely an attempt
to capture the fact that the existing unicast IGP routing protocols would
meet the homenet requirements with the addition of routing based on
source-address. For example, while BGP would not be precluded, BGP¹s rich
routing policy is not viewed as being required in the homenet.
Thanks,
Acee 

-----Original Message-----
From: Juliusz Chroboczek <[e-mail]>
Date: Thursday, June 12, 2014 at 7:34 AM
To: Ted Lemon <[e-mail]>
Cc: "[e-mail] Group" <[e-mail]>
Subject: Re: [homenet] Updates to Homenet Architecture Principles doc

>>> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/homenet