Subject: [tsvwg] Response to the detailed review: draft-ietf-tsvwg-circuit-breaker-05

From: [email-masked]
Date: Sat, 17 Oct 2015 12:32:23 +0100

Sorry I've taken so long to reply.

> Review by Bob Briscoe: 8th Oct 2015
> Gorry,
>
> Despite being past the WG stage, here's my review anyway. Consider this
> as early response to IETF last-call.
>
> In general I support the intent of this draft, but I am concerned at the
> severity of the problems I have found with it given it is meant to be
> about to go to the IESG. I am particularly concerned that I have found
> numerous significant problems with the normative requirements section.
>
> Have you had a substantial review from anyone before this? The level of
> review comments on the tsvwg list seemed quite light - picking on issues
> of particular concern, but not seeming to review the draft as a whole.
>

I did see some reviews (and have had comments off-list - including from
other WGs),
but I also REALLY do appreciate this careful read of the whole.

See my comments on comments below (a few notes from DB as document
shepherd are also included).

I'm guilty of reaching the deadline, and therefore have submitted these
changes in a new draft (06), some of these points may benefit from further
discussion if the new update did not address the issues.

Gorry

--------

> *1. Intro: **
> *Congestion Collapse is a very specific case - CB is much more general.
> it is clear from the draft that a CB is intended to mitigate
> circumstances wider than solely the extreme case of congestion collapse.
> For instance: a large unresponsive aggregate contributing to a high
> level of congestion alongside congestion responsive traffic. This is
> nowhere near congestion collapse, but it would be an applicable case for
> a circuit-breaker. Congestion collapse is a specific well-defined
> process that involves a cascade of congestion as a sequence of queues
> fill in turn moving in the upstream direction. It is due to continual
> retries or additional load arriving faster than existing flows are
> departing. {Note 1}
>
GF: I see and I can do this, and will rephrase in the next version,
to avoid using this term.
----
> The introduction mentions that TCP-style cc is only an appropriate
> remedy when long flows dominate. The implication that CB could be used
> to deal with congestion induced by many short flows is a step too far,
> IMO. This problem has not even been discussed in the IETF or IRTF to my
> knowledge, let alone in the context of this draft. In 6.2 this draft
> all-but says that a CB is a solution to this problem. I strongly object
> to a BCP making that assertion. CB would be a very drastic and clumsy
> solution to that problem.{Note 2}
>
> It says that the timescale at which a circuit-breaker operates must be
> seconds or tens of seconds - much longer than the RTT timescale on which
> TCP, SCTP and DCCP react. This disregards an important type of
> application response to congestion; it must say that the timescale also
> has to be longer than the timescale on which certain real-time
> applications operate their own circuit-breakers i.e. adapt down their
> codec rates, and eventually close the connection as a form of
> self-admission control. Applications operate per-flow circuit-breakers
> typically over the order of seconds or tens of seconds, so network CBs
> MUST take longer than that - I would say "no less than a minute".
>
> We MUST not discourage voluntary self-regulation by overriding it
> (end-to-end principle). I pick up this point later (comments on section
> 51.), arguing that the fast-trip CB for RTP should be considered as an
> application CB, and a network CB should always take longer to trigger
> than these app CBs.
>
GF: I think want to encourage applications to do this, starting by
ensuring that they have the opportunity to do so, added some text on this.
I revised the upper bound to clarify this, please see if this helps.

GF: I added some more text on the coexistence of fast and other circuit
breakers, which may help (within the fast circuit breakers section) - but
did not create a new section dedicated to this. If this is desirable we
could create a section (electrical circuit breakers have different
"curves" for trigger in a similar way to what is described ... but that's
just a side observation).

GF-XXX: If these comments still apply on the new text, it is worth
discussing further.
---
> *1.1 Types of CB**
> **
> *I saw criticism on the list of the use of the term "protect" in this
> section. Why hasn't it been changed? As the posting said, a CB does not
> protect the aggregate that it monitors; rather it /regulates/ the
> aggregate to protect the rest of the traffic that it is /not/ monitoring.
>
GF: Totally agree, although guilty of not changing the wording as promised
-   (people have the same problem describing Electrical circuit breakers)
and sorry thatI inadvertently repeated this many times.  I have rephrased
throughout.
---
> *3.1 Functional Components.**
> *
> There is no mention of the problem of synchronising the ingress and
> egress measurements to allow for transit time. Given you are trying to
> measure loss, which is a relatively small difference between the traffic
> entering and leaving, you can get very bad errors if you don't take path
> delay into account. draft-ietf-tsvwg-tunnel-congestion-feedback
> describes a nice (and commonly used) stateless way of doing that, by
> sending the ingress measurement in-band to the egress, which triggers
> the egress measurement so they are synchronized; allowing for transit
> time. Then the egress can send them both back to the ingress to be
> compared and acted on.
>
GF:I'd hope that measurements over longer periods would not result in
inaccuracies high enough to lead to trigger, but added a note to the text.
GF: I'm not sure the tunnel method is a CB, it seems more like a
congestion control method, which is perhaps why it that case the
synchronisation is required.
----
> *4. Reqs**
> *
>
>        There MUST be a control path from the ingress meter and the egress
>        meter to the point of measurement.  The Circuit Breaker MUST
>        trigger if this control path fails.
>
> Either this is unclear terminology, or I strongly disagree. What do you
> mean by a control path? We should only recommend that the CB triggers
> due to lack of measurement signals if the measurement signals are
> carried in-band with the data being monitored. That is only one way of
> arranging the mechanism. The term control path, sounds like it is out of
> band.
GF: I fell into the trap of a multiply-defined term.  This needs resolved.
I think we should say "communication path used for control messages", and
edit accordingly to avoid this misunderstanding.

> If the measurement signals are out of band, the CB MUST NOT
> trigger due to lack of measurement signals. I would recommend the
> in-band method, but there are plenty of network designers who will want
> to do this in centralised out of band ways, so we have to cater for that
> way of thinking (even tho it's misguided).
>
DB: I think Bob's request for not triggering the CB if a separate control
path fails is reasonable - that may need to be NOC/operator-mediated.
GF-XXX: I'm not sure I agree with "MUST NOT", so this needs more thought -
comments welcome on this point.
----
>        The measurement period MUST be longer than the time that current
>        Congestion Control algorithms need to reduce their rate following
>        detection of congestion.
>
> This needs to be rewritten. Or just removed. It seems like ideas changed
> after it was written, and the end was changed but not the normative
> statement at the beginning. IMO, the measurement period can be
> arbitrarily short, as long as multiple measurements are combined before
> triggering the CB.
> It talks about unnecessarily penalizing long RTT
> flows, but the measurement period is nothing to do with the period
> before there is any penalization (defined later as the triggering
> interval). There is no problem with short measurement periods as long as
> any high congestion measured in these periods is averaged over all the
> measurement periods in the triggering interval.
>
DB: There seem to be two meanings of "measurement period" here.  I've
always viewed it as the period of time over which measurements are taken
that result in triggering the CB, whereas Bob seems to view it as the
period of time over which an individual measurement is taken.  I have no
problem with the line of Bob's text quoted above, and think some
clarification to make it clear that the means of measurement is
unspecified (e.g., taking short measurements and combining them is fine),
but the period of time that applies to the metric that is used to trigger
the CB has to be sufficiently long.

GF: My understanding was the "measurement period" are the samples that
feed the trigger, so if the ingress or egress meter samples more
frequently, these would be combined. I added text to clarify this.
> In fact, there should be many measurement intervals per trigger
> interval, so that there are many opportunities for measurement messages
> to get through. Otherwise if there are only one or two measurement
> periods per trigger interval, the possibility of a false trigger due to
> lost control signals becomes too great.
>
GF: This is the robustness issue.
>     o  A Circuit Breaker is REQUIRED to define a threshold to determine
>        whether the measured congestion is considered excessive.
>
>     o  A Circuit Breaker is REQUIRED to define the triggering interval,
>
> A perfectly good CB could vary the trigger interval and threshold
> depending on how rapidly congestion is rising, or how high its absolute
> level is. Indeed one could say it is actually wrong to define a single
> threshold or a single interval, so these normative statements are overly
> restrictive and preclude designs that are smarter than just simple fixed
> threshold.
>
GF: There are many ways to do this, and individual specs can indeed react
using more sophisticated algorithms. At some point these will become more
like CC than an envelop CB.
DB: A metric and threshold for that metric are needed.  A rate-of-increase
metric or one based in part on that would be fine.
----
> Also, see comment above about allowing time for application CBs, and
> suggesting one minute minumum.
>
> o  A Circuit Breaker SHOULD be constructed so that it does not
>        trigger under light or intermittent congestion, with a default
>        response to a trigger that disables all traffic that contributed
>        to congestion.
>
> The second half after the comma seems misplaced. If it does not trigger,
> why does the sentence go on to talk about disabling all traffic that
> contributed to congestion (which is what an /enabled/ trigger would do)?
>
GF: Split the second part as a separate clause.
> A reaction that results in a reduction SHOULD result in
>        reducing the traffic by at least a factor of ten,
>
> What evidence have you got for this 10% number? It seems utterly
> inappropriate to write a number here. The number depends on what
> proportion of the traffic on the path between ingress and egress is
> regulated by the CB. If the proportion is low, it needs to reduce by a
> lot to make sufficient space for other traffic. If the proportion is
> high relative to other traffic, it might be sufficient to reduce by 5%
> to 95% of the previous load. If the tunnel traffic represented say 80%
> of the load on the path, and it reduced by a factor of 10, that would
> leave 92% of the path for other traffic, which might be unnecessarily
> much greater than the normal proportion used by other traffic.
>
DB: Need to say something here - we can fall back to "order of magnitude"
or something like that, but this'll need list discussion.
GF: Text updated. This point was previously discussed, but I am happy to
receive more feedback, rather than relying on what was said before. As I
recall, many were happy with terminating flows once a CB triggered, but
this was an attempt to be "kinder" and allow more flexibility - which I
personally liked - but still the default reaction to successive triggers
needs to be harsh. (It is a "SHOULD" though).
-----
>        Manual operator
>        intervention will usually be required to restore a flow.
>
> This sentence should be toned down to possibly, not usually. A human is
> no more capable than a machine is of bringing together all the necessary
> measurements to decide what other courses of action might be possible,
> and when to release the brakes. I suggest the last para of 5.3.1 starting:
>
> "An operator-based response provides opportunity..."
>
> is more appropriate here, and doesn't really fit where it is.
>
DB:  Operator intervention may be required to restore a flow.
GF: Changed as above.
----
> Section 4.1 contains no requirements text, only examples. It ought to be
> moved from the normative requirements section to section 5 (Examples).
>
GF: Resolved as a section on topologies.
----
> *5. Examples:**
> *
> *5.1.1 Fast-Trip CB for RTP**
> *
> The draft needs to make the distinction between an application doing its
> own circuit breaking vs. functions on the path between the application
> endpoints (even if in the hosts) doing CB. The extremely important
> distinction is:
> 1a) an app knows when congestion is too high for it to work properly
> 1b) functions under the app can only infer congestion is possibly too
> high for most apps to work properly
> 2a) an app may be able to reduce the rate at which it sends data
> 2b) a function under an app can only discard data, not remove it at
> source.
>
GF: Although this is not the place to delve into details, I added a prefix:
"Applications ought to use a full-featured transport (TCP, SCTP, DCCP),
and if not, application (e.g. those using UDP and its UDP-Lite variant
[RFC3828])they need to provide appropriate congestion avoidance. [RFC2309]
discusses the dangers of congestion-unresponsive flows and states that
"all UDP-based streaming applications should incorporate effective
congestion avoidance mechanisms". Guidance for applications that do not
use congestion-controlled transports is provided in [RFC5405.bis]. Such
mechanisms can be designed to react on much shorter timescales than a
circuit breaker, that only observes a traffic envelope. These methods can
also interact with an application to more effectively control its sending
rate."
GF: Also updated some other parts of the section.
----
> I believe that the requirements in section 4 do not apply to
> application-controlled circuit-breakers. So, I would not include the
> "Fast-Trip CB for RTP" as an example of a /network/ transport CB.
>
> As the requirements say, a network CB should never fast trip.
GF: But by design a RTP-CB should also not terminate flows.

> By misclassifying RTP CBs as network CBs, you've allowed the timescale
> for network CBs to trigger after tens of seconds. When a network CB
> should allow app CBs this long to trigger themselves (as I said earlier).

GF: I'm not sure, since understanding the difference between the two is
indeed important. Apps that "trigger themselves" describes what the
fast-trip CB does (in the absence of CC).
-----
>
> *Missing examples:**
> *
> * You might want to point to the flow termination function (as opposed
> to admission control) in the PCN architecture [RFC5559], which is
> precisely a network CB. It was precisely developed for cases where
> failures caused traffic to reroute onto a previously well-provisioned
> path (see 6.1).

DB: I think that's a stretch.  This is not among the types listed in 1.1. 
It might be mentioned as a related concept that is outside the scope of
this draft.
GF: How different to rsvp and other admission-controlled schemes? - I
think we're drifting away here... I did change in the new rev. Unless
there is strong support from the WG, I'd rather not add these examples.
------
> * Andrew McGregor gave the examples of Google's BwE (bandwidth enforcer)
> and B4, but you haven't referred to them. Given they are documented
> existence proof of this beast, that seems remiss.
>
GF: I believe I discussed with Andrew and we didn't at the time have good
text to add. This may well have changed, if there are good references
please send them for consideration.
------
> *7. Security Consid's**
> **
> *
>
>     The circuit breaker MUST be designed to be robust to packet loss that
>     can also be experienced during congestion/overload.
>
> This implies reliable transmission - i.e. retransmit for ever until
> acknowledged. This is NOT a good idea. In
> ietf-tsvwg-tunnel-congestion-feedback we propose using SCTP partially
> reliable transport. Then if congestion causes messages to be lost, they
> don't have to be retransmitted if there are insufficient resources (thus
> not risking contributing to congestion collapse - and here I use the
> phrase correctly). Because they transmit counters, the missing counters
> values do not matter. This is the tried-and-tested message delivery
> approach used for IPFIX. The messages can still be given priority, but
> should not be retransmitted.
>
GF: I disagree this is a requirement for reliably transmitting packets.
I'd be happy to add text to explain robustness does not imply reliability
and that this is likely to be an evil thing to do.
GF: Added text on duplicating messages.
-------
>     Simple protection can be provided by using a
>     randomized source port, or equivalent field in the packet header
>     (such as the RTP SSRC value and the RTP sequence number) expected not
>     to be known to an off-path attacker.
>
> I think the draft should recommend that for most scenarios, randomized
> ports will be insufficient protection for CB control messages, which
> should be properly crytographically authenticated. Otherwise, a
> CB-controlled aggregate is too vulnerable to these off-path attacks.
>
GF-XXX: I don't know why you state that a random port (or protocol field)
is insufficient protection from off-path attack, please explain.  Are you
saying a CB is more vulnerable to attack than other transport traffic. I
don't see the problem yet, can you suggest what you would like to see
added?
--------
> *Gap #1:**
> ***The draft seems to think it is so obvious what a CB should measure
> that it only says it vaguely as "the level of congestion", and only
> suggests the difference between ingress and egress counters as an
> example. Some readers might well think like this: Does congestion level
> mean the percentage extra bit-rate relative to the aggregate's expected
> or maximum bit-rate? That might actually be a correct measure of
> congestion in some scenarios, but...
>
> The draft does not say that the congestion level is defined as dropped
> bytes divided by ingress bytes. The draft should spell out that a CB
> should measure the volume of bytes dropped and the volume of ECN-capable
> bytes marked with CE, and express these as a fraction of resp. total
> ingress non-ECT bytes and total ingress ECT bytes (assuming buffers
> within the scope of the CB are ECN-enabled). Even this is problematic,
> because the assumption in parentheses never holds, particularly during
> excessive congestion. It could also discuss the relative merit of
> measuring the percentage of packets dropped/marked instead of bytes.
>
GF:  A detailed discussion of how to measure congestion is out of scope
here, IMHO.
-----
> Also it should mention that care should be taken over how to combine the
> measurements. For instance avoid the common mistake of averaging
> fractions, because ave(c1/t1, c2/t2, c3/t3 ...) != (c1 + c2 + c3)/(t1 +
> t2 + t3).
>
GF: Added some text - is this sufficient, given there is no intention to
specify the algorithm here:
"If necessary, MAY combine successive individual meter samples from the
ingress and egresss to ensure observation of an average over a
sufficiently long interval. (Note when meter samples need to be combined,
the combination needs to reflect the sum of the  individual sample counts
divided by the total time/volume over which the samples were measured.
Individual samples over different intervals can not be directly combined
to generate an average value.)"
--------
> *Gap #2:**
> ***All the diags show multiple routers, but the text says congestion can
> be measured by comparing ingress and egress traffic. Nowhere does it say
> that only traffic with addressing that will have for-certain only passed
> through both ends should be measured.
>
GF: True, I think everyone who previously looked at this thought that
section 3.1 described. I agree though that it needs to be stated, and will
add text.
--------
> {Note 1}: A few years ago I dug deep into the history surrounding the
> early congestion collapses on the Internet and found that those involved
> were adamant that the term congestion collapse should not be waved
> around for dramatic effect, because it has a very specific definition,
> as paraphrased above.
>
GF: I cited an RFC on congestion collapse and did not use the words
thereafter.
--------
> {Note 2}: The credit feature of ConEx was intended to address short-flow
> overload if it becomes a problem. DOn't get me wrong; I'm not objecting
> to the use of CBs for the short-flow problem because I want you to use
> my solution. I'm just using this as an example of a fine-grained way to
> solve the problem, rather than the sledge-hammer CB way.
> Here's the intuition briefly: With ConEx, you have to attach 'congestion
> credit' to the first packets of a flow to cover the risk of congestion
> before you have feedback (and if you don't and there is congestion, your
> packets are dropped by an audit function). Then congestion policers at
> the network ingress can limit the amount of congestion credit consumed
> without needing feedback, and thin out traffic if it consists of large
> numbers of short flows. If short flows come to predominate, ConEx credit
> was also designed to incentivize a new form of proxy that could regulate
> short-flows with a push-back style of congestion control, without a full
> feedback loop. That would be far preferable to such a drastic measure as
> a circuit-breaker. This aspect of ConEx was not written into the IETF
> docs, but it is mentioned in the re-ECN drafts that were the ancestors
> of ConEx.
>
GF: I do agree ConEx can manage traffic. I'm confident that a
ConEx-controlled flow would not need an additional circuit breaker
mechanism - but I see this as a congestion control mechanism though - not
a circuit-breaker.
---
> *Nits**
> *
> 3.
> s/last resort protection to the network paths that these are used./
>   /last resort protection to the traffic sharing their network path./
>
GF: Good you spotted this, changed to: " to provide last resort protection
for traffic that shares the network path being used."
> s/tunnels encapsulations/
>   /tunnel encapsulations/
GF: Fixed in latest version

---
> 3. What makes a good CB?
>
>     Circuit Breakers are RECOMMENDED for IETF protocols and tunnels that
>     carry non-congestion-controlled Internet flows and for traffic
>     aggregates, e.g., traffic sent using a network tunnel.
>
> Delete "
>
> e.g., traffic sent using a network tunnel
>
> "
> Reason: this implies all network tunnels are problematic, whereas the
> rest of the sentence adequately says that only tunnels carrying
> non-congestion controlled flows are of concern.
>
GF: Understood, suggest remove from this sentence, and instead place in a
separate sentence that follows this saying,
"This includes traffic sent using a network tunnel. "
-----
> 4.
>
> s/monitor the level congestion/
>   /monitor the level of congestion
GF: Fixed in latest version
> 4.1.1
> (e.g. to implement a Section 5.1)
> ?
GF: Fixed tag in latest version
> 4.1.2
> s/pre-prosvisioned/
>   /pre-provisioned/
GF: Was fixed in -06
> 6.1
>
>     One common question is whether a Circuit Breaker is needed when a
>     tunnel is deployed in a private network with pre-provisioned
>     capacity?
> Remove '?' from the end.
>
GF: Fixed in latest version

> 6.2
>
> s/in the event that persistent congestion occur./
>   /in the event that persistent congestion occurs./
>
GF: Fixed in latest version
> Regards
> Bob
Gorry

---

From: "Black, David" <[email-masked]>
Date: Sat, 17 Oct 2015 18:16:04 +0000

<WG Chair Hat OFF>

> comments welcome on this point.

On further thought, I think the proposed "MUST NOT" errs by going too far
to the other end of the spectrum.  I think "SHOULD NOT trigger due to lack
of measurement signals" is appropriate when the measurement communication
path is out of band, and I'd state a rationale for the "SHOULD NOT" that
it avoids failure amplification/propagation when the measurement and data
paths can fail independently.

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Saturday, October 17, 2015 7:32 AM
> To: Bob Briscoe; [email-masked]
> Cc: [email-masked]
> Subject: [tsvwg] Response to the detailed review: draft-ietf-tsvwg-circuit-
> breaker-05
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 17 Oct 2015 21:48:43 -0500

My hat's off here for now.

> paths can fail independently.

I'm reading

- Bob's comment as saying "operators MUST continue to run traffic that
needs a circuit breaker without a circuit breaker if the control path stops
working",

- DB:'s first thought as saying "we're leaving it up to operators to figure
out if they're fine with running traffic that needs a circuit
breaker without a circuit breaker without a circuit breaker, if the control
path stops working", and

- Dave's further thought as saying "operators SHOULD continue to run
traffic that needs a circuit breaker if the control path stops working". Am
I misunderstanding?

And, yes, fate sharing is your friend, and we're talking about what to do
when someone has decided that fate sharing isn't your friend ...

Spencer

---

From: [email-masked]
Date: Sun, 18 Oct 2015 13:58:04 +0100

Please comment...

So, I’m not sure whether I’m capturing the comments correctly, but would
certainly like to address the issue of control messages correctly.

I’m thinking this may best be done by adding two additional requirements
relating to the control communication - putting more in the security
considerations seems to me to be the wrong place. I’ve written this below
as an addition to draft  -06, but would really  appreciate comments,
because there is new normative text here (together with existing text from
the sec considerations section - nearly all the first bullet):

"* A Circuit Breaker requires control communication between endpoints
and/or network devices. The source and integrity of control information
(measurements and triggers) MUST be protected from off-path attacks (<xref
target="sec">. The circuit breaker MUST be designed to be robust to packet
loss that can also be experienced during congestion/overload. This does
not imply that it is desirable to provide reliable delivery (e.g., over
TCP), since this can incur additional delay in responding to congestion.
Appropriate mechanisms could be to duplicate control messages to provide
increased robustness to loss, or/and to regard a lack of control traffic
as an indication that excessive congestion may be being experienced <xref
target="ID-ietf-tsvwg-RFC5405.bis">.

* The control communication may be in-band or out-of-band. Inband
communication is RECOMMENDED when either design would be possible. If this
traffic is sent over a shared path, it is RECOMMENDED that this control
traffic is prioritized to reduce the probability of loss under congestion.
Control traffic also needs to be considered when provisioning a network
that uses a circuit breaker.

In-Band: An in-band control method SHOULD assume that loss of control
messages is an indication of potential congestion on the path, and
repeated loss ought to cause the Circuit Breaker to be triggered. This
design has the advantage that it provides fate-sharing of the traffic
flow(s) and the control communications.

Out-of-Band: An out-of-band control method SHOULD NOT trigger Circuit
Breaker reaction when there is loss of control messages (e.g., a loss of
measurements). This avoids failure amplification/propagation when the
measurement and data paths fail independently. A failure of an out-of-band
communication path SHOULD be regarded as an abnormal network event. As
such, this event SHOULD be logged."

----

>> > GF-XXX: I'm not sure I agree with "MUST NOT", so this needs more
>> thought
>> -

---

From: "Black, David" <[email-masked]>
Date: Mon, 19 Oct 2015 14:52:04 +0000

New text looks very good - expanding on this was the "right thing to do"
(IMHO).  I have one small suggestion for the end of the proposed new text:

> A failure of an out-of-band

I'd suggest:

... abnormal network event and be handled as appropriate for the network, 
e.g., this event SHOULD be logged, and additional network operator action
might be appropriate, depending on the network and the traffic involved.

I'd that this text will receive further editorial attention as the draft
progresses.

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, October 18, 2015 8:58 AM
> To: Spencer Dawkins at IETF
> Cc: Black, David; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Response to the detailed review: draft-ietf-tsvwg-
> circuit-breaker-05
> 
> Please comment...
> 
> So, I'm not sure whether I'm capturing the comments correctly, but would
> I'm thinking this may best be done by adding two additional requirements
> considerations seems to me to be the wrong place. I've written this below

---

From: [email-masked]
Date: Mon, 19 Oct 2015 16:33:08 +0100

OK - I added this to my version being edited. I'll now wait to see if
further comments emerge from others.

Gorry

>> >> > > in-band method, but there are plenty of network designers who
>> will
>> >> want
>> >> > > to do this in centralised out of band ways, so we have to cater
>> for
>> >> that
>> > traffic that needs a circuit breaker if the control path stops
>> working".
>> > Am
>> > I misunderstanding?
>> >

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Oct 2015 11:47:17 -0500

Given that I have to put this on a telechat agenda at some point ...

> > might be appropriate, depending on the network and the traffic involved.

Other words would also work, but that sounds about right to me. I wasn't
comfortable saying "if the out of band control channel breaks, please press
on, because what could go wrong?". This is closer to saying "you are now
flying without a parachute, and that might be OK for a short time, but
sooner or later you'll remember why you needed a parachute in the first
place" ...

> > I'd that this text will receive further editorial attention as the draft

I am, of course, still listening with an open mind :-)

Spencer