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 <[email protected]> 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 <[email protected]> > Date: Thursday, June 12, 2014 at 7:34 AM > To: Ted Lemon <[email protected]> > Cc: "[email protected] Group" <[email protected]> > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
