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

From: Bob Briscoe <[email-masked]>
Date: Wed, 22 Jul 2009 18:34:49 +0100

Michael,

At 11:34 22/07/2009, Michael Menth wrote:
>Hi Bob,
>
>comments inline.
>
>Bob Briscoe schrieb:
>>Michael,
>>[snip]
>>>Additional rules regarding the outer ECN field may applied to
>>>support its local reuse. For instance, directly after
>>>encapsulation the ingress tunnel router may re-mark the `00'
>>>codepoint to a typical ingress value and the egress tunnel router
>>>may reset the locally reused ECN field to the neutral `00' just
>>>before decapsulation. This avoids potential alarms.
>>
>>This is correct, but we didn't need 
>>compatibility mode for PCN traffic to do this. 
>>We just needed any tunnel, so I'd rather it was 
>>in normal mode, then it will correctly support 
>>ECN-capable traffic, whether PCN-enabled or not.
>Do you mean first encapsulate PCN packets using 
>normal (or any) mode and then set the PCN-DSCP 
>and ECT(0) by specific PCN ingress functions? 
>That makes sense to me, but must be stated explicitly.

Yes.

>I believe I know what you mean and I am 
>technically with you. So what you want is probably the following, right?
>
>Design Principles for Tunnelling Traffic over 
>Segments with Alternate ECN Semantics
>
>ECN is an end-to-end protocol, but the ECN field 
>can be reused for local purposes under certain 
>conditions. To preserve the end-to-endness of 
>ECN, tunnels may be used to bridge a segment 
>with alternative ECN semantics in order to 
>protect the original ECN field. This can be done 
>using any tunneling mode at the ingress.

...as far as PCN traffic is concerned (I merely 
say this, because non-PCN traffic may well care 
in my first alternative scenario).

>Additional rules regarding the outer ECN field 
>may applied to support its local reuse. That means, directly after
>encapsulation the ingress tunnel router may 
>re-mark the outer ECN field to a typical ingress 
>value and the egress tunnel router resets the 
>locally reused ECN field to the neutral `00' just before decapsulation.

Yup.

Bob

>Regards,
>
>Michael
>
>
>>
>>The text that explained all this was taken out 
>>of the ecn-tunnel draft because I probably 
>>over-generalised it (talking about in-path 
>>load-regulators) when it primarily applied to 
>>PCN (although it could apply to pseudo-wires 
>>too). This fell between two stools (English 
>>idiom for not hitting either of two alternate 
>>targets). The scenario was too PCN-specific and 
>>the text was too abstract. I can't think of a 
>>better place to put an explanation like that, but it ought to be somewhere.
>>
>>
>>Bob
>>
>>
>>
>>
>>>Regards,
>>>
>>>Michael
>>>
>>>
>>>Bob Briscoe schrieb:
>>>>Michael,
>>>>
>>>>Thank you very much for you extensive review. 
>>>>I hope the revised draft (see link in mail to 
>>>>pcn copied below) is much more 
>>>>understandable. I took all your suggestions 
>>>>into account, and wherever you didn't 
>>>>understand it I tried hard to think why and 
>>>>make amends. You were right in every case.
>>>>
>>>>One of your points needs a specific response. 
>>>>Here's my text, your comment and my comment 
>>>>on your comment (pasted from your Word file), 
>>>>then the new text (pasted from the new draft):
>>>>
>>>>" RFC3168 also provided a Limited Functionality mode that turns off ECN
>>>>processing over the scope of the tunnel. [LfII1] This is necessary if the
>>>>ingress does not know whether the tunnel egress supports propagation
>>>>of ECN markings.[LfII2] [RJB3]
>>>>
>>>>[LfII2] <#_msoanchor_2>It’s also useful for 
>>>>tunneling ECN marks in PCN domains. This 
>>>>tunneling rule should remain as a useful option.
>>>>
>>>>[RJB3] <#_msoanchor_3>The new compatibility 
>>>>mode provides the same per-packet behaviour 
>>>>as RFC3168 limited functionality mode. 
>>>>However, it is not a mode of the tunnel, only 
>>>>of the ingress, so I gave it a new name.
>>>>
>>>>PCN's tunnelling of ECN marks is another case 
>>>>again. It doesn't set Not-ECT in the outer 
>>>>header. It resets the ECN field in the outer header to ECT(0).
>>>>
>>>>But this is not an encapsulation behaviour  
>>>>it is a PCN-specific behaviour independent of 
>>>>tunnelling. PCN resets the ECN field whether 
>>>>or not there is a tunnel across the PCN 
>>>>region. If the operator wants to preserve the 
>>>>e2e field, it puts the encap function just 
>>>>before PCN does the reset. This was explained 
>>>>in Appendix B (which has been removed in 
>>>>draft-03 by popular request). A short para about this has been put in S.7).
>>>>"
>>>>
>>>>============================================================================ 
>>>>
>>>>7. Design Principles for Future Non-Default Schemes
>>>>[snip]
>>>>
>>>>1. If it has established that ECN will be correctly propagated, an
>>>>encapsulator should also copy incoming congestion notification
>>>>into the outer header. The general principle here is that the
>>>>outer header should reflect congestion accumulated along the
>>>>whole upstream path, not just since the tunnel ingress (
>>>>Appendix B.3
>>>>
>>>><file:///D:/data/htdocs/projects/ipe2eqos/pcn/papers/draft-ietf-tsvwg-ecn-tunnel-03.html#ecntun_Mgmt_Constraints> 
>>>>
>>>>on management and monitoring explains).
>>>>
>>>>In some circumstances (e.g. pseudowires, PCN), the whole path is
>>>>divided into segments, each with its own congestion notification
>>>>and feedback loop. In these cases, the function that regulates
>>>>load at the start of each segment will need to reset congestion
>>>>notification for its segment. Often the point where congestion
>>>>notification is reset will also be located at the start of a
>>>>tunnel. However, the resetting function should be thought of as
>>>>being applied to packets after the encapsulation functiontwo
>>>>logically separate functions even though they might run on the
>>>>same physical box. Then the code module doing encapsulation can
>>>>keep to the copying rule and the load regulator module can reset
>>>>congestion, without any code in either module being conditional on
>>>>whether the other is there.
>>>>
>>>>
>>>>
>>>>Bob
>>>>
>>>>>Date: Tue, 21 Jul 2009 18:35:22 +0100
>>>>>To: "tsvwg IETF list" <[email-masked]>, "PCN IETF list" <[email-masked]>
>>>>>From: Bob Briscoe <[email-masked]>
>>>>>Subject: draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue
>>>>>
>>>>>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
>>>>
>>>>________________________________________________________________
>>>>Bob Briscoe, Networks Research Centre, BT Research
>>>
>>>--
>>>Dr. Michael Menth, Assistant Professor
>>>University of Wuerzburg, Institute of Computer Science
>>>Am Hubland, D-97074 Wuerzburg, Germany, room B206
>>>phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
>>>mailto:[email-masked]
>>>http://www3.informatik.uni-wuerzburg.de/research/ngn
>>
>>________________________________________________________________
>>Bob Briscoe, Networks Research Centre, BT Research
>
>--
>Dr. Michael Menth, Assistant Professor
>University of Wuerzburg, Institute of Computer Science
>Am Hubland, D-97074 Wuerzburg, Germany, room B206
>phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
>mailto:[email-masked]
>http://www3.informatik.uni-wuerzburg.de/research/ngn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Jul 2009 12:34:06 +0200

Hi Bob,

comments inline.

Bob Briscoe schrieb:
> Michael,
>
> No, this isn't an alternative view, it's different.
>
> I'm trying to avoid needing specially coded PCN-specific tunnel 
> endpoints. I want to be able to use off-the-shelf ecn-tunnel-compliant 
> encapsulator (E) and decapsulator (D) _functions_ that aren't 
> specially coded to know about PCN.
>
> -------E--------------------------------D------->
> \ /
> \PI---------->-------------PE/
> ECN:=ECT(0) ECN:=Not-ECT
>
> Then you can have an arrangement like the above. The PCN ingress (PI) 
> sets or resets the ECN field to ECT(0) and the PCN egress (PE) zeroes 
> it to Not-ECT.
>
> More inline...
>
> At 21:52 21/07/2009, Michael Menth wrote:
>> Hi Bob,
>>
>> thanks for your feedback. Yes, that makes sense to me. I summarized 
>> what I have understood from your Section 7 in my own words. It's a 
>> bit more general as it does not just apply do load regulation. Maybe 
>> this text shows you some alternative view of the same thing ;-)
>>
>> Regards,
>>
>> Michael
>>
>>
>> Design Principles for Tunnelling Schemes over Segments with Local
>> Reuse of the ECN-Field
>
> The aim is that PCN does _not_ require an alternate ECN _tunnelling_ 
> scheme, it just requires alternate ECN _marking_ semantics on interior 
> nodes. The "Don't" advice about alternate ECN tunnelling in ecn-tunnel 
> applies to PCN too.
Yes, PCN does not require its own tunneling scheme, but it needs to 
apply the correct marking to the packets after encapsulation.

>
>
>> ECN is an end-to-end protocol, but the ECN field can be reused for
>> local purposes under certain conditions. To preserve the
>> End-to-endness of ECN, tunnels may be used to bridge a segment
>> with alternative ECN semantics in order to protect the original
>> ECN field. This can be done using the [compatibility mode] which
>> sets the ECN field in the outer header to `00' upon encapsulation
>
> Why? As you say below, we want it eventually set to a non-zero value, 
> typically ECT(0), at the PCN ingress.

>
>> and ignores the ECN field in the outer header upon decapsulation.
>
> Note: an off-the-shelf egress compliant with ecn-tunnel doesn't have 
> modes. If you want an ecn-tunnel egress (or any legacy egress for that 
> matter) to ignore the outer, it's safest to clear the outer to 00 just 
> before the decapsulator, then the decapsulation rules will behave as 
> if the egress is ignoring the outer.
That makes sense and is fine with me.

> This is correct, but we didn't need compatibility mode for PCN traffic 
> to do this. We just needed any tunnel, so I'd rather it was in normal 
> mode, then it will correctly support ECN-capable traffic, whether 
> PCN-enabled or not.
Do you mean first encapsulate PCN packets using normal (or any) mode and 
then set the PCN-DSCP and ECT(0) by specific PCN ingress functions? That 
makes sense to me, but must be stated explicitly.

>
> One idea (drawn above) is to use normal mode for the encapsulator 
> _function_ for _all_ traffic, without having to configure it to know 
> what is PCN traffic and what isn't. 
> Otherwise the encapsulation function has to be in compatibility mode 
> for PCN-enabled traffic and normal mode for non-PCN-enabled traffic.
>
> Alternatively (and better), a PCN ingress could encapsulate (in the 
> software sense, not the tunnelling sense) off-the-shelf encapsulation 
> code (drawn below). This would be the only way to avoid tunnelling 
> non-PCN-enabled traffic unnecessarily. I actually prefer this, as a 
> PCN ingress will always need to know the address of the egress for 
> PCN-enabled traffic, but it shouldn't have to for non-PCN-enabled 
> traffic, which doesn't need to be tunnelled.
>
> +--------------------->---------------------+
> ..........|.............. not tunnelled |
> : PCN- N : |
> :enabled?/\ :tunnelled |
> -:-------- -Y----E-------------->-----------------D---+---->
> : \/ \ : /
> : \------------>-------------PE/
> : ECN:=ECT(0): ECN:=Not-ECT
> :.......................:
> PCN-ingress (PI)
>
> The first alternative makes sense if you're already tunnelling 
> everything across the domain (e.g. probably using MPLS or Ethernet but 
> it could be IP). The second alternative makes sense if only PCN needs 
> to determine the egress address to tunnel to.
I believe I know what you mean and I am technically with you. So what 
you want is probably the following, right?

Design Principles for Tunnelling Traffic over Segments with Alternate 
ECN Semantics

ECN is an end-to-end protocol, but the ECN field can be reused for local 
purposes under certain conditions. To preserve the end-to-endness of 
ECN, tunnels may be used to bridge a segment with alternative ECN 
semantics in order to protect the original ECN field. This can be done 
using any tunneling mode at the ingress.
Additional rules regarding the outer ECN field may applied to support 
its local reuse. That means, directly after
encapsulation the ingress tunnel router may re-mark the outer ECN field 
to a typical ingress value and the egress tunnel router resets the 
locally reused ECN field to the neutral `00' just before decapsulation.

Regards,

Michael

>
> The text that explained all this was taken out of the ecn-tunnel draft 
> because I probably over-generalised it (talking about in-path 
> load-regulators) when it primarily applied to PCN (although it could 
> apply to pseudo-wires too). This fell between two stools (English 
> idiom for not hitting either of two alternate targets). The scenario 
> was too PCN-specific and the text was too abstract. I can't think of a 
>>> Thank you very much for you extensive review. I hope the revised 
>>> draft (see link in mail to pcn copied below) is much more 
>>> understandable. I took all your suggestions into account, and 
>>> wherever you didn't understand it I tried hard to think why and make 
>>> amends. You were right in every case.
>>>
>>> One of your points needs a specific response. Here's my text, your 
>>> comment and my comment on your comment (pasted from your Word file), 
>>> [LfII2] <#_msoanchor_2>It’s also useful for tunneling ECN marks in 
>>> PCN domains. This tunneling rule should remain as a useful option.
>>>
>>> [RJB3] <#_msoanchor_3>The new compatibility mode provides the same 
>>> per-packet behaviour as RFC3168 limited functionality mode. However, 
>>> it is not a mode of the tunnel, only of the ingress, so I gave it a 
>>> new name.
>>>
>>> PCN's tunnelling of ECN marks is another case again. It doesn't set 
>>> Not-ECT in the outer header. It resets the ECN field in the outer 
>>> header to ECT(0).
>>>
>>> But this is not an encapsulation behaviour  it is a PCN-specific 
>>> behaviour independent of tunnelling. PCN resets the ECN field 
>>> whether or not there is a tunnel across the PCN region. If the 
>>> operator wants to preserve the e2e field, it puts the encap function 
>>> just before PCN does the reset. This was explained in Appendix B 
>>> (which has been removed in draft-03 by popular request). A short 
>>> para about this has been put in S.7).
>>> "
>>>
>>>> I've revised draft-ietf-tsvwg-ecn-tunnel to -03 after extensive 
>>>> review comments. Thanks for the deep reviews from Gorry Fairhurst, 
>>>> 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:
>>>> 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