Warren: As the shepherd, thank you for your comments and DISCUSS. Part of this discuss appears to be a process discuss on: 1) What you want to see in the shepherd's report 2) How you want to see discussions represented on the mail list.
It is always a pleasure to readjust shepherd's reports to answer the current IESG questions as opposed to the previous year's IESG questions. Shepherd and WG chairs serve to enlighten IESG, and I am glad to provide any details I can for you. Let me provide you the background: 1) 2015 IESG member - So, previous IESG members like to see the mail list comments without any editorializing. Hence, this format 2) Relevant vibrant discussion occurred in face-to-face meetings at IETF meetings. The TRILL WG transition between the INT and RTG WG area and we have been pushing documents through at best possible speed. You will note a steady progression of drafts in the history. Why so lengthy a time? First, the transition of the area required that the RTG-DIR reviews occurred. Until our current Routing ADs revised the RTG-DIR QA review process to be like the OPS-DIR review process, TRILL reviews were simply not being processed. Second, we were getting feedback slowly from other groups. I see interesting feedback from Transport based on the new Transport review system that we may take back to the WG. I am not quite clear on all of Magnus' points - but at least it is substantive reviews. Our previous "no comment" state plus the stall in the review process for 1 year - has a tendency to make WGs stall. As Alia may have mentioned, we are trying to complete all of these drafts and publish these drafts. 3) Finally, we started with 3 companies: Huawei, cisco, and brocade - with pre-standards or standards. Due to business environments, the three companies are now: Huawei, IP-Infusion, and the legacy work in brocade and cisco. So, please let me know what you want in the shepherd's report. If this type of history is useful, I am happy to provide this level of discussion in the shepherd's reports. Or more details on the specific pros/cons of the discussion. 3) updates/news - Again, previous reviews had said this was not useful information. Such statements, is "why include this information?" Tends to make people less interested in including this in the future. Donald Eastlake and other authors who used to include this - stopped putting it in. If you would like the update information as an appendix, we can add it. Thank you for your excellent process questions. Sue Hares -----Original Message----- From: trill [mailto:trill-boun...@ietf.org] On Behalf Of Warren Kumari Sent: Wednesday, July 5, 2017 3:16 PM To: The IESG Cc: draft-ietf-trill-mtu-negotiat...@ietf.org; trill-cha...@ietf.org; sha...@ndzh.com; trill@ietf.org Subject: [trill] 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). [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." _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill