[Babel-users] Possible changes to the Babel protocol

[Mitar]

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
<jch at pps.univ-paris-diderot.fr> wrote:
> 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 at 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
>
> _______________________________________________
> Babel-users mailing list
> Babel-users at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



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