Subject: [tsvwg] TSVWG WGLC: draft-ietf-tsvwg-circuit-breaker-02

From: "Black, David" <[email-masked]>
Date: Mon, 17 Aug 2015 02:29:27 +0000

This email announces a TSVWG Working Group Last Call (WGLC) on:

	Network Transport Circuit Breakers
	draft-ietf-tsvwg-circuit-breaker-02 

Due to the timing (many people take time off during August), this WGLC will
run for longer than usual - it will be for just over 3 weeks, ending at
midnight US Eastern (daylight) Time on Tuesday, September 8 (this date &
time have been chosen to be after the US Labor Day holiday on Monday,
September 7).  Comments should be sent to the [email-masked] list,
although purely editorial comments may be sent directly to the author
(Gorry Fairhurst <[email-masked]>).

As part of this WGLC, comments are requested on the appropriate RFC status
for this draft - this circuit breaker draft has been written with BCP (Best
Current Practice) RFC status in mind, but another status (e.g., Proposed
Standard) may be appropriate.  Reviews and comments should assume BCP as
the intended status, although that may change as a result of the WGLC
(in consultation with our ADs).

As I mentioned in the Prague tsvwg meeting, there is an expired WG draft
(formerly in the pwe3 WG, now the responsibility of the pals WG) on congestion
considerations for TDM pseudowires (PWs) - that draft contains some discussion
of a managed circuit breaker for TDM PWs.  If that draft reappears before
the end of this tsvwg LC on the circuit breaker draft, that reappearance
will be taken as a tsvwg WGLC comment requesting changes/additions to
section 5.3.1 of the tsvwg circuit breaker draft, which currently discusses
another managed circuit breaker for SAToP PWs.

To set a good example, I have reviewed the draft (it's well-written, and a
relatively easy read) and have a few LC comments as a WG chair to start this
WGLC:

Section 3.1, end of 1st paragraph:

   A CB is used to control traffic
   passing through a subset of these routers, acting between an ingress
   and a egress point.  In some cases, the ingress and egress may be
   within one or both network endpoints, in other cases they will be
   within a network device.  For example, one expected use would be at
   the ingress and egress of a tunnel service.

Editorial: "tunnel service" -> "service"

Editorial: Figure 1 shows measure and trigger at ingress - they could
also be at ingress or in network operations/management infrastructure,
e.g., with trigger event communicated to ingress to take action.  The
text following Figure 1 looks ok, so this is a request for text to
indicate that Figure 1 is not fully general in this regard.

Technical: p.7:

   o  A CB MUST define a measurement period over which the receiver
      measures the level of congestion.

"congestion" -> "congestion or loss"  Congestion may not be directly
measurable in all cases, even when ECN is used, as ECN nodes may drop
packets, and packets can be dropped for non-congestive reasons.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------