Hi Bob, All your changes look good to me.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Sat, Feb 3, 2018 at 8:31 PM, Bob Briscoe <[email protected]> wrote: > Sue, > > Thanks for the editorial suggestions. > Donald, I'm happy with Sue's specific suggestions if you are. > > Responses inline... > > On 22/01/18 15:18, Susan Hares wrote: > > As part of the shepherd’s duties, I’ve review > draft-ietf-trill-ecn-support-04.txt to determine if it is ready for > publication. > > > > Status: Ready with editorial nits > > > > General comment: I’m thrilled to see an RBridge specification enacting aids > for advanced congestion control mechanisms. > > What I’ve checked: normative references including > draft-ietf-twvwg-enc-encap-guidelines-01/txt > > BTW, it's currently -09, not -01. > > I suggest the following changes to each occurrence of a citation of > [ECNencapGuide]: > > 1. Introduction > <No change to both citations, which are to the whole of [ECNencapGuide] in > general> > > 3. ECN Support > > CURRENT: > > ... which correspond to the recommended provisions of > [ECNencapGuide]. > > > SUGGESTED: > > ... which correspond to the recommended provisions in section 3 and > sections 5.1-5.4 of > [ECNencapGuide]. > > > 3.1. Ingress ECN Support > > CURRENT: > > ... it MUST follow the guidelines in [ECNencapGuide] > to add a Flags Word to the TRILL Header. > > > SUGGESTED: > > ... it MUST follow the guidelines in Section 5.3 of [ECNencapGuide] > to add a Flags Word to the TRILL Header. > > > 3.3 Egress ECN Support > > CURRENT: > > Drop is the intended behavior for such a packet, as required by > [ECNencapGuide]. > > > SUGGESTED: > > Drop is the intended behavior for such a packet, as required by Section > 5.4 of > [ECNencapGuide]. > > > CURRENT: > > o When decapsulating a non-IP protocol frame with a means of > indicating ECN that is understood by the RBridge, it MUST follow > the guideines in [ECNencapGuide] when setting the ECN information > in the decapsulated native frame. > > > SUGGESTED: > > o When decapsulating a non-IP protocol frame with a means of > indicating ECN that is understood by the RBridge, it MUST follow > the guideines in Section 5.4 of [ECNencapGuide] when setting the ECN > information > in the decapsulated native frame. > > > > > > Editorial nits are below. You can adopt or ignore the editorial nits. > > > > Sue Hares > > =========== > > > > Editorial nits: > > > > General – it may be helpful to specify section in the [ECNencapGuide] – > document, and RFC7567. While the way you specify it is correct, it may help > the reader to narrow down the scope within the document. > > > > #1 > > Explicit congestion notification (ECN [RFC3168]) allows a forwarding > > element, such as a router, to notify downstream devices, including > > the destination, of the onset of congestion without having to drop > > packets. > > > > The multiple commons in this sentence do not lend to easy reading of the > initial sentence. > > One alternative is: > > > > Explicit congestion notification (ECN [RFC3168]) allows a forwarding > > Element (such as a router) to notify downstream devices, including > > the destination, of the onset of congestion without having to drop > > packets. > > > > However you may wish to revise the sentence in an alternative way. > > > > > > #2 – Section 2. Paragraph 2. Sentences 4 > > Old/Extesnion Flags Word./ > > New/Extension Flags Word./ > > > > > > #3 – Section 3.3 is dense and thoughtful text. I am not sure you can > improve it, but it too me several reads to make sure I understood it > correctly. > > > > I think it might help if we created two subsections within 3.3 for: > 3.3.1: "Non-ECN Egress RBridge" the first para > 3.3.2: "ECN Egress RBridge" for the rest of the section > > Also, it might make it clearer if the two bullets were explicitly flagged as > mutually exclusive alternatives: > > CURRENT: > > If an RBridge supports ECN, the egress behavior is as follows: > > SUGGESTED: > > If an RBridge supports ECN, for the two cases of an IP and a non-IP inner > packet, > the egress behavior is as follows: > > > Then, instead of the two bullet symbols, perhaps use hanging indented > headers: > > Decapsulating an inner IP packet: The RBridge sets the ECN > ... > Decapsulating a non-IP protocol frame: If the frame has a means of > indicating ECN that is understood by the RBridge, the RBridge MUST > follow > ... > > > > Other suggested edits to make the going easier: > > CURRENT: > > In the case where the TRILL 3-bit ECN codepoint indicates > congestion experienced (CE) but the encapsulated native IP frame > indicates a not ECN-capable transport (Not-ECT), the RBridge MUST > drop the packet. > > > SUGGESTED: > > In the case where the TRILL 3-bit ECN codepoint indicates > congestion experienced (CE) but the encapsulated native IP frame > indicates a not ECN-capable transport (Not-ECT), it can be seen that > the RBridge MUST > drop the packet. > > RATIONALE: > To reassure the reader that this req't is already described in the table; it > is not an additional req't. > > HTH > > > > Bob > > > > > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
