Margaret and all, I have started conversations about the possibility of having an IETF WG where Babel or a similar protocol could be started. Alvaro, Deborah and I are thinking of it as potentially a Distance Vector IGP working group. It isn't yet clear whether there is (a) a community to do the work or (b) a clear scope and applicability to which a protocol would need to conform.
I expect that we may have a mailing list to encourage focused discussion soon. Regards, Alia On Tue, Mar 31, 2015 at 4:37 PM, Margaret Wasserman <[email protected]> wrote: > > I like to think that the IETF standards process has considerable value, > and that the specifications that we produce as standards-track RFCs are > higher-quality, not just in document quality but in the technical quality > of the protocols, than the documents that enter the process. > > In the case of Babel, there are two things I think we should consider that > would definitely come up as part of the IETF standards process: > > 1) A mandatory-to-implement security mechanism. The current draft says > that security can be accomplished by using a lower-layer security solution, > like IPsec. It doesn't specify one, and (perhaps more importantly) doesn't > specify how the Babel session would be bound to a lower-layer security > mechanism. A lower layer mechanism can't really be used to secure a > higher-layer protocol, unless the identifiers used in the higher-layer > protocol are properly bound to the identifiers used in the lower-layer > security mechanism. > > 2) Congestion avoidance. I am not sure how Babel would behave in the > presence of congestion, nor am I sure that it wouldn't cause congestion in > the presence of route flapping. I have looked through the spec, and I > don't see any mechanism to rate-limit Babel messages, or to do any sort of > back-off in the presence of congestion. I'd be interested to know if this > has been considered? Are there mechanisms in the implementation to avoid > these problems? > > These are two of the things that I look for in protocols -- there are > different things that other people look for, and I think it would be > valuable to examine Babel from all of those different perspectives. > > I think there are other parts of the protocol that could be improved in > various ways, although I am not sure that everyone would agree with me. I > think it would be both fun and fruitful to have those discussion, though. > If Juliusz would be willing to surrender change control of the protocol to > an IETF WG, I would like to see an IETF WG formed to standardize Babel, > whether or not the Homenet WG chooses to adopt it. I don't see why the > formation of that group couldn't start now, in parallel with the design > team assessment. If there are folks who would like to get together to > propose a charter for that group, I would be happy to cooperate in that > effort. > > Margaret > > On Mar 31, 2015, at 3:40 PM, Brian E Carpenter < > [email protected]> wrote: > > > On 01/04/2015 05:02, Joel M. Halpern wrote: > >> Actually Ray, IETF process, as described by the IESG, happily allows > for Downref with suitable approval and notice to the > >> community. So, as far as I can tell, homenet could indeed reference > and mandate Babel in a Proposed Standard RFC. I would > >> agree that homenet choosing to do that would be a strong impetus for > moving the document to Standards track. But that does not > >> have to be gating. > > > > It doesn't. But otoh we'd like the protocol to meet the standards track > criteria > > in reality, not so much on paper (which is why the downref mechanism > exists, > > so that reality trumps bureaucracy). I actually like Dave Taht's point: > > running code trumps theoretical extensibility. > > > > So yes, I think the design team should be chartered to focus on technical > > reality and to set aside bureaucratic requirements. > > > > (But, since the interop that occurred last week - great to see that - > > did apparently show up some minor issues, revving the Babel document > > may be a good thing to do in any case.) > > > > Brian > > > >> > >> https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry > >> > >> Yours, > >> Joel > >> > >> On 3/31/15 11:54 AM, Ray Bellis wrote: > >>> > >>>> 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 > >>> > >> > >> _______________________________________________ > >> 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 >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
