Subject: [PCN] draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue

From: Bob Briscoe <[email-masked]>
Date: Tue, 21 Jul 2009 18:35:22 +0100

tsvwg & pcn folks,

I've revised draft-ietf-tsvwg-ecn-tunnel to -03 after extensive 
review comments. Thanks for the deep reviews from Gorry Fairhurst, 
Michael Menth, Ingemar Johansson, Toby Moncaster and David Black.

I didn't upload it in time for the draft deadline (sorry), but I've 
uploaded -03 to my personal Web site, while we wait for the queue to re-open:
<http://www.bobbriscoe.net/pubs.html#ecn-tunnel>

I shall be presenting the draft in the Security Area Advisory Group 
next week, as well as in tsvwg.

As you may have noticed, there are still open discussions on the 
list, but I wanted to put the new revision up there, as it's had a 
major bashing. A summary of the changes is below...

Bob
===========================================================================

              Tunnelling of Explicit Congestion Notification
                      draft-ietf-tsvwg-ecn-tunnel-03

Abstract

    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 RFC3168
    to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
    ECN processing.  On decapsulation it updates both RFC3168 and RFC4301
    to add new behaviours for previously unused combinations of inner and
    outer header.  The new rules propagate the ECN field whether it is
    used to signal one or two severity levels of congestion, whereas
    before they propagated only one.  Tunnel endpoints can be updated in
    any order without affecting pre-existing uses of the ECN field
    (backward compatible).  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.

    From ietf-02 to ietf-03 (current):

       *  Functional changes:

          +  Corrected errors in recap of previous RFCs, which wrongly
             stated the different decapsulation behaviours of RFC3168 &
             RFC4301 with a Not-ECT inner header.  This also required
             corrections to the "Changes from Earlier RFCs" and the
             Motivations for these changes.

          +  Mandated that any future standards action SHOULD NOT use the
             ECT(0) codepoint as an indication of congestion, without
             giving strong reasons.

          +  Added optional alarm when decapsulating ECT(1) outer,
             ECT(0), but noted it would need to be disabled for
             2-severity level congestion (e.g.  PCN).

       *  Structural changes:

          +  Removed Document Roadmap which merely repeated the Contents
             (previously Section 1.2).

          +  Moved "Changes from Earlier RFCs" (Section 5) before
             Section 6 on Backward Compatibility and internally organised
             both by RFC, rather than by ingress then egress.

          +  Moved motivation for changing existing RFCs (Section 5.3) to
             after the changes are specified.

          +  Moved informative "Design Principles for Future Non-Default
             Schemes" after all the normative sections.

          +  Added Appendix A on early history of ECN tunnelling RFCs.

          +  Removed specialist appendix on "Relative Placement of
             Tunnelling and In-Path Load Regulation" (Appendix D in the
             -02 draft)

          +  Moved and updated specialist text on "Compromise on Decap
             with ECT(1) Inner and ECT(0) Outer" from Security
             Considerations to Appendix F

       *  Textual changes:

          +  Simplified vocabulary for non-native-english speakers

          +  Simplified Introduction and defined regularly used terms in
             an expanded Terminology section.

          +  More clearly distinguished statically configured tunnels
             from dynamic tunnel endpoint discovery, before explaining
             operating modes.

          +  Simplified, cut-down and clarified throughout

          +  Updated references.

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research