Skip to main content

Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: David Black <>, The IESG <>,,,,,,
Subject: Protocol Action: 'Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP' to Best Current Practice (draft-ietf-tsvwg-ecn-encap-guidelines-20.txt)

The IESG has approved the following document:
- 'Guidelines for Adding Congestion Notification to Protocols that
   Encapsulate IP'
  (draft-ietf-tsvwg-ecn-encap-guidelines-20.txt) as Best Current Practice

This document is the product of the Transport and Services Working Group.

The IESG contact persons are Zaheduzzaman Sarker and Martin Duke.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

   The purpose of this document is to guide the design of congestion
   notification in any lower layer or tunnelling protocol that
   encapsulates IP.  The aim is for explicit congestion signals to
   propagate consistently from lower layer protocols into IP.  Then the
   IP internetwork layer can act as a portability layer to carry
   congestion notification from non-IP-aware congested nodes up to the
   transport layer (L4).  Following these guidelines should assure
   interworking among IP layer and lower layer congestion notification
   mechanisms, whether specified by the IETF or other standards bodies.
   This document is included in BCP 89 and updates the advice to
   subnetwork designers about ECN in RFC 3819.

Working Group Summary

Sebastian Moeller repeatedly questioned on the mailing list the use of
recommendations that were based on an earlier BCP, i.e. RFC 7141, saying that
some of the earlier concepts recommended in RFC 7141 were yet to be
implemented. The chairs and editors are content that the current revision has
considered this feedback and looked into these topics, and that citing RFC 7141
is consistent with good practice.

Document Quality

This is a BCP that is not directly implementable, but 4 RFCs and 3 I-Ds referernce it.


   The Document Shepherd for this document is Gorry Fairhurst. The
   Responsible Area Director is Martin Duke.

RFC Editor Note