Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-00.txt

From: [email-masked]
Date: Sat, 27 Sep 2014 04:04:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Area Working Group Working Group of the IETF.

        Title           : Network Transport Circuit Breakers
        Author          : Godred Fairhurst
	Filename        : draft-ietf-tsvwg-circuit-breaker-00.txt
	Pages           : 13
	Date            : 2014-09-27

Abstract:
   This note explains what is meant by the term "network transport
   circuit breaker" (CB).  It describes the need for circuit breakers
   when using network tunnels, and other non-congestion controlled
   applications.  It also defines requirements for building a circuit
   breaker and the expected outcomes of using a circuit breaker within
   the Internet.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Mon, 29 Sep 2014 02:40:02 +0000

Gorry and co,

can a tunnel keepalive (e.g. the patented Cisco GRE tunnel keepalive mechanism) be considered part and parcel of circuit breaking? ie if congestion is such that keepalives are lost and the tunnel drops, the keepalive machine has, imperfectly and without much measurement, done the circuit breaker thing - by having its circuit broken. It's not robust to congestion events, though.

I think some discussion of keepalives and their limitations (and analogy with TCP's acks as keepalives) might be appropriate here. Necessary but not sufficient, or not necessary?

(nit section 5.2 - whether does not need a question mark.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: tsvwg <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Saturday, 27 September 2014 9:04:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-circuit-breaker-00.txt

Abstract:

---

From: [email-masked]
Date: Mon, 29 Sep 2014 09:23:46 +0100

I'd be keen to see text on keepalives, but the difficulty I have is
identifying what to write.

I see a basic keepalive, as tracking reachability (blackhole detection) -
that is whether the path supports packets. To me, (tell me more) I'd
expect it to provide help in identifying problems such as:
There is no route to the tunnel destination address.
The tunnel interface is down, or remote endpoint unavailable..
Other routing/recahability problems

As the ID is written that's not a circuit-breaker, it doesn't say much of
the ability of a path to support a certain workload, at best a simple
method sends a periodic probe (sampling infrequently).

If the keepalive packets were to carry OAM data on packets sent/received
(do they?) they could indeed be used to validate the path was not loosing
packets (or not significantly congested). Does that make sense? - do
people know of examples of this that could be useful to document in the
circuit breaker draft?

Gorry

> Gorry and co,
>
> can a tunnel keepalive (e.g. the patented Cisco GRE tunnel keepalive
> mechanism) be considered part and parcel of circuit breaking? ie if
> congestion is such that keepalives are lost and the tunnel drops, the
> keepalive machine has, imperfectly and without much measurement, done the
> circuit breaker thing - by having its circuit broken. It's not robust to
> congestion events, though.
>
> I think some discussion of keepalives and their limitations (and analogy
> with TCP's acks as keepalives) might be appropriate here. Necessary but
> not sufficient, or not necessary?
>