Re: [babel] Suresh Krishnan's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Dear Suresh,

> I did have one major concern that I would like to see addressed
> though. This is in regard to backward compatibility with RFC6126
> implementations. Due to the addition of the mandatory bit and the
> processing associated with it, I would think that the new
> implementations will not be able to properly interoperate with the
> existing RFC6126 implementations. Is my understanding correct?

Short version:

  - a 6126bis implementation that does not send either mandatory sub-TLVs
    or Unicast Hellos fully interoperates with 6126.
  - an implementation of 6126 can be made compatible with 6126bis with the
    addition of 20 lines of code (ignore Unicast Hellos and TLVs with
    mandatory sub-TLVs).

Long version:

The WG discussed this issue at length, both at face-to-face meetings and
over the ML.  We had three possibilities:

  (1) remain 100% backwards-compatible;
  (2) add *optional* features that break compatibility;
  (3) make a new, incompatible version of the protocol.

Solution (3) was considered as being the death of Babel.  Solution (1) was
rejected after we realised how much mandatory sub-TLVs simplify the
protocol encoding.

Thus, we came up with the following transition plan:

  - make the incompatible features optional, and don't send them by default;
  - teach all the implementations in the wild to silently ignore the new
    features;
  - wait one year;
  - start sending the new features by default.

> If so, I would like to see some text explaining what is the expected behavior
> when deploying into legacy environments

[...]

> I think a consolidated change log from RFC6126 would be more helpful in the
> finished RFC for existing implementers.

I'll seriously consider it.

-- Juliusz