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
