Subject: [homenet] actual requirements for standardization of an ietf protocol?

From: Dave Taht <[email-masked]>
Date: Tue, 24 Mar 2015 17:58:19 -0700

I saw this message go by today:

http://www.ietf.org/mail-archive/web/homenet/current/msg05073.html

where the author stated:

"If there were a solid specification and second implementation of
babel, babel would win on the basis of functionality."

A) As for the first, babel is pretty fully documented in a
multiplicity of individual submissions and a pair of formal (to-me)
looking RFCs. Certainly could use more eyeballs! Does it really need a
dedicated working group?

B) As for the second part of that statement, there is a second
implementation in quagga, but it is indeed from the same people.

I have LONG believed in the need for two or more implementations from
a specification in order for it to be a good spec.

However:

0) Modern protocols are really hard to write down in english. Open C
code is generally more clear (at least to me!), as are accompanying
documents that can actually incorporate graphs and math. Plain text
does not cut it.  The IEEE does a bit better job in this regard than
the ietf, IMHO.

1) I don't know where the "2 separate implementation" concept is
embedded formally in the ietf structures for approval. So far as I
know that was an old requirement, long dropped. What rfcs mandate
this? Was it mandated for http 2/0, for example? Did that happen? Is
it mandated for RPL? Has anyone ever produced an interoperable version
of ospf or ISIS solely from the spec?

2) Given the ready availability of very open (MIT licensed source
code) I think doing independent code from scratch is a waste of time
and a waste of what few valuable resources exist for furthering better
routing protocols and routing/kernel software in general. (I would
certainly, ultimately, like a version of babel that could be poured
into gates and run with a much tighter update interval at 100GigE, but
I can leverage the C code for that also. I don´t think an in-kernel
version is needed, either.

Would a ns3 version of a given routing protocol meet the requirement
for a competing implementation?

Back in the days when we had to write stuff in assembly, or gates, I
tend to think that the two separate implementation requirement made
sense, but not in an age where source is so freely available.

3) In the upcoming babel 1.6 release, I hope to see support for atomic
route updates, (not present in any linux routing daemon I know of
besides olsrd - and I do hope that code gets into quagga bgp in
particular when it stablizes), support for openwrt procd init
replacement (reliable restarts in case of failure), autodetection of
IPV6_SUBTREES at runtime, and a few other features.

After babeld-1.6 released, I expect it to be quickly taken up by the
entire linux (debian/fedora) ecosystem, as well as bsd, as well as (if
it stabilizes soon enough) openwrt chaos calmer, it´s deriviates,
buildroot, and yocto.

Basic babeld already being available as a standard - and universally
identical - package in so many parts of the ecosystem is one of the
basic babeld´s advantages over quagga, which has a good dozen
competing forks with different behavior and interfaces, and a mess of
competing implementations and feature sets in isis, ospf, and bgp.

An analogy I would use to favor babel is much like the one that let
firefox take over from mozilla - that a small team, no committee,
strong maintainer, makes for better software.

in babeld 1.7:

A) I would hope to see the currently quagga-only
https://tools.ietf.org/html/rfc7298 authentication extensions pushed
into babel using a modern, safe, well debugged crypto toolkit like
nacl, if needed... and some ideas towards partially authenticated
routes explored.

B) Given the issues with configuring hnetd + dhcp + babel + firewall +
dnsmasq, I would like to
see all that gain a configuration bus much like dbus, kdbus, or ubus.

C) I personally hope to gain the time to finally come up with an RTT
based availability, capacity, utilization metric leveraging the unique
characteristics of fq_codel (which is the current de-facto queue type
for openwrt, and thus homenet, and more or less what is going into
make-wifi-fast). What I think I got here will distinguish - without
using BFD - between wifi, wireless, homeplug, ethernet, and other
forms of connectivity pretty cleanly, I hope, without explicit
configuration. But I am unwilling to promise that (been a goal of mine
for 18 years!), and certainly there are other things on my plate
taking priority. (the math will work out fine for other routing
protocols that want to take advantage of the same assumptions)

And after that (or during), I would like to see work towards getting
ECMP and multicast to work, speedups on solving for wider diameter
networks, ability to take advantage of more wireless statistics, etc.

All this is stuff building on what already exists, and exhausts what
few developers are available *already* on what little funding exists.

As I have long noted, it would be awesome to gain more developers
working on quagga, babeld, olsr, manet, rpl, etc to actually turn
dreams into reality, and make for a deeper awareness of how routing
protocols work in the next generation. Certainly the BGP architecture
of the internet is creaky and I would dearly appreciate more efforts
at QAing existing code against newer versions of the OS, and improving
the OS interfaces overall. Routing lookups in modern hardware are very
expensive in particular...

One last note: I am deeply concerned about the depth and scope of the
FIB table updates happening in the linux kernel in the past two (4.0,
4.1) releases. They are comprehensive and invasive, and speed up fib
lookups amazingly, but the testing has been lacking for those making
tons of routing updates (RCU has been introduced) via daemons that
will ultimately be consuming that dogfood.

truly spectacular gains - in FIB lookups a factor of 7! here:

https://netdev01.org/docs/duyck-fib-trie.pdf

Some controversy here:

http://lists.openwall.net/netdev/2015/03/11/136

and nobody, so far as I know, using any routing daemon, has been
comprehensively testing. I hope to start myself, but jeeze, folk, the
fate of the internet relies on BGP, and the one guy doing the work at
redhat is just using a couple VMs to write the code on...

So to return to the impetus for this overlong email.

... so as usual, I find it ironic and depressing that those at the
ietf wish to impose more coding work, when there are far too few
coders and nearly zero testers actually on the job of doing what they
can to implement what they have to keep holding the internet together
as it continues to grow.

... out of fear, I am doing my best to track those updates above and
contribute where I can. I sure hope those that rely on any routing
protocol working at scale are closely tracking the FIB work also.

I would be comforted to know of any, any person, any corporation,
besides me, that are doing so.

-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 01:42:19 +1300

> embedded formally in the ietf structures for approval.

It isn't, for Proposed Standard status, although historically the
Routing Area has been tougher than the rest of the IETF because of
reasonable concern that a faulty routing protocol can produce more
horrible failure modes than pretty much anything else.

http://tools.ietf.org/html/rfc4794 may clarify a bit.

For advancement to Internet Standard there is a requirement
for 2 implementations but that is not germane to the current
discussion. (http://tools.ietf.org/html/rfc6410)

Sigh. It's embarassing how baroque the IETF process documents
have become, but it would be a lot of uninspiring work to
clean them up. That's why I've been maintaining this page for
a few years now: http://www.ietf.org/about/process-docs.html
(And yes, I'm aware it's overdue for an update.)

  Brian

---

From: Alia Atlas <[email-masked]>
Date: Wed, 25 Mar 2015 11:58:09 -0400

In the Routing Area, it depends upon the WG as to whether 2 interoperable
implementations are required.   This is always the case in,  for example ,
IDR.  For a new routing protocol,  I think it would be appropriate to be
comfortable that others can implement it and it works well.

Regards,
Alia
On Mar 25, 2015 7:43 AM, "Brian E Carpenter" <[email-masked]>
wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Dave Taht <[email-masked]>
Date: Wed, 25 Mar 2015 09:07:31 -0700

> comfortable that others can implement it and it works well.

The yak we are shaving here, is whether two inter-operable implementations
leveraging the same mit-licensed source code base (as in the base babeld daemon
and the quagga implementation) are acceptable to this wg.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 25 Mar 2015 17:37:56 +0100

> leveraging the same mit-licensed source code base (as in the base babeld
> daemon and the quagga implementation) are acceptable to this wg.

Dave,

Alia is right -- there do not at the current time exist two independent
implementations of Babel.

We can argue about whether that is a reasonable requirement, but we cannot
argue about the above, which is a fact.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 08:13:56 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

> argue about the above, which is a fact.

But she also said, or rather logically implied, that if there was a
babel WG it could decide that two strictly independent implementations
were *not* required for Proposed Standard. Of course the AD and the IESG
would have to agree, but it is perfectly allowed by the current IETF rules.

BTW there is also no rule that WGs must hold meetings. Reaching rough consensus
on the WG list is necessary and sufficient under the rules. It's rare
but entirely possible.

    Brian