[Tsvwg] Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec
Bob Briscoe <rbriscoe@jungle.bt.co.uk> Thu, 17 July 2008 20:00 UTC
Return-Path: <tsvwg-bounces@ietf.org>
X-Original-To: tsvwg-archive@optimus.ietf.org
Delivered-To: ietfarch-tsvwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A083A6831; Thu, 17 Jul 2008 13:00:20 -0700 (PDT)
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C873A6831 for <tsvwg@core3.amsl.com>; Thu, 17 Jul 2008 13:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.334
X-Spam-Level:
X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=-1.117, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3, 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 jCVSDTZ4biND for <tsvwg@core3.amsl.com>; Thu, 17 Jul 2008 13:00:12 -0700 (PDT)
Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 8F60B3A67FC for <tsvwg@ietf.org>; Thu, 17 Jul 2008 13:00:12 -0700 (PDT)
Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 21:00:43 +0100
Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 21:00:43 +0100
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 1216324842133; Thu, 17 Jul 2008 21:00:42 +0100
Received: from mut.jungle.bt.co.uk ([10.73.81.228]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6HK0dwW015818 for <tsvwg@ietf.org>; Thu, 17 Jul 2008 21:00:41 +0100
Message-Id: <200807172000.m6HK0dwW015818@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 17 Jul 2008 21:00:38 +0100
To: tsvwg IETF list <tsvwg@ietf.org>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
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: 17 Jul 2008 20:00:43.0552 (UTC) FILETIME=[CB8EE200:01C8E847]
Subject: [Tsvwg] Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
Sender: tsvwg-bounces@ietf.org
Errors-To: tsvwg-bounces@ietf.org
Tsvwg (also relevant to PCN, PWE3 & IPsec - but pls discuss on tsvwg), Layered Encapsulation of Congestion Notification <draft-briscoe-tsvwg-ecn-tunnel-01.txt> (intended for standards track) Abstract and summary of diffs pasted below. At the last -00 rev, on the tsvwg list there was unanimous support and no detractors for the primary proposal to bring the ECN behaviour of IP in IP tunnels into line with IPsec tunnels. However, many voiced concerns about secondary aspects of the -00 draft. I believe I've fixed them all (with considerable help from David Black and RFC2983), but I've probably added more ;) That was a year ago. The ADs suggested, and I agreed, that we should let it lie until PCN wire protocol was clearer (in case there was an interaction). PCN's just become clearer. So I've rev'd this one back to life. I'm about to go offline until Dublin starts, so I'll pick up any discussion then. Bob Abstract This document redefines how the explicit congestion notification (ECN) field of the outer IP header of a tunnel should be constructed. It brings all IP in IP tunnels (v4 or v6) into line with the way IPsec tunnels now construct the ECN field. It includes a thorough analysis of the reasoning for this change and the implications. It also gives guidelines on the encapsulation of IP congestion notification by any outer header, whether encapsulated in an IP tunnel or in a lower layer header. Following these guidelines should help interworking, if the IETF or other standards bodies specify any new encapsulation of congestion notification. Changes From -00 to -01: * Related everything conceptually to the uniform and pipe models of RFC2983 on Diffserv Tunnels, and completely removed the dependence of tunnelling behaviour on the presence of any in- path load regulation by using the [1 - Before] [2 - Outer] function placement concepts from RFC2983. * Added specifc cases where the existing standards limit new proposals. * Added sub-structure to Introduction (Need for Rationalisation, Roadmap), added new Introductory subsection on "Scope" and improved clarity * Added Design Guidelines for New Encapsulations of Congestion Notification * Considerably clarified the Backward Compatibility section * Considerably extended the Security Considerations section * Summarised the primary rationale much better in the conclusions * Added numerous extra acknowledgements * Added Appendix A. "Why resetting CE on encapsulation harms PCN", Appendix B. "Contribution to Congestion across a Tunnel" and Appendix C. "Ideal Decapsulation Rules" * Changed Appendix A "In-path Load Regulation" to "Non-Dependence of Tunnelling on In-path Load Regulation" and added sub-section on "Dependence of In-Path Load Regulation on Tunnelling" ____________________________________________________________________________ Bob Briscoe, <bob.briscoe@bt.com> Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196