Subject: Re: [trill] Shepherd's report on draft-ietf-trill-ecn-support-04

From: Bob Briscoe <[email-masked]>
Date: Sun, 4 Feb 2018 01:31:40 +0000

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 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>].

SUGGESTED:

    ... which correspond to the recommended provisions in section 3 and sections 5.1-5.4 of
    [ECNencapGuide 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>].

3.1. Ingress ECN Support

CURRENT:

       ... it MUST follow the guidelines in [ECNencapGuide 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>]
       to add a Flags Word to the TRILL Header.

SUGGESTED:

       ... it MUST follow the guidelines in Section 5.3 of [ECNencapGuide 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-ECNencapGuide>].

SUGGESTED:

    Drop is the intended behavior for such a packet, as required by Section 5.4 of
    [ECNencapGuide 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 
<https://tools.ietf.org/html/draft-ietf-trill-ecn-support-04#ref-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 
> <https://tools.ietf.org/html/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 
> <https://tools.ietf.org/html/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/

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 4 Feb 2018 23:59:16 -0500

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-masked]

On Sat, Feb 3, 2018 at 8:31 PM, Bob Briscoe <[email-masked]> wrote:
> General comment:  I’m thrilled to see an RBridge specification enacting aids
> for advanced congestion control mechanisms.
>
> <No change to both citations, which are to the whole of [ECNencapGuide] in
> general>
>
> 3. ECN Support
>
> CURRENT:
>
>    [ECNencapGuide].
>    [ECNencapGuide].
>       ... it MUST follow the guidelines in [ECNencapGuide]
>       ... it MUST follow the guidelines in Section 5.3 of [ECNencapGuide]
>    [ECNencapGuide].
>    [ECNencapGuide].
>       the guideines in [ECNencapGuide] when setting the ECN information
>       the guideines in Section 5.4 of [ECNencapGuide] when setting the ECN
> information
> 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
>
> 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
>
> Also, it might make it clearer if the two bullets were explicitly flagged as
> mutually exclusive alternatives:
>
> CURRENT:
>
> To reassure the reader that this req't is already described in the table; it
> is not an additional req't.
>
> HTH
>
>
>
> Bob
>
>
>
>
>
>
>
> --