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/
_______________________________________________
trill mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trill
