Subject: [RTG-DIR] RtgDir review: draft-ietf-babel-applicability-06

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 3 Jul 2019 13:08:29 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-babel-applicability-06
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 03-Jul-19
IETF LC End Date: 04-Jul-19
Intended Status: Informational

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

I have reviewed the -01 version of the draft two and a half years ago. Since then the document has undergone massive changes, so that I feel that I have been reviewing a new document.
One thing that remained unchanged, however, was the readiness of the author to cooperate with the review.  I would like to express my deep gratitude to Juliusz for that.

The document is very well written and matches my understanding of what an applicability statement draft for a routing protocol should be. It is not only easy but also interesting to read (at least for me).

Most of the issues I am raising in this review are in the gray area between “minor” and “nit”. My classification in this review is, therefore, arbitrary to some extent, and should be taken with a grain of salt.
And at least some of these issues reflect my personal curiosity.

Major Issues: None found

Minor Issues:

1.       The text in Section 2.3 says: “in order to check the interoperability of two implementations of Babel, it is enough to verify that the interaction of the two does not violate the protocol's assumptions.”

a.       This looked just wrong to me – two implementations may preserve all the protocol assumptions but fail in the interoperability test, e.g., because encoding of some parameter in one of the PDUs is different

b.       The author has confirmed that this was actually a typo, and has agreed to remove this text

c.       This is one of the cases where  it is difficult to say whether this is a minor issue or a nit

2.       The explanation of the BABEL base assumptions in Section 2.2. is very useful. However, it assumes that the reader has at least some intuitive understanding of the “routing algebra” notations.

a.       Discussed this point with the author

b.       We have agreed that there is no need to make this document a detailed tutorial on the subject, nor to indulge in ASCII art (that would be indicative at best in any case)

c.       Some short explanation, possibly augmented with Informative references to the relevant research papers, would be sufficient IMHO

3.       The draft mentions 4 independent implementations of BABEL in Section 2.1, but does not say anything about their interoperability. Such information, if available, should be very useful for the readers. (If no such information is available as of this moment, I would accept this)

4.       The comparison between BABEL and IS-IS/OSPF in Section 2.4.1 lacks information about possibility of fast local protection mechanisms (a.k.a. IP FRR, see, e.g., RFC 5286)

a.       Discussed this point with the author since from my POV such information could be valuable for the readers that consider deploying BABEL in their networks

b.       Unfortunately,  the author could not provide an immediate answer one way or another

5.       Last but not least, a few words about manageability of BABEL would be useful IMHO.

Nits:

1.       I did not run the nits check on the draft

2.       I think that the work “argue”  in the text in Section 1 “we argue that there exist niches where Babel is useful and that are not adequately served by more  mature protocols” is by far too weak (or too modest?). From my POV the draft goes far beyond arguing.

a.       Discussed this point with the author

b.       The author agrees to change this text to be more definitive,

Hopefully these notes will be useful.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jul 2019 16:31:34 +0200

Dear Sasha,

Thank you very much for your review, which has helped me improve the document.

> 1.       The text in Section 2.3 says: “in order to check the interoperability
> of two implementations of Babel, it is enough to verify that the interaction of
> the two does not violate the protocol's assumptions.”

This has been fixed.

> 2.       The explanation of the BABEL base assumptions in Section 2.2. is very
> useful. However, it assumes that the reader has at least some intuitive
> understanding of the “routing algebra” notations.

This has been expanded with human-readable comments, and I've added a reference
to my favourite paper on the subject (Griffin and Sobrinho, "Metarouting").

> 3.       The draft mentions 4 independent implementations of BABEL in Section
> 2.1, but does not say anything about their interoperability. Such information,
> if available, should be very useful for the readers. (If no such information is
> available as of this moment, I would accept this)

I have simply added the word "interoperable" to the sentence, which
reflects what the authors of the implementations have reported to me.

> 4.       The comparison between BABEL and IS-IS/OSPF in Section 2.4.1 lacks
> information about possibility of fast local protection mechanisms (a.k.a. IP
> FRR, see, e.g., RFC 5286)

This is an interesting question, and I need to go educate myself on the
subject.  I didn't add anything on this subject.

> 1.       I did not run the nits check on the draft

I have.

> 2.       I think that the work “argue”  in the text in Section 1 “we argue that
> there exist niches where Babel is useful and that are not adequately served by
> more  mature protocols” is by far too weak (or too modest?). From my POV the
> draft goes far beyond arguing.

We now *describe* a few niches that are *arguably* not adequately served.

Thanks again,

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jul 2019 16:48:34 +0200

I forgot one of your points.

> 5.       Last but not least, a few words about manageability of BABEL would be

People are working hard on monitoring and manageability:

  - Barbara Stark and Mahesh Jethanandani are working on manageability
    within the IETF framework;
  - Nexedi are working on dynamic reconfiguration of interfaces by an
    external cross-layer (2->3) monitoring agent;
  - a number of people are working on monitoring, both by a human operator
    and by an external software agent:

        https://github.com/kerneis/babelweb
        https://github.com/Vivena/babelweb2
        https://github.com/tcatm/mmfd

However, none of this work is finished yet, and, given the wide range of
application domains of Babel, I do not feel comfortable to give any
definite advice about management.  I have therefore decided not to say
anything in this document.

-- Juliusz

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 7 Jul 2019 14:52:08 +0000

Dear Juliusz,
Lots of thanks for addressing my review comments so quickly.

I have looked up the -07 version and it addresses my review comments to the maximum possible extent.
In particular, I accept the fact that my question about fast local protection with BABEL cannot be answered without additional investigation: such investigation is clearly not part of the applicability draft.
And I also accept the fact that management aspects of BABEL are still work in progress.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Juliusz Chroboczek <[email-masked]> 
Sent: Sunday, July 7, 2019 5:49 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: RtgDir review: draft-ietf-babel-applicability-06

However, none of this work is finished yet, and, given the wide range of application domains of Babel, I do not feel comfortable to give any definite advice about management.  I have therefore decided not to say anything in this document.

-- Juliusz