[conex] Fwd: RFC 6040 on Tunnelling of Explicit Congestion Notification

[Bob Briscoe <[e-mail]>]

Folks,

RFC6040 has just been published.

As it gets deployed, it will remove an otherwise awkward barrier to 
ConEx deployment. Because it ensures ECN is visible in the outer 
header of all IP-in-IP tunnels (IPsec tunnels were OK in this 
respect, but non-IPsec tunnels were not).

This is particularly important for LTE, which uses IP-in-IP tunnels 
everywhere. So, it's important to ensure that LTE equipment is all 
compliant with RFC6040.

This means IP-in-IP, MPLS-in-IP and MPLS-in-MPLS all now expose 
upstream ECN congestion markings in the outer header,... at least if 
they comply with the latest specs: RFC6040 and RFC5129.

This also makes it more likely that future standardisation of ECN for 
other link layers (esp IEEE802) will follow the same model.

Over a year ago I wrote a pre-Internet Draft giving guidelines on 
adding ECN to other technologies below IP (e.g. IEEE802). It used 
text removed from the early I-D that became RFC6040 - when we decided 
to narrow its scope to just IP-in-IP:
<http://www.bobbriscoe.net/projects/ipe2eqos/pcn/marking/draft-briscoe-tsvwg-ecn-encap-guidelines-00a.txt>
Would anyone support taking this through the IETF? Probably as a BCP? 
Probably through tsvwg?


Bob

PS. Being a change to IP and to IPsec, it took some heavy lifting to 
get through. I submitted the first individual draft at the time we 
were thinking about the Trilogy proposal (Mar 1997).
<http://www.arkko.com/tools/lifecycle/draft-ietf-tsvwg-ecn-tunnel-timing.html>



>To: <[e-mail]>, <[e-mail]>
>Subject: RFC 6040 on Tunnelling of Explicit Congestion Notification
>From: <[e-mail]>
>Date: Mon, 29 Nov 2010 22:27:37 -0800
>CC: <[e-mail]>, <[e-mail]>
>List-Id: Transport Area Working Group <tsvwg.ietf.org>
>List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>,
>         <mailto:[e-mail]?subject=unsubscribe>
>List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
>List-Post: <mailto:[e-mail]>
>List-Help: <mailto:[e-mail]?subject=help>
>List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>,
>         <mailto:[e-mail]?subject=subscribe>
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 6040
>
>         Title:      Tunnelling of Explicit Congestion Notification
>         Author:     B. Briscoe
>         Status:     Standards Track
>         Stream:     IETF
>         Date:       November 2010
>         Mailbox:    [e-mail]
>         Pages:      35
>         Characters: 89412
>         Updates:    RFC3168, RFC4301, RFC4774
>
>         I-D Tag:    draft-ietf-tsvwg-ecn-tunnel-10.txt
>
>         URL:        http://www.rfc-editor.org/rfc/rfc6040.txt
>
>This document redefines how the explicit congestion notification
>(ECN) field of the IP header should be constructed on entry to and
>exit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168
>to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301
>IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and
>RFC 4301 to add new behaviours for previously unused combinations of
>inner and outer headers.  The new rules ensure the ECN field is
>correctly propagated across a tunnel whether it is used to signal one
>or two severity levels of congestion; whereas before, only one
>severity level was supported.  Tunnel endpoints can be updated in any
>order without affecting pre-existing uses of the ECN field, thus
>ensuring backward compatibility.  Nonetheless, operators wanting to
>support two severity levels (e.g., for pre-congestion notification --
>PCN) can require compliance with this new specification.  A thorough
>analysis of the reasoning for these changes and the implications is
>included.  In the unlikely event that the new rules do not meet a
>specific need, RFC 4774 gives guidance on designing alternate ECN
>semantics, and this document extends that to include tunnelling
>issues.  [STANDARDS-TRACK]
>
>This document is a product of the Transport Area Working Group 
>Working Group of the IETF.
>
>This is now a Proposed Standard Protocol.
>
>STANDARDS TRACK: This document specifies an Internet standards track
>protocol for the Internet community,and requests discussion and suggestions
>for improvements.  Please refer to the current edition of the Internet
>Official Protocol Standards (STD 1) for the standardization state and
>status of this protocol.  Distribution of this memo is unlimited.
>
>This announcement is sent to the IETF-Announce and rfc-dist lists.
>To subscribe or unsubscribe, see
>   http://www.ietf.org/mailman/listinfo/ietf-announce
>   http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
>For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
>For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to [e-mail].  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.
>
>
>The RFC Editor Team
>Association Management Solutions, LLC

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design