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

From: "Black, David" <[email-masked]>
Date: Sun, 13 Sep 2015 20:35:11 +0000

It looks like all the WGLC comments on this circuit-breaker draft have been
addressed in the -03 version.  There are a couple of items that could still
use some attention:

(1) The pseudowire congestion draft that contains a circuit breaker
has reappeared - it's now draft-ietf-pals-congcons-00.

Please ignore the fact that it's a -00 draft; it received significant
attention, including WG LC in the pwe3 WG ... but is now a -00 in the
pals WG courtesy of WG reorganization in the routing area.  The draft
actually contains a *managed* circuit breaker, which the -01 version
of this draft is expected to make clear (speaking as an author of that
draft).  As a late WGLC comment, I'd suggest adding some mention of this
pals-congcons draft to the discussion of managed circuit breakers in
the tsvwg circuit-breaker draft.

(2) Additional comments on whether the circuit-breaker draft should
be a BCP or not would be appreciated.  As an individual, I'm inclined
to agree with Colin Perkins that:

The draft seems to describe requirements for how to implement a circuit
breaker. As a BCP on that topic, it seems fine.

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
----------------------------------------------------

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Sep 2015 15:58:57 +0000

I am not sure if using mcast leaving msg for CB controlling is a good way. There are many mcast solutions providing multi-homing mechanism to a mcast receiver. If a receiver implementing CB detects congestion on current path, it can send a congestion notification by IGMP/MLD protocol instead of mcast leaving msg, thus the network may be able to switch to another path. If using mcast leaving msg, the network can't differ if a receiver wants to leave or receiver experiences congestion.

IMO: information RFC is a better fit than BCP.

Lucy  

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Black, David
Sent: Sunday, September 13, 2015 3:35 PM
To: [email-masked]
Subject: [tsvwg] TSVWG WGLC status: draft-ietf-tsvwg-circuit-breaker

It looks like all the WGLC comments on this circuit-breaker draft have been addressed in the -03 version.  There are a couple of items that could still use some attention:

(1) The pseudowire congestion draft that contains a circuit breaker has reappeared - it's now draft-ietf-pals-congcons-00.

Please ignore the fact that it's a -00 draft; it received significant attention, including WG LC in the pwe3 WG ... but is now a -00 in the pals WG courtesy of WG reorganization in the routing area.  The draft actually contains a *managed* circuit breaker, which the -01 version of this draft is expected to make clear (speaking as an author of that draft).  As a late WGLC comment, I'd suggest adding some mention of this pals-congcons draft to the discussion of managed circuit breakers in the tsvwg circuit-breaker draft.

(2) Additional comments on whether the circuit-breaker draft should be a BCP or not would be appreciated.  As an individual, I'm inclined to agree with Colin Perkins that:

The draft seems to describe requirements for how to implement a circuit breaker. As a BCP on that topic, it seems fine.

Thanks,
--David

---

From: [email-masked]
Date: Tue, 15 Sep 2015 10:30:37 +0100

> the tsvwg circuit-breaker draft.
I suggest adding the following, as section 5.4:

<?xml version="1.0"?>
<section
title="A Managed Circuit Breaker for Pseudowires (PWs)"
><t
>Pseudowires (PWs) <xref
target="rfc3985"
><ns:textPlaceholder
xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard"
></ns:textPlaceholder
></xref
> have become a common mechanism for tunneling traffic, and may be found
in unmanaged scenarios competing for network resources both with other
PWs and with non-PW traffic, such as TCP/IP flows.</t
><t
><xref
target="ID-ietf-pals-congcons"
><ns:textPlaceholder
xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard"
></ns:textPlaceholder
></xref
> specifies conditions udner which such competition is acceptable, i.e.,
the PW traffic is notr expected to significantly harm other traffic or
contribute to excessive congestion.  For inelastic PWs (e.g., Time
Division Multiplex (TDM) PWs) we derive a bound under which such PWs
consume no more network capacity than a TCP flow and that shuts down a
PW that persistently fails to comply with acceptable service criteria.
</t
></section
Would this cover this?

> breaker. As a BCP on that topic, it seems fine.
OK - noted.

> --David
Gorry

---

From: [email-masked]
Date: Tue, 15 Sep 2015 10:45:58 +0100

Please see below.

> I am not sure if using mcast leaving msg for CB controlling is a good way.
>
> There are many mcast solutions providing multi-homing mechanism to a mcast
> receiver. If a receiver implementing CB detects congestion on current
> path, it can send a congestion notification by IGMP/MLD protocol instead
> of mcast leaving msg, thus the network may be able to switch to another
> path. If using mcast leaving msg, the network can't differ if a receiver
> wants to leave or receiver experiences congestion.
>
I'm not familiar with an ICMP "congestion notification" message type.

As I understand, the way in which an application on a host leaves a
multicast group is to reset the local interface (to stop it forwarding to
the app) and generate an IGMP/MLD report  (or other equivalent message for
non-Ethernet links).

I'm not sure whether you mean something different, or would like something
else to be taken into consideration?

Let me know your thoughts, and if I missed something, I'll try to
accommodate this in the next revision (04) that I am preparing.

> IMO: information RFC is a better fit than BCP.
Noted, if others feel this way, I'd propose moving the normative text to
rfc5405bis, but I'd personally prefer to have this as a separate BCP
document to which people can refer.

Gorry

> It looks like all the WGLC comments on this circuit-breaker draft have
> been addressed in the -03 version.  There are a couple of items that could
> still use some attention:
>
> (1) The pseudowire congestion draft that contains a circuit breaker has
> reappeared - it's now draft-ietf-pals-congcons-00.
>
> attention, including WG LC in the pwe3 WG ... but is now a -00 in the pals
> WG courtesy of WG reorganization in the routing area.  The draft actually
> contains a *managed* circuit breaker, which the -01 version of this draft
> is expected to make clear (speaking as an author of that draft).  As a
> late WGLC comment, I'd suggest adding some mention of this pals-congcons
> draft to the discussion of managed circuit breakers in the tsvwg
> circuit-breaker draft.
>
> (2) Additional comments on whether the circuit-breaker draft should be a
> BCP or not would be appreciated.  As an individual, I'm inclined to agree
> with Colin Perkins that:
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 15 Sep 2015 14:43:39 +0000

Gorry,

Please see inline below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 4:46 AM
To: Lucy yong
Cc: Black, David; [email-masked]
Subject: Re: [tsvwg] Comment RE: TSVWG WGLC status: draft-ietf-tsvwg-circuit-breaker

Please see below.

> There are many mcast solutions providing multi-homing mechanism to a 
> mcast receiver. If a receiver implementing CB detects congestion on 
> current path, it can send a congestion notification by IGMP/MLD 
> protocol instead of mcast leaving msg, thus the network may be able to 
> switch to another path. If using mcast leaving msg, the network can't 
> differ if a receiver wants to leave or receiver experiences congestion.
>
I'm not familiar with an ICMP "congestion notification" message type.
[Lucy] IGMP only has join and leave msg now. ICMP does not have congestion notification yet. These protocols may be extended for the purpose. 

As I understand, the way in which an application on a host leaves a multicast group is to reset the local interface (to stop it forwarding to the app) and generate an IGMP/MLD report  (or other equivalent message for non-Ethernet links).
[Lucy] This is right and used when host wants to leave the multicast group. 

I'm not sure whether you mean something different, or would like something else to be taken into consideration?
[Lucy] IMO: if we implement CB protocol, it should not use the leaving msg as the controller msg; it should use "congestion notification" to tell the network although such protocol may not exist yet. This draft describes CB component and requirements, not specifies a protocol to achieve it. If host really wants to leave due to the congestion, it can do that; but there are cases that host may not want to leave when congestion happens. If the draft wants to state out the first, it should make that very clear. 

Let me know your thoughts, and if I missed something, I'll try to accommodate this in the next revision (04) that I am preparing.
[Lucy] see above.

> IMO: information RFC is a better fit than BCP.
Noted, if others feel this way, I'd propose moving the normative text to rfc5405bis, but I'd personally prefer to have this as a separate BCP document to which people can refer.
[Lucy] I may miss some logistic here. Can people refer to an informational RFC? An information RFC can't include normative text, is it a rule? I am new to this WG and have seen many arch and requirements RFCs that are informational. Anyway, I am fine with either way the WG picks. 

Regards,
Lucy

Gorry

> been addressed in the -03 version.  There are a couple of items that 
> could still use some attention:
>
> draft).  As a late WGLC comment, I'd suggest adding some mention of 
> this pals-congcons draft to the discussion of managed circuit breakers 
> in the tsvwg circuit-breaker draft.
>
> (2) Additional comments on whether the circuit-breaker draft should be 
> a BCP or not would be appreciated.  As an individual, I'm inclined to 
> agree with Colin Perkins that:
>
> The draft seems to describe requirements for how to implement a 
> circuit breaker. As a BCP on that topic, it seems fine.
>
> Thanks,
> --David
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748

---

From: "Black, David" <[email-masked]>
Date: Tue, 15 Sep 2015 19:57:48 +0000

Lucy,

On the intended publication status topic:

> rfc5405bis, but I'd personally prefer to have this as a separate BCP document
> to which people can refer.
> [Lucy] I may miss some logistic here. Can people refer to an informational
> RFC? An information RFC can't include normative text, is it a rule?

Yes, with exceptions.

When a Standards track RFC (e.g., Proposed Standard) normatively references
an Informational RFC, that is called a downward reference (DOWNREF) and is
an exceptional situation that requires special handling at both IETF Last Call
and the IESG, see:

RFC 3967: https://datatracker.ietf.org/doc/rfc3967/
IESG DOWNREF registry: https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

Quoting from RFC 3967's abstract:

   IETF procedures generally require that a standards track RFC may not
   have a normative reference to another standards track document at a
   lower maturity level or to a non standards track specification (other
   than specifications from other standards bodies).  For example, a
   standards track document may not have a normative reference to an
   informational RFC.  Exceptions to this rule are sometimes needed as
   the IETF uses informational RFCs to describe non-IETF standards or
   IETF-specific modes of use of such standards.

An important implication is that a document that is expected to routinely
referenced by standards track drafts/RFCs should not be published as an
Informational RFC.

Thanks,
--David

> From: Lucy yong [mailto:[email-masked]]
> Sent: Tuesday, September 15, 2015 10:44 AM
> To: [email-masked]
> Subject: RE: [tsvwg] Comment RE: TSVWG WGLC status: draft-ietf-tsvwg-circuit-
> breaker
> 
> Gorry,
> 
> Please see inline below.
> 
> [Lucy] IGMP only has join and leave msg now. ICMP does not have congestion
> notification yet. These protocols may be extended for the purpose.
> 
> As I understand, the way in which an application on a host leaves a multicast
> group is to reset the local interface (to stop it forwarding to the app) and
> generate an IGMP/MLD report  (or other equivalent message for non-Ethernet
> links).
> [Lucy] IMO: if we implement CB protocol, it should not use the leaving msg as
> the controller msg; it should use "congestion notification" to tell the
> network although such protocol may not exist yet. This draft describes CB
> component and requirements, not specifies a protocol to achieve it. If host
> really wants to leave due to the congestion, it can do that; but there are
> cases that host may not want to leave when congestion happens. If the draft
> wants to state out the first, it should make that very clear.
> 
> Let me know your thoughts, and if I missed something, I'll try to accommodate
> this in the next revision (04) that I am preparing.
> [Lucy] see above.
> 
> rfc5405bis, but I'd personally prefer to have this as a separate BCP document
> to which people can refer.
> [Lucy] I may miss some logistic here. Can people refer to an informational
> RFC? An information RFC can't include normative text, is it a rule? I am new
> to this WG and have seen many arch and requirements RFCs that are
> informational. Anyway, I am fine with either way the WG picks.
> 
> Regards,
> Lucy
> 
> Gorry
> 
> > Lucy
> >

---

From: "Black, David" <[email-masked]>
Date: Tue, 15 Sep 2015 20:00:59 +0000

> referenced by standards track drafts/RFCs should not be published as an

Missing word ... (sorry):

An important implication is that a document that is expected to routinely *be*
referenced by standards track drafts/RFCs should not be published as an
Informational RFC.

Thanks,
--David

> Sent: Tuesday, September 15, 2015 3:58 PM
> To: Lucy yong
> Cc: [email-masked]
> IESG DOWNREF registry:
> https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
> 
> > Subject: Re: [tsvwg] Comment RE: TSVWG WGLC status: draft-ietf-tsvwg-
> circuit-
> > breaker
> >
> > Please see below.
> >
> multicast
> accommodate

---

From: Lucy yong <[email-masked]>
Date: Tue, 15 Sep 2015 20:17:04 +0000

David,

Thanks. Reading RFC1818, I now know the difference between informational and BCP. It is OK to publish as BCP.

Lucy
-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 2:58 PM
To: Lucy yong
Cc: [email-masked]
Subject: RE: [tsvwg] Comment RE: TSVWG WGLC status: draft-ietf-tsvwg-circuit-breaker

Lucy,

On the intended publication status topic:

> Noted, if others feel this way, I'd propose moving the normative text 
> to rfc5405bis, but I'd personally prefer to have this as a separate 
> BCP document to which people can refer.
> [Lucy] I may miss some logistic here. Can people refer to an 
> informational RFC? An information RFC can't include normative text, is it a rule?

Yes, with exceptions.

When a Standards track RFC (e.g., Proposed Standard) normatively references an Informational RFC, that is called a downward reference (DOWNREF) and is an exceptional situation that requires special handling at both IETF Last Call and the IESG, see:

An important implication is that a document that is expected to routinely referenced by standards track drafts/RFCs should not be published as an Informational RFC.

Thanks,
--David

> Subject: RE: [tsvwg] Comment RE: TSVWG WGLC status: 
> draft-ietf-tsvwg-circuit- breaker
> 
> Gorry,
> 
> Please see inline below.
> 
> Subject: Re: [tsvwg] Comment RE: TSVWG WGLC status: 
> draft-ietf-tsvwg-circuit- breaker
> 
> Please see below.
> 
> > protocol instead of mcast leaving msg, thus the network may be able 
> > to switch to another path. If using mcast leaving msg, the network 
> > can't differ if a receiver wants to leave or receiver experiences congestion.
> >
> [Lucy] IGMP only has join and leave msg now. ICMP does not have 
> congestion notification yet. These protocols may be extended for the purpose.
> 
> multicast group is to reset the local interface (to stop it forwarding 
> to the app) and generate an IGMP/MLD report  (or other equivalent 
> message for non-Ethernet links).
> I'm not sure whether you mean something different, or would like 
> something else to be taken into consideration?
> [Lucy] IMO: if we implement CB protocol, it should not use the leaving 
> msg as the controller msg; it should use "congestion notification" to 
> tell the network although such protocol may not exist yet. This draft 
> describes CB component and requirements, not specifies a protocol to 
> achieve it. If host really wants to leave due to the congestion, it 
> can do that; but there are cases that host may not want to leave when 
> congestion happens. If the draft wants to state out the first, it should make that very clear.
> 
> Noted, if others feel this way, I'd propose moving the normative text 
> to rfc5405bis, but I'd personally prefer to have this as a separate 
> BCP document to which people can refer.
> [Lucy] I may miss some logistic here. Can people refer to an 
> informational RFC? An information RFC can't include normative text, is 
> it a rule? I am new to this WG and have seen many arch and 
> requirements RFCs that are informational. Anyway, I am fine with either way the WG picks.
> 
> Regards,
> Lucy
> 
> Gorry
> 
> > Lucy
> >
> > It looks like all the WGLC comments on this circuit-breaker draft 
> > have been addressed in the -03 version.  There are a couple of items 
> > that could still use some attention:
> >
> > Please ignore the fact that it's a -00 draft; it received 
> > significant attention, including WG LC in the pwe3 WG ... but is now 
> > a -00 in the pals WG courtesy of WG reorganization in the routing 
> > area.  The draft actually contains a *managed* circuit breaker, 
> > which the -01 version of this draft is expected to make clear 
> > (speaking as an author of that draft).  As a late WGLC comment, I'd 
> > suggest adding some mention of this pals-congcons draft to the 
> > discussion of managed circuit breakers in the tsvwg circuit-breaker draft.
> >
> > be a BCP or not would be appreciated.  As an individual, I'm 
> > inclined to agree with Colin Perkins that:
> >
> > David L. Black, Distinguished Engineer EMC Corporation, 176 South 
> > St., Hopkinton, MA  01748

---

From: "Black, David" <[email-masked]>
Date: Mon, 21 Sep 2015 14:19:17 +0000

> Would this cover this?

The suggested text is "digging in the right place" (I would definitely

> PWs and with non-PW traffic, such as TCP/IP flows.</t

"may be found in unmanaged scenarios competing for"
-> "may compete for"

One consideration here is to avoid trying to explain "unmanaged" in this draft.

Beyond here, I have rewrites to suggest:

> > specifies conditions under which such competition is acceptable, i.e.,
> the PW traffic is not expected to significantly harm other traffic or
> contribute to excessive congestion.

New text suggestion:

<draft-ietf-pals-congcons> discusses congestion considerations that can
arise when PWs complete with elastic (i.e., congestion responsive) network
traffic (e.g., TCP traffic). Elastic PWs (e.g., Ethernet PWs carrying IP
traffic, see [RFC 4448]) do not raise major concerns because all of the
traffic involved responds to the occurrence of network congestion.

> For inelastic PWs (e.g., Time

In contrast, inelastic PWs (e.g., fixed bandwidth Time Division Multiplex
(TDM) PWs, [RFC4553][RFC5086][RFC5087]) have the potential to harm
congestion responsive traffic or contribute to excessive congestion because
inelastic PWs do not adjust their transmission rate in response to congestion.
<draft-ietf-pals-congcons> analyzes TDM PWs, with an initial conclusion that
a TDM PW operating with a degree of loss that may result congestion-related
problems is also operating with a degree of loss that results in unacceptable
TDM service.  For that reason, the draft suggests that a managed circuit
breaker that shuts down PWs when they persistently fail to deliver acceptable
TDM service is a useful means of addressing these congestion concerns.

Thanks,
--David

> Sent: Tuesday, September 15, 2015 5:31 AM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [tsvwg] TSVWG WGLC status: draft-ietf-tsvwg-circuit-breaker
> 
> > been

---

From: "Black, David" <[email-masked]>
Date: Mon, 21 Sep 2015 19:58:53 +0000

> has reappeared - it's now draft-ietf-pals-congcons-00.

A new version of the draft incorporating text from list discussion
would be appreciated.  I'll prepare the writeup based on that version.

> be a BCP or not would be appreciated.  

BCP status appears to be appropriate; this will be discussed further
with our AD.

Thanks,
--David

> From: Black, David
> Sent: Sunday, September 13, 2015 4:35 PM
> To: [email-masked]
> Cc: Black, David
> Subject: TSVWG WGLC status: draft-ietf-tsvwg-circuit-breaker
>

---

From: [email-masked]
Date: Thu, 24 Sep 2015 07:57:45 +0100

I agree with the changes you suggest, and have incorporated new text. My
working version now reads as below.

You mention making this text section 5.4, however that structure to me
suggests that this is a new type of circuit breaker, which I think this is
not. I therefore propose using your wording to handle the possibility of
other CBs being defined in this space, but to retain this specific example
of the need for a managed circuit breaker, and position the text at 5.3.2.
Is this OK?

New text follows.

Gorry

<?xml version="1.0"?>
<section
target="rfc3985"
></ns:textPlaceholder
></xref
> have become a common mechanism for tunneling traffic, and may compete
for network resources both with other PWs and with non-PW traffic, such
as TCP/IP flows.</t
></ns:textPlaceholder
></xref
> discusses congestion conditions that can arise when PWs compete with
elastic (i.e., congestion responsive) network traffic (e.g, TCP
traffic). Elastic PWs carrying Ip traffic (see <xref
target="RFC4488"
></ns:textPlaceholder
></xref
>) do not raise major concerns because all of the traffic involved
responds, reducing the transmission rate when network congestion is
detected. </t
><t
>In contrast, inelastic PWs (e.g., fixed (e.g., fixed bandwidth Time
Division Multiplex (TDM)  <xref
target="RFC4553"
> <xref
target="RFC5086"
> <xref
target="RFC5087"
></ns:textPlaceholder
></xref
>) have the potential to harm congestion responsive traffic or to
contribute to excessive congestion because inelastic PWs do not adjust
their transmission rate in response to congestion. <xref
target="ID-ietf-pals-congcons"
></ns:textPlaceholder
></xref
>  analyses TDM PWs, with an initial conclusion that a TDM PW operating
with a degree of loss that may result in congestion-related problems is
also operating with a degree of loss that results in an unacceptable
TDM service. For that reason, the draft suggests that a managed circuit
breaker that shuts down a PW when it persistently fails to deliver
acceptable TDM service is a useful means for addressing these
congestion concerns.</t

---

From: "Black, David" <[email-masked]>
Date: Thu, 24 Sep 2015 12:57:11 +0000

Yes, positioning the text at 5.3.2 is fine.

Please submit a new version of the draft, and I'll go work on the writeup for it.

Thanks,
--David

> Sent: Thursday, September 24, 2015 2:58 AM
> To: Black, David
> Cc: [email-masked]
> Subject: New text on PWs: draft-ietf-tsvwg-circuit-breaker
> 
>

---

From: [email-masked]
Date: Fri, 25 Sep 2015 10:02:41 +0100

Thanks. I have now incorporated the new text in the draft and submitted a
revision to address this new draft.

Best wishes,

Gorry