Subject: [babel] Possible changes to the Babel protocol

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 21 May 2016 18:33:25 +0200

Dear all,

Since the creation of a WG is out of our hands right now, I'd like to
start a discussion about whether we want to make an incompatible revision.

I'm sending this mail to both lists, please follow-up to babel@ietf.
I suggest that people express their opinions as followups to this mail,
after the discussion has settled I'll summarise and make this into a wiki
page.

We can adopt one of three approaches.  One would be to make an entirely
compatible revision -- tighten the spec, make the extension mechanism
a MUST, etc.

We could make a revision that is technically incompatible, but retain
version number 2 and design it so that it is possible to implement both
RFC 6126 and IETF Babel at the same time.  This would allow us to make
some TLV types optional (deprecate them) or to mark them as reserved.

The third approach is to make a new, Babel revision 3, which preserves the
spirit of Babel to the extent possible but is not compatible with Babel.
Unless the semantics are too different, it should be possible to implement
both Babel 2 and 3 in a single process with loop avoidance across the two
protocols, but at the cost of doubling the amount of control traffic.

I hold no opinion at the present time which approach is preferable.  I'm
just listing the changes that we could envision.  Notes of the form
[jch:...] indicate my current opinion on each change.  Whenever possible,
the name of the person who originally suggested the change is indicated in
brackets.

* Incompatible changes

Expand the primary metric to 32 bits (Tony) [jch: don't care, we can
carry a 32-bit metric in an extension TLV, but expanding the primary
metric is simpler]

Expand the TLV size to 16 bits (Tony) [jch: opposed, 8 bits is plenty
since TLVs must fit within a worst-case MTU]

Expand the TLV/sub-TLV space to 16 bits [jch: opposed, there's already
a mechanism for expansion of the TLV/sub-TLV space in RFC 7557]

Add a mandatory bit to TLVs (Tony) [jch: unsure]

Add a mandatory bit to sub-TLVs (Tony) [jch: in favour, they would
simplify the source-specific encoding quite a bit]

Clean up the encoding (Joel, Markus) [jch: mildly in favour, but afraid of
bikeshedding]

* Semi-compatible changes

Remove AE 0 and wildcard requests/retractions/IHU (Toke) [jch: in favour,
wildcard requests and retractions are confusing and not useful, wildcard
IHU can be encoded in a more parsimonious manner]

Remove plain (non-seqno) requests (jch) [jch: in favour, they complicate
the protocol and are not very useful, can be added as an extension if
needed]

* Compatible changes

Reserve router-ids all-zero and all-ones (Toke).  [jch: in favour]

Change the treatment of unfeasible updates from the selected neighbour,
(Section 3.5.4 of RFC 6126, Ondrej) [jch: not sure]

Change the SHOULD send a request when receiving an unfeasible update to
MUST (Section 3.8.2.2, Tony) [jch: in favour]

Rework the algorithm for sending requests when starving (Section 3.8.2.1,
jch).  [jch: in favour, but requires some experimental work]

-- Juliusz

---

From: Mitar <[email-masked]>
Date: Sat, 28 May 2016 18:26:16 +0200

Hi!

I would be in favor of making an incompatible but improved version,
but against forking of current main codebase (and resources directed
in maintaining it). So in some way I would be that current main
codebase should also move to this new "major" version. I see it simply
from the open source project perspective as a new major (backwards
incompatible version). In addition, there should be a transition path
provided for networks with previous major version. For example, by
running both Babel versions in parallel (this might require using a
different port for a new version?).

Mitar

On Sat, May 21, 2016 at 6:33 PM, Juliusz Chroboczek
<[email-masked]> wrote:
> _______________________________________________
> Babel-users mailing list
> [email-masked]
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m