Early Review of draft-ietf-babel-applicability-01
review-ietf-babel-applicability-01-rtgdir-early-vainshtein-2017-02-02-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-babel-applicability-01-rtgdir-early-vainshtein-2017-02-02

Hello,
I have been appointed as an early  (QA) RTG-DIR reviewer of draft-ietf-babel-applicability.

The review has been requested by one of the BABEL WG chairs. The purpose of an early review is to get an outside opinion on the work and to try to spot any major issues or objections early on in its lifecycle.

Document: draft-ietf-babel-applicability-01
Reviewer: Sasha Vainshtein
Review Date: 31-Jan-17
IETF LC End Date: N/A
Intended Status: Informational

Before going into the review proper, I would like to make a couple of introductory statements.


1.       From my POV this review falls somewhere in between the RtgDir QA review and the "full' RtgDir review. This explains deviations from the full RtgDir review template.

2.       I have looked up for suitable precedents to understand the expectations for a stand-alone Applicability Statement document since it was not clear to me what to expect.

a.       The draft under review is just 5 pages, which, from my POV, is clearly a blessing for an "outside" reviewer. So I have decided, rather arbitrarily, to exclude several very long Applicability Statement RFCs for routing and signaling protocols (e.g., RFC 7733<https://tools.ietf.org/html/rfc7733> - 38 pages, or RFC 6571<https://tools.ietf.org/html/rfc6571> - 35 pages) from my list of potential valid reference points.

b.      I have considered the following published documents as valid reference points for the purpose of this review:

                                                               i.      RFC 2081<https://www.rfc-editor.org/rfc/rfc2081.txt>

                                                             ii.      RFC 3037<https://tools.ietf.org/html/rfc3037>

                                                            iii.      RFC 3210<https://tools.ietf.org/html/rfc3037>

c.       I have noticed that these documents more or less follow a common scheme:

                                                               i.      A brief technical overview of the protocol (at some level or detail)

                                                             ii.      Objectives and actual results that can be achieved with the protocol

                                                            iii.      Specific limitations (e.g., scalability), possibly with information about the critical scale parameters

                                                           iv.      Security considerations

3.       I expected to see some level of compliance with the above-mentioned common scheme in the draft under review. At the same time I understand that my selection of reference points and the resulting conclusion about the common scheme are somewhat arbitrary and may be biased. Hence I ask to take the WG Chairs, the ADs and the RTG-DIR team to take the conclusions in my review with a grain of salt.

Summary:
I have some concerns about the document that can be summarized as "not enough information in the document to be published as an Informational RFC". From my POV, these concerns should be resolved before the document is progressed.
These concerns may be due to difference of expectations from the kind of document I has been assigned to review.

I have discussed my concerns in a private exchange with the author, but we have not resolved our differences at the time this review has been posted.

Comments:
The document is very short  and hence easy to read. It is divided into three main parts:

1.       Networks where use of BABEL has been successfully deployed

2.       Networks where use of BABEL is not recommended

3.       Security considerations



The IANA Considerations section is also present but it does not contain any information (as expected).


Issues:

The draft differs from the above-mentioned common scheme and does not provide sufficient level of detail. As a consequence, It does not meet my expectations for a stand-alone Applicability Statement document.

1.       The technical overview of the protocol in the draft is limited to a single sentence that includes a reference to the base BABEL spec - RFC 6126.

a.       I have found that Sections 1.1 "Features" and 1.2 "Limitations" of RFC 6126 contain quite a reasonable description of BABEL capabilities and weaknesses

b.      This would probably  suffice if we were dealing with an Applicability Statement as a separate section in the spec. But from my POV a separate Applicability document should be more or less self-contained

2.       The draft lists four classes of networks where BABEL has been successfully deployed:

a.       Medium-sized hybrid networks that combine "a wired, aggregated backbone with meshy wireless bits at the edges".

                                                               i.      Success of BABEL in these networks is attributed to its ability to "to deal with both classical, prefix-based ("Internet-style") routing and flat ("mesh-style") routing over non-transitive link technologies"

                                                             ii.      No specific parameters about the networks in this class are provided. From my POV "medium-sized" and "meshy bits" can mean very different things to different people

b.      Large overlay networks "built out of thousands of tunnels spanning continents" and "used with a metric computed from links' latencies".

                                                               i.      Success of BABEL in these networks is attributed to the ability of BABEL to "remain stable and efficient in the presence of  unstable metrics, even in the presence of a feedback loop"

                                                             ii.      No specific parameters (e.g., frequency and the range of metric changes) are provided

                                                            iii.      Wireless pure mesh networks. No explanation is given for the claimed BABEL ability "be competitive with dedicated    routing protocols for wireless mesh networks"

c.       Small unmanaged networks (three to five routers). BABEL is claimed to be a replacement for RIP in these networks

3.       By and of itself, reference to actual deployments could be a great advantage for an applicability document - if sufficient level of detail about these deployments is provided. While "sufficient level of detail' clearly is in the eye of the reader, from my POV:

a.       The only class of networks where, the level of detail provided in the draft is quite sufficient, are "small, unmanaged networks (three to five routers)"

b.      In the remaining cases the descriptions are somewhat vague. In particular, there is no information about:

                                                               i.      The number of nodes and links per node encountered in specific deployments

                                                             ii.      Specific information about non-transitive behavior of links in these deployments (e.g. the numbers of transitive vs. non-transitive links per node)

                                                            iii.      Frequency of changes in the metric and observed range of variations (where applicable) etc.

4.       I have raised these points in a personal exchange with the author.

a.       It seems that in some cases the information is publicly available (and so could be included in the draft

b.      In some other cases the operators who have deployed BABEL object to publication of any specific information about their networks.

5.       One more detail that IMHO is lacking is usage -or non-usage - of any extensions to the base BABEL spec in successful deployments and their impact (or lack thereof) on the success.  This kind of detail could be important - or not

6.       The part of the draft that discusses the scenarios in which use of BABEL is not recommended is more in line with the common scheme. However, I have noticed that:

a.       Section 1.2 of RFC 6126 explicitly mentions two potential weaknesses of BABEL:

                                                               i.      Periodic distribution of routing info.

                                                             ii.      Potential transient black-holing when an aggregated route is replaced by more specific ones

b.      Only the first of these issues is mentioned in the draft as the root cause preventing effective use of BABEL in specific networks

                                                               i.      This may be due to the fact that the second kind of problem has never been encountered in actual deployments - or not.

                                                             ii.      In any case, I would expect correlation between the limitations of BABEL as presented in the base spec and the impact of these limitations on actual deployments in the applicability document.

c.       I also think that non-applicability of BABEL as a routing protocol in "large, stable, well-administrated networks" is not only due to the fact that it uses periodic distribution of routing info - especially since the protocols recommended for this purpose (OSPF and IS-IS) also do that (due to aging of their Link State databases even if, presumably, with much longer periods)

7.       IMHO and FWIW, security concerns associated with BABEL, and the mechanisms for their mitigation  are  adequately presented in the draft.

I believe that the issues I've raised can be resolved to my satisfaction (at the price of making the draft somewhat longer to read) by providing:

-          A reasonably detailed technical overview of BABEL in the draft based on a similar overview in the base spec

-          Some level of detail about the networks where BABEL has been successfully deployed - where information is available and can be published without causing unnecessary conflicts

-          Information about actual impact of de-aggregation of routes on black-holing in existing BABEL deployments. If such impact has not been observed, a mere statement of the fact would suffice, of course.

NITS:

I did not check the draft for nits.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Monday, January 09, 2017 1:42 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: Jon Hudson (jon.hudson@gmail.com) <jon.hudson@gmail.com>; Yemin (Amy) <amy.yemin@huawei.com>; Donald Eastlake <d3e3e3@gmail.com>; 'Zhangxian (Xian)' <zhang.xian@huawei.com>
Subject: Routing area directorate early (QA) review of draft-ietf-babel-applicability

Hi Sasha

Happy new year to you!  I wonder if you would be able to do an early directorate review of this short draft?  The review has been requested by the babel chairs and is due by 31 Jan.
https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/?include_text=1

Just to remind you, the purpose of an early review is to get an outside opinion on the work and to try to spot any major issues or objections early on in its lifecycle.  Please send comments to the babel mailing list, rtg-dir mailing list and babel chairs.

You will hopefully have also received an email from our new review tracking system!

Please let me know if you can accept this assignment.

Best regards and all the best for 2017!
Jon