From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1209921F7F0; Tue, 11 Aug 2015 19:13:25 -0700 (PDT) Received: by oip136 with SMTP id 136so2000232oip.1; Tue, 11 Aug 2015 19:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=HkFyI7IkZjNfnfbjcj8Gn6qTNsh7TKS9sZuiBTIPky0=; b=CDtZ0lSXoCtHTlxLLfsfJZF3mwwQ9AoNPjmBna1P5p5GHeERq6cnYhPLjvTVtpb5v3 Zrz0HEFGmvuqDynNDQ1YBPzxCY7EvbpvHniPE6Muj2DLu+40GjFl/+0acKwoHJYMtSxu IxDasnMJhmQd7BVraqMA0Xd1Zh3HPKDW/vrSjqn8VsF1m1o8oSxMCrelxzcEJyC4AGUG olANcA6ygYWKAt52fJzNZqhH6fO7uMUyihuutcP3TSWnACwnjyU+RRIwQfAb6u6qE5FP SxT1FQ7quIaxZpfXWv7UA8Wbf9loaYSKU31XsQgMzTdwJ+r/P+KsWGHPZu1cfRkz6pHt Or1g== MIME-Version: 1.0 X-Received: by 10.202.129.70 with SMTP id c67mr27083022oid.42.1439345604684; Tue, 11 Aug 2015 19:13:24 -0700 (PDT) Received: by 10.202.108.12 with HTTP; Tue, 11 Aug 2015 19:13:24 -0700 (PDT) In-Reply-To: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> References: <87pp2t76wi.wl-jch@pps.univ-paris-diderot.fr> Date: Tue, 11 Aug 2015 19:13:24 -0700 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" , make-wifi-fast@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Make-wifi-fast] Fwd: [Babel-users] Babel to standard X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 02:13:54 -0000 new mailing list for discussion of moving babel to standards track in the ietf. If you care, please join. ---------- Forwarded message ---------- From: Juliusz Chroboczek Date: Tue, Aug 11, 2015 at 4:16 PM Subject: [Babel-users] Babel to standard To: babel@ietf.org Cc: babel-users@lists.alioth.debian.org The goal of this mail is to list what I think are the issues with the current experimental Babel specification, RFC 6126, that should be fixed before Babel can be standardised, as well as improvements that I think are not needed. I'll wait a few days to see if consensus emerges, then I'll write up the results. This mail is crossposted between the babel@ietf and babel-users mailing lists. I've directed replies to babel@ietf, to which you're encouraged to subscribe: https://www.ietf.org/mailman/listinfo/babel MUST be fixed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Incorrect port number --------------------- The RFC gives an incorrect port number. There is an erratum to RFC 6126 to this effect. Garbage collecting routes ------------------------- RFC 6126 doesn't say when a route entry is garbage collected. The answer is -- it doesn't matter, just don't do it too early, but this needs to be stated explicitly. More precisely, a route entry SHOULD be garbage collected some time after it is retracted and blackholed (as described in Section 3.5.5), a couple of minutes is enough. That is a SHOULD, since nothing bad will happen if you don't -- you'll just run out of memory at some point. (Do people think that this deserves an erratum?) Ignoring extra data ------------------- Section 4.3 is clear that extra data after the end of the contents of a TLV MUST be silently ignored. However, two respectable implementors (Denis and Markus) got that wrong, so this needs to be made more prominent. Editorial changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Merging extensions into the base spec ------------------------------------- Which, if any, of the currently defined extensions should be merged into the base spec? My opinion is that the extension mechanism should be merged, but that the actual extensions should remain separate documents. Describing the route selection algorithm ---------------------------------------- RFC 6126 states that designing a route selection algorithm for Babel is an open research problem. While this is still true, there should be an informative appendix that describes the trivial algorithm (just pick the route with the lowest metric) and the time-sensitive algorithm used since version 1.4.0 of babeld since it is simple and appears to work well in practice. Including suggested metric values --------------------------------- While suggested values for metrics on lossy links are described in Appendix A.2.2, no such values are described for lossless links (Appendix A.2.1). Changing "metric" to "primary metric" ------------------------------------- Babel is able to carry additional metrics in extension TLVs; the metric used in the Metric field is merely the "primary metric", the one that is used for loop avoidance and ensures interoperability between different extensions (which can always fall back to the primary metric). This should be made clear in the base spec, especially if the extension mechanism is merged. Deprecating wildcard requests ----------------------------- Wildcard requests are useful for debugging, but we now know that they SHOULD NOT be used in normal operation. Say that an implementation MUST limit the rate at which it honours such requests, and recommend that they SHOULD NOT be sent. Rethinking recommendations about seqno requests ----------------------------------------------- Loosen Section 3.8.2.1 -- the "SHOULD be multicast over all of the node's attached interfaces" is what the reference implementation does, but the spec should allow more parsimonious implementations. This is far from trivial to write. Incompatible protocol changes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D A Babel packet carries a protocol number, which it is possible to increase if the protocol needs to change in an incompatible version. I'd be opposed to doing that, since it would severely impact the installed base of Babel routers, and could cause a split in the community, as has unfortunately happened with the OLSR community. Using a wider primary metric ---------------------------- It has been suggested that the current 16 bits are not sufficient. However, an extended metric can be as wide as will fit in a sub-TLV (255 octets). The Babel-Z (diversity routing) metric, for example, has variable width. Unless you intend to put 65536 routers in a row, there is no need to extend the primary metric. Adding mandatory and transitive bits, as in BGP ----------------------------------------------- There is currently no way to mark a sub-TLV of an Update TLV as mandatory, as in BGP. This has forced us to design the source-specific extension as using a separate TLV, which is not very elegant. However, the source-specific extension would still have required new TLVs for requests. Mandatory and transitive bits would make it easier to design an extension that does BGP-style communities that are suitable for filtering, a feature that has been requested by both the Italian and Slovenian communities. I believe that the doubtful benefits that this provides do not justify an incompatible protocol change. Making source-specific routing part of the base spec ---------------------------------------------------- Source-specific routing uses its own set of TLVs, which are distinct from the base protocol's TLVs. Merging the two kinds of TLVs would yield a slightly cleaner protocol, but would require putting source-specific routing in the base spec. I like small specs. Removing prefix compression --------------------------- Joel dislikes prefix compression. I'm not sure I like it myself, but it yields a massive traffic reduction in typical IPv6 networks, and costs very little code. Security considerations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are at least four known ways to secure the Babel protocol: * lower-layer security (e.g. put a frightening guy or gal with a truncheon in front of each Ethernet plug, or use 802.1X); * HMAC authentication (RFC 7298); * Stenberg-style authentication (move everything to unicast except hellos, use DTLS); * use the replay protection from RFC 7298 together with statically keyed IPsec. There are different tradeoffs between these techniques (reuse of existing libraries vs. compact code, authentication only vs. privacy, etc.), so the current plan is to implement them all and let the community decide. I am therefore strongly opposed to putting any security mechanism in the base spec. _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast