Subject: [tsvwg] I-D Action:draft-ietf-tsvwg-ecn-tunnel-05.txt

From: [email-masked]
Date: Fri, 18 Dec 2009 08:15:05 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group Working Group of the IETF.

	Title           : Tunnelling of Explicit Congestion Notification
	Author(s)       : B. Briscoe
	Filename        : draft-ietf-tsvwg-ecn-tunnel-05.txt
	Pages           : 41
	Date            : 2009-12-18

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 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 (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.  In the unlikely
event that the new rules do not meet a specific need, RFC4774 gives
guidance on designing alternate ECN semantics and this document
extends that to include tunnelling issues.

Status of This Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 21, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 18 Dec 2009 18:12:04 +0000

David, Pls see whether the alarms aspects are acceptable. You will 
also see all the other functional amendments we agreed.

Gorry, I've dealt with all your editorial review comments as 
requested - thanks - they are good improvements - hope you like them. 
I cut down the two appendices you requested, but I don't want to cut 
them down further until after Security Directorate review - they were 
mainly in there to allow the Security guys to understand the subset 
of motivations for this draft related to PCN without having to go 
read all the PCN stuff.

There's still a couple of people who volunteered to review this 
earlier on the hook. I can supply names :)

Once David is happy, I feel this is ready for WGLC. You might want to 
do Security Directorate review in parallel? Up to you.

Cheers

Have a relaxing holdiay season everyone (assuming you can)!

Bob

At 16:15 18/12/2009, [email-masked] wrote:
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-05.txt>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: <[email-masked]>
Date: Fri, 18 Dec 2009 23:09:14 -0500

Bob,

I think this is acceptable.  We are in agreement on the data
path treatment of the bits.  Beyond that, the "MAY" requirement
for raising alarms plus the accompanying discussion of operator
discretion seem reasonable to me.  I appreciate your patience
with the time it's taken to work through these concerns.

Thanks,
--David

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: Friday, December 18, 2009 1:12 PM
> To: Gorry Fairhurst; Black, David
> Cc: [email-masked]
> Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-ecn-tunnel-05.txt
>

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 20 Dec 2009 23:42:33 +0000

David,

Thanks for your quick response. And indeed for your patience on this issue.

Having reached consensus, I'm now going to be a perfectionist and 
change the text you are happy with... hopefully you won't object...

On reflection, I would prefer to use the phrase 'currently unused' 
rather than 'invalid' for combinations that shouldn't arise from any 
combination of RFCs so far defined. This is more precise IETF 
language, because CU implies the combination could become valid in future.

I've also re-read the -05 draft I just posted and noticed some minor 
errors. I am about to post a corrected -06 draft. I will change 
'invalid' to 'currently unused' in the expectation that you will not object.

Cheers

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 21 Dec 2009 09:29:45 +0000

I much prefer the "currently unused" designation.

Gorry

Bob Briscoe wrote:
> Having reached consensus, I'm now going to be a perfectionist and change 
> the text you are happy with... hopefully you won't object...
> 
> combination of RFCs so far defined. This is more precise IETF language, 
> because CU implies the combination could become valid in future.
>

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 09:48:15 -0500

+1

Thanks,
--David

> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Monday, December 21, 2009 4:30 AM
> To: Bob Briscoe
> Cc: Black, David; [email-masked]
change
> > combination of RFCs so far defined. This is more precise IETF
language,
> >> > Subject: Re: [tsvwg] I-D
Action:draft-ietf-tsvwg-ecn-tunnel-05.txt
> >> > >A New Internet-Draft is available from the on-line
Internet-Drafts
> >> > >directories.

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 21 Dec 2009 19:22:42 +0000

David, Gorry,

Thanks for agreement.
As you will have seen, I've posted an -06 rev.

As I rev'd it twice in quick succession, for everyone's convenience, 
diffs from -04 to -06 are here:
<http://www.bobbriscoe.net/projects/ipe2eqos/pcn/papers/draft-ietf-tsvwg-ecn-tunnel-06-04.html>

Bob

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Dec 2009 10:19:37 +0100

----- Original Message -----
From: "Bob Briscoe" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, December 21, 2009 12:42 AM
Subject: Re: [tsvwg] I-D Action:draft-ietf-tsvwg-ecn-tunnel-05.txt

> language, because CU implies the combination could become valid in future.

Probably too late for this one, but if this were to arise in future, I would
suggest
'reserved'
or
'reserved for future use'
an idea shamelessly borrowed from another standards body which
defines this as something to be ignored for now but which may take on
significance later.

Tom Petch

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 29 Dec 2009 23:40:54 +0000

Tom,

IETF use "reserved for future use" too (eg. see RFC2474). It 
generally means the same as Currently Unused.

I prefer CU in this particular case, as we are talking about 
combinations of codepoints in different headers. So, as such, we're 
not really reserving the combinations for future use, they just don't 
happen to be arise in practice, because of the way protocols work at 
the moment.

Cheers

Bob