From rbriscoe@jungle.bt.co.uk Fri Dec 3 11:35:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D5C3A6993 for ; Fri, 3 Dec 2010 11:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jojkoFHUQQvh for ; Fri, 3 Dec 2010 11:35:48 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CCB873A698E for ; Fri, 3 Dec 2010 11:35:47 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Dec 2010 19:37:04 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Dec 2010 19:37:04 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1291405023806; Fri, 3 Dec 2010 19:37:03 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.19.86]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oB3Jb2UC027933 for ; Fri, 3 Dec 2010 19:37:02 GMT Message-Id: <201012031937.oB3Jb2UC027933@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Dec 2010 19:37:03 +0000 To: ConEx IETF list From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 03 Dec 2010 19:37:04.0451 (UTC) FILETIME=[76AE0130:01CB9321] Subject: [conex] Fwd: RFC 6040 on Tunnelling of Explicit Congestion Notification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 19:35:55 -0000 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: 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). >To: , >Subject: RFC 6040 on Tunnelling of Explicit Congestion Notification >From: >Date: Mon, 29 Nov 2010 22:27:37 -0800 >CC: , >List-Id: Transport Area Working Group >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-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: bob.briscoe@bt.com > 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 rfc-editor@rfc-editor.org. 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 From toby@moncaster.com Sat Dec 4 08:11:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FE728C0E1 for ; Sat, 4 Dec 2010 08:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=0.6, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n8fXbn9a+6p for ; Sat, 4 Dec 2010 08:11:17 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 836E728C0DB for ; Sat, 4 Dec 2010 08:11:16 -0800 (PST) Received: from TobysHP (host86-152-88-47.range86-152.btcentralplus.com [86.152.88.47]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lv8ja-1OOnwZ1KJ0-010eQS; Sat, 04 Dec 2010 17:12:34 +0100 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'ConEx IETF list'" References: <201012031937.oB3Jb2UC027933@bagheera.jungle.bt.co.uk> In-Reply-To: <201012031937.oB3Jb2UC027933@bagheera.jungle.bt.co.uk> Date: Sat, 4 Dec 2010 16:12:33 -0000 Message-ID: <000e01cb93ce$0fc44c60$2f4ce520$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuTIX4owV296x/4S9utiDdZDi4ZJAAq8wog Content-Language: en-gb X-Provags-ID: V02:K0:HLnLMmp31nhJN0pu8ktgTehohZv/D3+AY5v0R74detx EWk2gJ8pu/ei9BJbhqixmb3J+UInpyXTvYPoiee0/d8zmz7xLt fUz8Rn9jZwwtDHRj2623hw7qxTV86pfiOIvYnlez7wmNPQC5+H qYpKRP2XZs8kPs07UtdmXXTrbDBx1Vm+PyUswV0/NDfpxuf0Fn VFvpZZhfeuVff5ckz5APMJLNM+r19SLJ/ffGdavBCk= Subject: Re: [conex] Fwd: RFC 6040 on Tunnelling of Explicit Congestion Notification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:11:20 -0000 inline > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Bob Briscoe > Sent: 03 December 2010 19:37 > To: ConEx IETF list > Subject: [conex] Fwd: RFC 6040 on Tunnelling of Explicit Congestion > Notification > > Folks, > > RFC6040 has just been published. Congratulations. A useful new RFC that addresses some of the more silly inconsistencies in IP-in-IP tunnelling... > > 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. Unfortunately I suspect there may already be quite a lot of kit out there that isn't compliant! > > 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: > tsvwg-ecn-encap-guidelines-00a.txt> > Would anyone support taking this through the IETF? Probably as a BCP? > Probably through tsvwg? I think this would be a good idea. Might it also be sensible to start working out if any liaison is needed with other standards bodies (since this impacts their standards)? As I see it there are two approaches - a very broad guidelines document stating what the end result should be or a number of more specific documents for groups of sub-IP technologies. Although the first approach is cleaner it runs a risk of just getting ignored. Toby > > > 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). > timing.html> > > > > >To: , > >Subject: RFC 6040 on Tunnelling of Explicit Congestion Notification > >From: > >Date: Mon, 29 Nov 2010 22:27:37 -0800 > >CC: , > >List-Id: Transport Area Working Group > >List-Unsubscribe: , > > > >List-Archive: > >List-Post: > >List-Help: > >List-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: bob.briscoe@bt.com > > 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 rfc-editor@rfc-editor.org. > 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 > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From jbabiarz@istop.com Sat Dec 4 08:54:32 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034923A6A86 for ; Sat, 4 Dec 2010 08:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_93=0.6, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgvjzgNfCYZi for ; Sat, 4 Dec 2010 08:54:30 -0800 (PST) Received: from fish.cia.com (fish.cybersurf.net [209.197.145.184]) by core3.amsl.com (Postfix) with ESMTP id B04393A6894 for ; Sat, 4 Dec 2010 08:54:29 -0800 (PST) Received: from i209-195-113-216.cia.com ([209.195.113.216] helo=Joe) by fish.cia.com with esmtp (Exim 4.50) id 1POvOm-0000uq-AC; Sat, 04 Dec 2010 09:55:48 -0700 From: "Joe Babiarz" To: "'Bob Briscoe'" , "'ConEx IETF list'" References: <201012031937.oB3Jb2UC027933@bagheera.jungle.bt.co.uk> In-Reply-To: <201012031937.oB3Jb2UC027933@bagheera.jungle.bt.co.uk> Date: Sat, 4 Dec 2010 11:55:49 -0500 Message-ID: <000f01cb93d4$1a773180$4f659480$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuTIZHUILAIdY5dSwqx8434reBb5QAsfr6g Content-Language: en-us Subject: Re: [conex] Fwd: RFC 6040 on Tunnelling of Explicit Congestion Notification X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 16:54:32 -0000 Thanks Bob for getting the ECN marking when tunneling issue resolved. Regards, Joe. jbabiarz@istop.com -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of Bob Briscoe Sent: Friday, December 03, 2010 2:37 PM To: ConEx IETF list Subject: [conex] Fwd: RFC 6040 on Tunnelling of Explicit Congestion Notification 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: 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). >To: , >Subject: RFC 6040 on Tunnelling of Explicit Congestion Notification >From: >Date: Mon, 29 Nov 2010 22:27:37 -0800 >CC: , >List-Id: Transport Area Working Group >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-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: bob.briscoe@bt.com > 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 rfc-editor@rfc-editor.org. 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 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex