Liaison statement
Explicit Congestion Notification (ECN) and IEEE Protocols

To:  "IEEE 802 – attn. Paul Nikolich, Chair" <p.nikolich@ieee.org>
From:  "IETF TSVWG" <tsvwg-chairs@tools.ietf.org>
CC: "Martin Stiemerling" <mls.ietf@gmail.com>, "Spencer Dawkins" <spencerdawkins.ietf@gmail.com>,
	"Pat Thaler" <pthaler@broadcom.com>, "Bob Briscoe" <bob.briscoe@bt.com>,
	"Glenn Parsons - IEEE 802.1 WG chair" <gparsons@ieee.org>,
	"Eric Gray" <eric.gray@ericsson.com>, "Dan Romascanu" <dromasca@avaya.com>,
	"Russ Housley" <housley@vigilsec.com>

==Background==
In 2001, the IETF introduced explicit congestion notificiation (ECN) to the Internet Protocol
as a  proposed standard, see RFC 3168. The purpose of ECN was to notify congestion without
having to drop packets. The IETF originally specified ECN for cases where buffers were IP-aware.

However, ECN is now being used in a number of environments where some of the forwarding devices
are solely layer-2 devices, where IEEE protocols encapsulate IP. Originally there was little
if any guidance on how to add explicit congestion notification to lower layer protocols, nor
on the interface between lower layers and ECN in IP.

==Notification==
This liaison statement is addressed at IEEE 802, and particularly though not exclusively the
802.1 WG for congestion marking in bridges and other WGs for other forms of forwarding. The
IETF wishes to notify relevant WGs that it has started work on guidelines for adding ECN to
protocols that may encapsulate IP and interfacing these protocols with ECN in IP. Then IP may
act in its role as an interoperability protocol over multiple forwarding protocols. This
activity is led by the IETF's transport services working group (tsvwg).

==Requests==
The IETF tsvwg kindly asks IEEE 802:
1) To inform the IETF tsvwg of which IEEE work-groups could be affected by this work.
2) To inform the IETF tsvwg of any specific IEEE specifications affected by this work.
3) to forward this liaison statement to these affected work-groups, and to invite them to
	review the latest draft of the guidelines, available here:
         - http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines
Review comments are particularly welcome on:
  - comprehensibility for the IEEE community
  - usefulness and applicability
  - technical feasibility

Review comments may be posted directly to the IETF tsvwg mailing list
<mailto: tsvwg@ietf.org>. Postings from non-subscribers may be delayed by moderation.
Alternatively,  subscription is open to all at: < https://www.ietf.org/mailman/listinfo/tsvwg>.

==Relevant IETF Specifications==
The following IETF specifications or drafts are particularly relevant to this activity
(the relevance of each of them is explained in the first item below):
* draft-ietf-tsvwg-ecn-encap-guidelines
	- http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines
* RFC3168 updated by RFC4301, RFC6040 (ECN in resp. IP/TCP, IPsec & IP-in-IP tunnels)
	- https://tools.ietf.org/html/rfc3168
	- https://tools.ietf.org/html/rfc4301
	- https://tools.ietf.org/html/rfc6040
* RFC6679 (ECN in RTP)
	- https://tools.ietf.org/html/rfc6679
* RFC5129 updated by RFC5462 (ECN in MPLS)
	- https://tools.ietf.org/html/rfc5129
	- https://tools.ietf.org/html/rfc5462
* RFC4774 (Specifying alternative semantics for the ECN field)
	- https://tools.ietf.org/html/rfc4774
* draft-ietf-aqm-recommendation
	- http://tools.ietf.org/html/draft-ietf-aqm-recommendation

Sincerely yours,
-- David Black (IETF tsvwg co-chair) <david.black@emc.com>