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

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Thu, 08 Aug 2019 05:48:10 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-babel-rfc6126bis-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rfc6126bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this well written document. Most of the issues I found
have been covered in the ballot positions of my esteemed colleagues. 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?

If so, I would like to see some text explaining what is the expected behavior
when deploying into legacy environments. If not, I would greatly appreciate an
explanation and I will clear.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Appendix F

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Aug 2019 15:13:34 +0200

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.

> when deploying into legacy environments

[...]

> finished RFC for existing implementers.

I'll seriously consider it.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 17 Aug 2019 03:30:19 +0200

> I'll seriously consider it.

Done in -14.