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

[Bob Briscoe <[e-mail]>]

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 
<[e-mail]> at least.

Cheers


Bob


>Date: Thu, 17 Jul 2008 21:00:38 +0100
>To: "tsvwg IETF list" <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: Updated: ECN Tunnelling I-D relevant to PCN, PWE3, IPsec
>
>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, <[e-mail]>      Networks Research Centre, BT Research
>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]

____________________________________________________________________________
Bob Briscoe, <[e-mail]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]