Re: [homenet] Updates to Homenet Architecture Principles doc

Thank you, Acee. 

The very first sentence of section 3.5 contains a very strong statement about using existing protocols. I don't see how expanding this section with detailed routing protocol requirements du jour helps to underscore that point. So, please, let's stop. 

- Mark

(Thumbtyped)

> On Jun 12, 2014, at 4:55 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:
> 
> 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 <jch@pps.univ-paris-diderot.fr>
> Date: Thursday, June 12, 2014 at 7:34 AM
> To: Ted Lemon <mellon@fugue.com>
> Cc: "homenet@ietf.org Group" <homenet@ietf.org>
> 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
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet