[RTG-DIR] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt

"Andrew G. Malis" <agmalis@gmail.com> Fri, 05 February 2016 21:43 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF51B2D50; Fri, 5 Feb 2016 13:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLK3Vay5Rcdc; Fri, 5 Feb 2016 13:43:00 -0800 (PST)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54E01A885E; Fri, 5 Feb 2016 13:42:56 -0800 (PST)
Received: by mail-oi0-x232.google.com with SMTP id s2so49937165oie.2; Fri, 05 Feb 2016 13:42:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=aMb8ckDXEWWczoDSXVkL6J+t8iyymPrj5nm17v3aerI=; b=HpdKf7CQy6AxwIz5hBZI7/X8fR3oZhbZitvDPwBlnu64XatcNtiNoYg06NW5b4HUWw WSRBaJNuKyaaGjFD2XEWd3cQtxUr/TmAJJ84Sj8M7SWeO8hEqMchwJyXSSp+OkgLQ8k0 CYG1uNOHwemVh36pZJwLSpGw7KVRH+zNxuKHcIywx+udXpJjRSVxXzM4pThi7rW14zqn wwfliZetzj/uB4/QQCGnxeUDLOtj4wVotJW2SApkCzKlGHdoPMq0NgGZ96uAUgCs6GSL oh3fw4y4Wid32YxerTjVXwuCfBHYcWlA2dmIFhvBQCTr/BKA1vZ3BQe4+RN7FdsDAI37 qHNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=aMb8ckDXEWWczoDSXVkL6J+t8iyymPrj5nm17v3aerI=; b=HNsUPrlkqcESmE615ioL9gHyqzbR0h2TROeRD1KVUqlL8fYgdow+12Tna4SNGpaI2H Z+1tGhhsS2FUveaSytYjKKGONDryP3aIq9ICXgWGSd7jqsp+xylX6OgZ2HV8EbErYHd3 uQer3GEWusAENiSYdLZrgm6hWQ6Rgd9bEh6AE9lBYCWPqDu9+7c+ARVzO9MoxeJPe90T PUVC2y/CAFlMhZiNYLUMvhsdSo6k+m3BIVwuCGufwlD8nmf9MoMx6FuwmBm19azuS7iF SNcpH9eLewhYEUCiZpzQg67pnDsAdL0Imt9kFY9JEmMw31DCiY035wO9fvG0muHmQ/J1 lAQQ==
X-Gm-Message-State: AG10YOQdLPbbgmwD7qb59uyKG7mu2ISvJIAwHeZ8vBbT01Z81YpG58Sf4QAhVMZ4waRssUs9jJZJ1a1MlIqKvA==
X-Received: by 10.202.241.214 with SMTP id p205mr10411285oih.126.1454708576320; Fri, 05 Feb 2016 13:42:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.196.104 with HTTP; Fri, 5 Feb 2016 13:42:36 -0800 (PST)
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Fri, 05 Feb 2016 16:42:36 -0500
Message-ID: <CAA=duU2EqQTt7Uw=bNAvt2TP3jU4-Kt0e5n4q5-cmHfphwi3eA@mail.gmail.com>
To: IETF Discussion <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c094b58f18145052b0cbb70"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/FpiRhwAeLrUUmhiJiCzeL_lEE7o>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, tsvwg@ietf.org, IESG <iesg@ietf.org>, draft-ietf-tsvwg-circuit-breaker.all@ietf.org
Subject: [RTG-DIR] RtgDir review: draft-ietf-tsvwg-circuit-breaker-11.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 21:43:02 -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 IESG. For more information about the Routing Directorate, please see ​
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

It would be helpful if you could consider these comments 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-tsvwg-circuit-breaker-11.txt
Reviewer: Andy Malis
Review Date: February 5, 2016
IETF LC End Date: February 9, 2016
Intended Status: Best Current Practice

Summary:

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

Major Issues:

No major issues found.

Minor Issues:

Page 3, first paragraph: There are no citations to the claim that
non-congestion-controlled traffic "can form a significant proportion of the
total traffic traversing a link". Sure, video is a major part of Internet
traffic these days, but much Internet video is dynamically adaptive. One or
more citations would be useful.

Section 4: There are so many issues that they should be numbered, so that
they can be referred to individually (from another document, for example).

Page 11: In my opinion, the second and third requirements on this page
should be "MUST"s rather than "SHOULD"s.

Page 12, discussion of "In-Band" near the bottom of the page: This
paragraph implies that an in-band control method will always provide
fate-sharing of the control and regular traffic. It may provide
fate-sharing, but that is by no means assured. For example, the network may
be using ECMP, or traffic tunnels for data but not control traffic.

Section 5: I'm not sure why Section 5 is a separate section, and not
integrated into Section 3 as new subsections, which I think would be an
improvement.

Page 13, first paragraph: "presented in figure 2" -> "presented in figures
1 and 2".

Page 19, fourth paragraph: This paragraph states that "IP-based traffic is
generally assumed to be congestion-controlled". This is true for TCP-based
traffic, but I would not make such an assumption for all IP-based traffic.

Nits:

The abbreviation "CB" is defined early in the document, but is hardly if
ever used thereafter, rather "Circuit Breaker" is almost always spelled
out. It may be useful to actually use the abbreviation.

Page 3, first paragraph, fifth line, "connection" -> "connections".

Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes
one space to the right.

Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a
CB MAY combine".

Page 11, fifth paragraph: "needs to be" -> "MUST"

Page 12, second paragraph: There are two separate references to Section 8.
One combined reference should be sufficient.

Page 12, second to last paragraph: "in-Band" should have the "i"
capitalized.

Page 15, last paragraph: "tranport" -> "transport"

Page 17, fifth paragraph: "Pseudo Wire" -> "PW"

Regards,
Andy