Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Thu, 08 February 2018 17:53 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340A2126C2F; Thu, 8 Feb 2018 09:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb4elSfqN-yw; Thu, 8 Feb 2018 09:53:51 -0800 (PST)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3BB127078; Thu, 8 Feb 2018 09:53:51 -0800 (PST)
Received: by mail-ot0-x235.google.com with SMTP id a2so5140303otf.2; Thu, 08 Feb 2018 09:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YS0qb84NzRlLAczb/yGFr6sd1Bms3+H9tySfU2MleZk=; b=CNSJJjQQ5HxEb5xG8gHM4bzHRbJWJhsdIkSbp5ru94vdVODVA8s95pm9p9QjJOPone lZnkne4Nt7POruFYgNEa2Mr+Ly9wjkAwTSVHJx8h4qPCX3GmSdY7N2CpbyUU/TQVDPQg pO/f3Dpl1BHMFrpe2MiPYFfCI0b5QE7II3hxzF1X2EoMeoMiSB/xSCLGXw6hj59UPKiR Ptn4UAqRayMOarmeWcBp3bmGvrV8X+UxJ+BBCHsSlojq79pZSxzVCgK3KRwZMSlbGult 35iTu3T9UniVgcmq0sGFem36SVQ4x+87UyWIu9Rm3Q3/MtbB++DaCJvXXoL74Z5Xfgk/ 1+yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YS0qb84NzRlLAczb/yGFr6sd1Bms3+H9tySfU2MleZk=; b=dasiEsE4yAXW0ZqV8ZOOIPR+pzXVPwGamk/6ua0iwlLK3cObXQQCZsK9rIIxeRf/97 cQgIJ6Dee+TVN9K/adDXXlzJtp3VcU2s6LpgnUE8X0zhwM1+XWSJOm81oaLas876XLqP ARz4HalcFHbDaFMY2PkhAIY/xLisJSha0C+EQEvRMglIR6uGRieoKwZgle1e5tbJSzQZ mLUqEicGeSkZx6b6qzUUH6Vxs+E4ZUHXYa7SKCPbwRI6ztSuL8ow1uHCMoBMVXdXiOmx Iw5WypaTP4odWgXU2ryZ6ridjYx3ZfL+ongJ8vnaEC2wE8PHY/XkBNu+IIOuDVcL9ino 7bcQ==
X-Gm-Message-State: APf1xPD4oRdU7jM28V3VNFm0PPHccwQ6J9DpXjjvn764MQXm9MYsg6Mg 4uZbR4rN8ZLRQOQsO7giDNJF5Z/h6rhYQmAUrnw=
X-Google-Smtp-Source: AH8x224Mj6EWfWkudhck05xBXkkxstFVn5a91tKqwTLdUKG/sghp7L6AixLaWhkgbSlzAkxcw+X2uawFfyC05VaVeYg=
X-Received: by 10.157.54.11 with SMTP id w11mr6181otb.334.1518112430547; Thu, 08 Feb 2018 09:53:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.168.67.205 with HTTP; Thu, 8 Feb 2018 09:53:35 -0800 (PST)
In-Reply-To: <151805235597.17192.8686136333532184356.idtracker@ietfa.amsl.com>
References: <151805235597.17192.8686136333532184356.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 8 Feb 2018 12:53:35 -0500
Message-ID: <CAF4+nEGcZF4dNTgKQXbk2NWBFRkYo_E9m0uraaaKU6Nk+hRrQg@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-trill-ecn-support@ietf.org, Susan Hares <shares@ndzh.com>, trill-chairs@ietf.org, trill@ietf.org
Content-Type: multipart/alternative; boundary="001a113f2b8226e9330564b718c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/sbcymEgLzmSkrmYSgmm8GWVLXrE>
Subject: Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 17:53:54 -0000

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach <adam@nostrum.com> wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks to the authors, chairs, shepherd, and working group for the effort
that
> has been put into this document.
>
> I have concerns about some ambiguity and/or self-contradiction in this
> specification, but I suspect these should be easy to fix. In particular,
the
> behavior defined in Table 3 doesn't seem to be consistent with the
behavior
> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>>       +---------+----------------------------------------------+
>>       | Inner   |  Arriving TRILL 3-bit ECN Codepoint Name     |
>>       | Native  +---------+------------+------------+----------+
>>       | Header  | Not-ECT | ECT(0)     | ECT(1)     |     CE   |
>>       +---------+---------+------------+------------+----------+
>>       | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) |  <drop>  |
>>       |  ECT(0) |  ECT(0) |  ECT(0)    |  ECT(1)    |     CE   |
>>       |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)    |     CE   |
>>       |    CE   |      CE |      CE    |      CE(*) |     CE   |
>>       +---------+---------+------------+------------+----------+
>>
>>                      Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a currently unused
>>  combination that SHOULD be logged. In contrast to [RFC6040], in TRILL
>>  the drop condition is the result of a valid combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native header value to the TRILL ECN
>     codepoint (resulting in any of the four values above) or doesn't
insert
>     any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE flag, resulting in "CE" in the
>     table above.
>
> Based on the above, a packet arriving at an egress gateway can only be in
one of
> the following states:
>
>  A. TRILL header is Not-ECT because no TRILL node inserted ECN
information.
>
>  B. TRILL header value == Native header value because the ingress gateway
>     copied it from native to TRILL.
>
>  C. TRILL header is "CE" because an intermediate node indicated
congestion.

Sort of... But note that the TRILL header ECN bit s can indicate non-ECT
while the CCE bit is set making the overall TRILL Header "CE".

> If that's correct, I would think that any state other than those three
needs
> to be marked with an (*). In particular, these two states fall into that
> classification, and seem to require an asterisk:
>
>   - Native==CE && TRILL==ECT(0)
>
>   - Native==ECT(0) && TRILL==ECT(1)

I would defer to my co-author Bob Briscoe but it looks to me like you have
a good point.

> In addition, the behavior this table defines for Native==ECT(0) &&
TRILL==ECT(1)
> is somewhat perplexing: for this case, the value in the TRILL header takes
> precedence; however, when Native==ECT(1) && TRILL==ECT(0) the Native
header
> takes precedence. Or, put another way, this table defines ECT(1) to always
> override ECT(0). I don't find any prose in here to indicate why this
needs to be
> treated differentially, so I'm left to conclude that this is a
typographical
> error. If that's not the case, please add motivating text to Table 3
explaining
> why ECT(1) is treated differently than ECT(0) for baseline ECN behavior.

As noted in Section 4.1, there is an ECN variation where ECT(0) just
indicates ECT while ECT(1) indicates congestion of a lesser severity level
has been encountered than that indicated by CE. I believe the dominance of
ECT(1) over ECT(0) is designed to not interfere with this variation.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I also have a small handful of editorial suggestions and nits to propose.

I am fine with all the changes below .

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> Please expand "TRILL" upon first use and in the title; see
> https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
>
>
---------------------------------------------------------------------------
> §1:
>
>>  In [RFC3168] it was recognized that tunnels and lower layer protocols
>
> "In [RFC3168], it was..."
> (insert comma)
>
>
---------------------------------------------------------------------------
>
> §2:
>
>>  These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN
>
> "...are shown..."
>
>
>>  The CRItE bit is the critical Ingress-to-Egress summary
>>  bit and will be one if and only if any of the bits in the CItE range
>>  (21-26) is one or there is a critical feature invoked in some further
>
> "...if any of the bits... are one or..."
> (replace "is" with "are")
>
>
>>   The first three have the same meaning as the corresponding ECN field
>>   codepoints in the IPv4 or IPv6 header as defined in [RFC3168].
>
> Section 1.1 defines "IP" to mean both IPv4 and IPv6. It would seem
cleaner and
> easier to read if the document were to leverage that definition here.
>
>
>>   However codepoint 0b11 is called Non-Critical Congestion Experienced
>
> "However, codepoint..."
> (insert comma)
>
>
---------------------------------------------------------------------------
>
> §3.3.2:
>
>>  If an RBridge supports ECN, for the two cases of an IP and a non-IPR
>
> "...non-IP"
>
>
---------------------------------------------------------------------------
>
> §4:
>
>>  Section 3 specifies interworking between TRILL and the original
>>  standardized form of ECN in IP [RFC3168].
>
> Please indicate this at the top of Section 3. When I was puzzling over
Table 3,
> I spent some time trying to figure out whether the behavior I describe in
my
> DISCUSS above was due to behavior described in RFC 8311 or the
experiments it
> contemplates.
>
>
---------------------------------------------------------------------------
>
> Appendix A:
>
>>  o  the meaning of CE markings applied by an L4S queue is not the same
>>     as the meaning of a drop by a "Classic" queue (contrary to the
>>     original requirement for ECN [RFC3168]).
>
> I think, when citing this exception, it makes much more sense to point to
RFC
> 8311 (where the exception to RFC 3168's requirement is defined) than to
RFC 3168
> in a vacuum.
>
>>     Instead the likelihood
>
> Insert a comma after "Instead".
>
>>     that the Classic queue drops packets is defined as the square of
>>     the likelihood that the L4S queue marks packets (e.g. when there
>
> Insert a comma after "e.g.,"