Hi Warren, Thanks for the comments. Please see responses inline below.
________________________________________ From: Warren Kumari [war...@kumari.net] Sent: Thursday, July 06, 2017 3:15 To: The IESG Cc: draft-ietf-trill-mtu-negotiat...@ietf.org; trill-cha...@ietf.org; sha...@ndzh.com; trill@ietf.org Subject: Warren Kumari's Discuss on draft-ietf-trill-mtu-negotiation-06: (with DISCUSS and COMMENT) 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). [Mingui] The last paragarph of the introdution and the item 2)-b) of Section 4 do discuss the updates. [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? [Mingui] OK. The "campus-wide" will be dropped. 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." [Mingui] Right. Will be updated as such. "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"? [Mingui] The latter option looks better. 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 [Mingui] OK. 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. [Mingui] Right. 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." [Mingui] Correct. 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). [Mingui] Right. 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. [Mingui] Correct. 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. [Mingui] Right. 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. [Mingui] Will replace "MUST" with "can". 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. [Mingui] Right. 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. [Mingui] Yes. "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." [Mingui] OK. Thanks, Mingui _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
