Subject: Re: [PCN] draft-ietf-tsvwg-ecn-tunnel-03 and tunnelling PCN

From: Bob Briscoe <[email-masked]>
Date: Wed, 22 Jul 2009 11:25:20 +0100

Michael,

I've added the PCN list to the distr as agreed.

[PCN folks, this is an off-list thread that we 
agreed would be useful on-list. I think the 
context can be understood by starting at the 
bottom - I've digested it a bit to help.]

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 ;-)

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...

>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.

>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.

>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.

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.

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. This is necessary if the
>>ingress does not know whether the tunnel egress supports propagation
>>of ECN markings.[LfII2] [RJB3]
>>
>>[LfII2] It’s also useful for tunneling ECN 
>>marks in PCN domains. This tunneling rule should remain as a useful option.
>>
>>[RJB3] 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 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>

[snip]

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research