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: Alexander.Vainshtein@ecitele.com ___________________________________________________________________________ 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. ___________________________________________________________________________