[trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT)

Warren Kumari <warren@kumari.net> Wed, 05 July 2017 19:15 UTC

Return-Path: <warren@kumari.net>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B081205F0; Wed, 5 Jul 2017 12:15:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari <warren@kumari.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-trill-mtu-negotiation@ietf.org, trill-chairs@ietf.org, shares@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149928214838.19397.15366425287313778494.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jul 2017 12:15:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/cdM3PWrdQTLKL5s8IeSXq3K5-NA>
Subject: [trill] Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 05 Jul 2017 19:15:48 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-trill-mtu-negotiation-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-mtu-negotiation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1: Instead of answering the questions, the Shepherd Writeup just has links to
things - for example:

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

WG LC:
Passed:
https://www.ietf.org/mail-archive/web/trill/current/msg07304.html
Discussion:
https://www.ietf.org/mail-archive/web/trill/current/msg07210.html

This caused me to go investigate further - it seems that there were only 4
comments received during WGLC (excluding the RtgDir review, a short exchange
with Julien Meuric). The comments which *were* received largely just fell into
the "Support" (with no real discussion) category.

The document was adopted 06 March 2015, and then there were a few automated
mentions of it (e.g [0], [1]), but I see no real discussion of the draft *in
the WG*.

It is entirely possible that my search fu is weak today, and that there has
been sufficient discussion and review of the draft (or that none was needed
because it is so obviously right and pure, but I'd like some reassurance of
that), especially because a quick review found multiple readability issues /
nits.

Note: I'm not holding the discuss on the readability / nits, rather on has the
process been followed / is there consensus grounds

2: The document also says that it Updates: 6325, 7177, 7780 - but I don't see
clear discussion of the Updates (OLD / NEW).

[0]: https://mailarchive.ietf.org/arch/msg/rtg-dir/c863sUajt86YB_d62uWfF5Hd_X4
[1]:
https://mailarchive.ietf.org/arch/msg/i-d-announce/p5ROVvvoU0B3S1OA2SY3vebX_b4


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Major:
I found much of the document really hard to read - I approve of the concept /
see the need for this, but reading the document itself is not well written.

Nits:

General
RFC 6325 says:
"4.3.1.  Determining Campus-Wide TRILL IS-IS MTU Size

   In a stable campus, there must ultimately be agreement among all
   RBridges on the value of "Sz", the minimum acceptable inter-RBridge
   link size for the campus, for the proper operation of TRILL IS-IS."
and this document says:
"[RFC6325] describes the way RBridges agree on the campus-wide minimum
   acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the
   campus-wide "Sz" "
Ok, so Sz is campus-wide -- but, for some reason this document has ~35
instances of "campus-wide Sz" - can you just drop the "campus-wide"? Is there
any time the Sz would not be campus-wide?

Section 1.
"[RFC6325] describes the way RBridges agree on the campus-wide minimum
   acceptable inter-RBridge MTU (Maximum Transmission Unit) size - the
   campus-wide "Sz" to ensure that link state flooding operates properly
   and all RBridges converge to the same link state."
This is really hard to parse - the bit before the hyphen is fine, but then it
gets muddled. Perhaps: "[RFC6325] describes the way RBridges agree on the
campus-wide minimum
   acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz")
   to ensure that link state flooding operates properly and all RBridges
   converge to the same link state."

"By calculating and using Lz
   as specified herein, link-scoped PDUs can be formatted greater than
   the campus-wide Sz up to the link-wide minimum acceptable inter-
   RBridge MTU size potentially improving the efficiency of link
   utilization and speeding link state convergence."
"formatted" seems clumsy - perhaps just drop it? Or reorder to be "link-scoped
PDUs larger than Sz, up to ...  can be used"?

O: "The new MTU size testing method specified in this document is backward
compatible to the old one." P: "The new MTU size testing method specified in
this document is backward compatible with the old one." C: Grammar

O: "Link-wide Lz is the minimum Lz supported and agreed between all RBridges on
a specific link." P: "Link-wide Lz is the minimum Lz supported and agreed
amongst all RBridges on a specific link." C: Between only if two.

Section 2. Link-Wide TRILL MTU Size
O: "These PDUs are exchanged just on the local link."
P: "These PDUs are exchanged only on the local link."

O: "They use that flooding to exchange their maximally supportable value of
"Lz"." P: "They use that flooding to exchange their maximum supported value of
"Lz"." C: Maximally would be an adverb, describing the process of maximizing
the flooding (or something).

Section 2.1:
O: "Lz MAY be reported using a originatingSNPBufferSize TLV that occurs"
P:  "Lz MAY be reported using an originatingSNPBufferSize TLV that occurs"
C: I think.

O: "If RB2 sends PDUs formatted in chunk of size 1800, it will be discarded by
B1." P: "If RB2 sends PDUs formatted in chunks of size 1800, they will be
discarded by B1." C: chunks is plural.

Section 6:
"The CSNPs and PSNPs MUST be formatted in chunks of size at most the
   link-wide Lz but are processed normally if received larger than that
   size." -- why the MUST? Is this supposed to be an instance of the sender
   being conservative and the receiver liberal? It so, I think it would be
   better to be much clearer.

Section 7:
O: "Unlike RBridges, end stations do not participate in the exchange of
   TRILL IS-IS PDUs, therefore they cannot grasp the traffic link MTU
   size from a TRILL campus automatically. "
C: should be a semicolon and not a comma before therefore, and a comma after
therefore.

Section 8. Backwards Compatibility
O: "This will act properly although it may not be as efficient as  it would be
if all RBridges on the link are Lz-aware." P: "This will act properly although,
it may not be as efficient as  it would be if all RBridges on the link are
Lz-aware." C: Missing comma.

"Then the path MTU can be set as the smallest tested link
MTU on this path and end stations should not generate frames that,
when encapsulated as TRILL Data packets, exceed this path MTU."
-- instead:
"Then, the path MTU can be set as the smallest tested link MTU on this path;
and end stations should not generate frames that, when encapsulated as TRILL
Data packets, exceed this path MTU."