Subject: [Tsvwg] Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec

From: Bob Briscoe <[email-masked]>
Date: Thu, 17 Jul 2008 21:00:38 +0100

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, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 27 Jul 2008 10:20:00 +0100

PCN, PWE3, IPsec lists,

Just notifying you of an I-D just posted that could become relevant 
to each of your w-gs (if it becomes a w-g item - it's still an 
individual draft).

See posting below for details.

You might choose to wait to see whether it becomes a tsvwg WG item 
before reading, or you might want to help (or hinder!) it becoming a 
WG item. The standards action stuff is in 2 pages from S.5 to S.7.

Pls cross-post any discussion that affects your w-g to 
<[email-masked]> at least.

Cheers

Bob

>Date: Thu, 17 Jul 2008 21:00:38 +0100
>To: "tsvwg IETF list" <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec
>
>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 ;)
>