> On 31 Mar 2015, at 16:35, Dave Taht <[email protected]> wrote: > > I don't see any point in starting up a new working group[1] whatsoever > based on the events of the last ietf homenet meeting, particularly > with the arrival of a new written from-spec version of babel in under > 15 hours, (which I am still chortling about. I am tempted to write one > in rust).
Whilst full standardisation of Babel may end up happening in a WG anyway, some of this design team's job will be to establish whether it's more expedient to bring Babel up to "proposed standard" levels of specification than to add Homenet-related features (per your list below) to existing IETF endorsed standards. > It is just punting the question and more delay when stuff that is more > than sufficiently stable is done, already, and shipping, with a 5 year > long productization pipeline left to fill. For better or worse, IETF process dictates that we cannot use what is officially an _experimental_ protocol in a standards track document. Markus' work was very impressive, but not sufficient to overcome that hurdle. However this _should_ be a very short-lived punt - less than one IETF cycle. The WG was unable to reach consensus over three full IETF cycles, and this structured design team approach _should_ clear this log jam. > (If it helps any (which I doubt) I have never thought that homenet > must settle on one routing protocol, and certainly the from the ISP > part of the link is underspecified) > > At least one routing protocol must be available, however to turn back > the tide of the current situation where none are commonly available in > most consumer routing gear. More than one IS available. We are arguing on the choice of one _mandatory to implement_ protocol. For interoperability's sake, this will be the one that "must be available". Nothing can (nor will) prevent additional protocols from being implemented, and perhaps even operate simultaneously. > Aside from that my major two requirements have only been > > 0) Must support source specific routing > 1) A homenet capable routing protocol MUST work well over wifi and > wireless links in addition to conventional ethernet and other mac > layers > > My minor requirements were: > > 0) Binary and memory sizes must be small enough to fit into teeny routers > 1) should be wildly available in every off the shelf OS that might be > used for routing > 2) should be extensively tested in environments ranging from homes, to > battlemesh, to small business campus networks > 3) Should have a good spec, must have at least one open sourced and > liberally licensed implementation These requirements are all very well understood. > So to me, y'all are wasting time that could be better spent into A) > pouring resources into making hnetd less the monster than it became, please elaborate (in a separate thread, please!) > B) dogfooding what exists and C) developing better tests and D) > developing better metrics > > PS However. > > [1] I would not mind a working group that took the outputs of the > battlemesh folk (babel, olsr-ETX, batman, bmx) and stacked them up > against the outputs of the ietf working groups (like RPL, olsrv2, and > others from manet and elsewhere) - and the IEEE (like all the layer 2 > isis stuff) and that wg BOTH tackled them in the working group AND in > the real world - and worked to sort out the mess of academic code and > real world requirements in the hope, that one day, maybe before I die > of old age and/or apoplexy, the one true routing protocol and metrics > emerged from the chaos. If enough people backed that and a suitable charter was agreed that could happen. kind regards, Ray _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
