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
