Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item

[Bob Briscoe <[e-mail]>]

Dimitri,

At 10:24 17/01/2007, [e-mail] wrote:
>On Nov 14, 2006, at 6:07 PM, [e-mail] wrote:
>
>[dp] the same section 7 mentions
>
>"[RFC3168] does not give any reasons against conveying CE information
>  from the inner header to the outer in the "full functionality" mode."
>
>nor the other way around - which leaves the point open for ECN itself
>-> the issue i am raising is that in absence of evidence current the
>processing should be left per RFC3168 and not inline with the expected
>PCN needs (even if it does not affect the former)

You are right to be concerned about the motivation for copying ECN CE 
information from the inner header to the outer at ingress of an MPLS region 
when this conflicts with RFC3168, which says CE should be reset to zero in 
the outer header for IP in IP tunneling. But I think your concern can be 
alleviated by updating you on information given by David Black in the 
IETF-66 TSVWG mtg, but not repeated (yet) on the list (AFAI recall).

There's only a brief mention in the minutes:
"David Black comment: copying 3168 header to outer header is fine"
<http://tools.ietf.org/wg/tsvwg/minutes?item=minutes66.html>
But below, I'll try to reconstruct what he said (David, pls correct if nec):

David (one of the original authors of RFC3168 on ECN) said that the text in 
RFC3168 about re-setting ECN CE can and should now be updated to mandate 
copying instead. The recent update to IPSec tunneling RFC now mandates 
copying the ECN field from inner to outer, not resetting it. David said the 
original text in RFC3168 was solely designed to satisfy the security 
community who thought there /might/ be concerns about information leakage. 
Now they have thought about it thoroughly, they are happy that copying CE 
is safe. According to David all implementations of IP in IP tunneling copy 
the ECN field anyway, though I don't recall how authoratative his survey was.

So what you see in this ECN-MPLS draft is compatible with what RFC3168 
/should/ now say.

I'll leave the ADs & WG chairs to advise on whether this draft would have 
to wait for an update to RFC3168 before it can go to RFC, but I assume not, 
given we should be able to repeat whatever process trick must have been 
used to get IPsec to contradict RFC3168.

Alternatively, there should be no problem doing a focused update to RFC3168 
in parallel, as long as we are strict about not opening other cans of worms 
at the same time, given 3168 is a long and complicated RFC.

We should explain this new situation in the next version of the draft. With 
this rider, are you now OK for this I-D to go to WG status?


Bob




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