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

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 5 Feb 2016 16:42:36 -0500

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

---

From: [email-masked]
Date: Fri, 12 Feb 2016 14:44:12 -0000

Thank you for sending your comments, I have tried to make changes that
incorporate comments from the various area reviews, and expect to shortly
release an ID revision (12) that has these improvements. Details of the
points addressed are below.

Gorry

---

Summary:

Major Issues:

No major issues found.

Minor Issues:

-GF: Understood, but I want to consult on the most suitable reference.

-GF: Numbered.

Page 11: In my opinion, the second and third requirements on this page
should be "MUST"s rather than "SHOULD"s.
-GF: Changed: A Circuit Breaker MUST be constructed so that it does not
trigger under light or intermittent congestion.
-GF: I did not change: “The default response to a trigger SHOULD disable
all traffic that contributed to congestion.” - I query if it really
important to dictate the “default” MUST?

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.
-GF: Added: “This fate-sharing property is weaker when some or all of the
measured traffic is sent using a path that differs from the path taken by
the control traffic (e.g., where traffic follows a different path de to
use of equal-cost multipath routing, traffic engineering, or tunnels for
specific types of 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.
-GF: I had contemplated this move, and have no preference. In the new
revision I moved the text to section 3.

1 and 2”.
-GF: done.

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.
- GF: Rephrased a little, although the present protocol assumption is that
UDP-based traffic needs to provide some form of congestion response, the
reality is that this is not always the case.

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.
-GF: done within the normative section, where the term is used a lot.

-GF: done.

Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes
one space to the right.
-GF: Thanks for spotting, done.

-GF: done.

-GF: done.

-GF: done.

-GF: done.

-GF: done.

-GF: done.

Regards,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 12 Feb 2016 11:03:02 -0500

Gorry,

> points addressed are below.

I’m glad to help. I noticed one new typo in your response, which may only
be in your email, but may be in the new text as well.

> specific types of traffic). ”

Change “path de to” to “path due to”.

Cheers,
Andy