Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13)

Bob Briscoe <> Sun, 11 June 2017 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83DA8128BA2; Sun, 11 Jun 2017 13:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9uKBrDUInKdL; Sun, 11 Jun 2017 13:43:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8FE71267BB; Sun, 11 Jun 2017 13:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=id4s83BDlhEIketkszPWWL2cqizZTgtmAfOkLVcz884=; b=5TtinLy5zCqOtSf2eEBBKadI+ /b3oLoSlyYqIaXmeohIKFdy2WKwACJdbhvTE36Mj62Cw1Cft4HxrmtX/q+nIOSoohFd199RAUwL2n qBjJ0W7ZV9rAx743ceRUn4Hcu1eSlKWGxs+5srDX9gRJKmVI8fthujnmBD5Jt5oktmiKLI7qb7rUE 8A5p1tSKANAxr/yulnAWmAsEgRwipB81DsbsoMFyghiBu543RUwdIj/TcKS8Pw2TzDRypeRsxO6a4 KxKqvP0V3S9Vf3fqau0yOgKsyof5KxHOu7U7trMEIxqC/uYhNuOFRJQpXXjF3uywcH+dCBhXupiOm DT/h1ULcQ==;
Received: from ([]:52774 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from <>) id 1dK9hb-0003xL-2R; Sun, 11 Jun 2017 21:43:15 +0100
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <>
Cc: Susan Hares <>, "" <>, "" <>, "" <>, Donald Eastlake <>
References: <01e101d2da3e$8b73b810$a25b2830$> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Sun, 11 Jun 2017 21:43:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------8F0B232D5D9411742DC811AA"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [trill] WG LC for draft-trill-ecn-support-03 (5/31 to 6:13)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Jun 2017 20:43:22 -0000


On 09/06/17 17:33, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
> Hi all,
> I reviewed this draft (for the first time) mainly from the point of view of L4S support. I greatly appreciate the forward vision of supporting upcoming ECN functionality, and the flexibility/extensibility of the thrill headers.
> Answering question 1: Definitely, L4S ECN marking can drastically improve latency and flow control.
> Following comments related to question 2:
> I think there is one opportunity not exploited in how L4S ECN is handled: If an ingress node is not supporting ECN, a transit node is allowed to add the Flags word and mark packets with CCE. In case of L4S this case is not covered, and cannot be applied, as NCCE code points are translated by egress nodes as CE or drop if the inner packet is Not-ECT.
There is a problem in this case, but I don't think you have described it 
well (I think you have described why your solution would not work with 
the spec as it stands, rather than describing what is wrong with the 
spec as it stands).

Here's how I would have described the problem:
The technique in Appendix A for a transit RBridge to support L4S-ECN 
takes different actions depending on the last bit of the trill-ECN 
field, which in turn depends on the trill ingress RBridge having copied 
the IP-ECN field into the trill-ECN field. However, in a case where the 
ingress hasn't, the spec says "a transit RBridge "MAY" add a Flags Word 
itself. But, it would be a layering violation to expect the transit 
RBridge to look for the IP-ECN field and copy it into the trill-ECN field.

The approach in the spec works for standard ECN [RFC3168], i.e. if a 
transit RBridge creates a flags Word it just initializes the trill-ECN 
field to not-ECT. But you're right, this doesn't work for L4S.

I'm not sure how important this is, because no vendor is likely to 
implement creation of a Flags word by a transit RBridge anyway (which is 
why the spec says "MAY").

> I think the solution could be to extent the "Arriving TRILL 3-bit codepoint name" table with an extra NCCE name mapping from TRILL-ECN=11 and CCE=0. Table 2 needs to have an extra column with rows (not-ECT, ECT(0), CE, CE). This way an L4S transit node can also insert a Flags word and set NCCE with probability p on top of CCE with p^2. I saw no other combinations that could lead to this arriving situation, and could lead to problems, as current ECN capable transit nodes never mark NCCE.
I have checked and this works in all cases.

Even if there is a Flags word, this is better for L4S, because L4S 
transit RBridges would not need to read the trill-ECN field before 
marking. So the pseudocode in Appendix A would be simpler, i.e. just:

       % On TRILL transit
       if (p > random() ) {
          mark(NCCE)                     % likelihood: p
          if (p > random() )
             mark(CCE)                   % likelihood: p^2

There is a downside tho: your proposal adds an extra case for the 
behaviour of all trill egress RBridges.

In summary, the tradeoffs with your proposal are:
* More complex standards track behaviour for all egress RBridges.
* Simpler for transit RBridges to support L4S (which is experimental track)
* Makes it possible for transit RBridges that support L4S to add a Flags 
Word (but unlikely that vendors will do this anyway)

Another way to solve this problem would be to just say that an L4S 
transit RBridge:
* MAY create a Flags word, but only if it is willing and able to inspect 
the inner IP header and copy the IP-ECN field to the trill-ECN field.
* Otherwise it has to use Classic drop for packets without a Flags Word.

One thing your email made me notice: as it stands, the pseudocode in 
Appendix A ought to include an outer 'if' block that checks for the 
Flags Word. But let's see what comments there are on the list before 
deciding between the alternatives, then we can write the appropriate 

> A typo in section 2: Extesnion should be Extension.
Thanks for this. While re-reading the draft, I also noticed a few 
editorial improvements, which I will raise with my co-author.

And thanks particularly for pointing out the alternative way of defining 
the egress behaviour.


> Regards,
> Koen.
>> On 31/05/17 19:48, Susan Hares wrote:
>> This begins a  2 week WG LC for draft-ietf-trill-ecn-support which can be
>> found at:
>> The authors (Donald Eastlake and Bob Biscoe) should indicate whether they
>> know of any IPR relating to this draft.
>> The TRILL WG should consider the following questions:
>> 1) Does this extension of the ECN to TRILL Switches provide for better
>> Flow control of IP packets without packet drops?  And is this useful in TRILL
>> deployments?
>> 2) Do you believe this document is ready for RFC publication?
>> Please include the answers to these questions among your comments about
>> this draft.
>> Sue Hares
>> _______________________________________________
>> trill mailing list

Bob Briscoe