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 protected]> 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@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 > [email protected] > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users -- http://mitar.tnode.com/ https://twitter.com/mitar_m _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
