Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Adam Roach]

Thanks! The changes look great, and I believe that all of my comments 
have been addressed.


/a

On 2/25/18 4:44 PM, Donald Eastlake wrote:

Hi Adam,

The just posted revision -07 is believed to resolve your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com 

On Fri, Feb 23, 2018 at 6:57 PM, Bob Briscoe > wrote:


@Adam, Thx for your patience. (It turned out I didn't see your
DISCUSS cos I had created a bug in my own e-mail filters - sry for
that).

@Donald (as editor), Adam's right that we risk implementers doing
their own thing if they judge that Table 3 might be wrong, because
its apparent illogicality is not explained without reading the
references. So, I've suggested one further change to text, inline...



On 20/02/18 22:22, Adam Roach wrote:

Bob --

Thanks for taking the time to explain the history and rationale
of Table 3 to me. I'm going to clear my DISCUSS based on this
explanation, since it seems that the technical solution in the
document is correct, if a bit non-obvious. Some additional
comments inline.

[For those of you who did not see Bob's response: it appears that
my original DISCUSS email did not reach him,  so he replied to a
reduced audience. I have restored the traditional IESG review
distribution to this email. For this reason, I am eliding less of
Bob's response than I usually would]

On 2/20/18 12:51 PM, Bob Briscoe wrote:




On Thu, Feb 8, 2018 at 2:15 PM, Adam Roach
mailto:a...@nostrum.com>> wrote:

On 2/8/18 11:53 AM, Donald Eastlake wrote:

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach
mailto:a...@nostrum.com>> wrote:
> Adam Roach has entered the following ballot
position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
>

--
> DISCUSS:
>

--
>
> Thanks to the authors, chairs, shepherd, and
working group for the effort that
> has been put into this document.
>
> I have concerns about some ambiguity and/or
self-contradiction in this
> specification, but I suspect these should be
easy to fix. In particular, the
> behavior defined in Table 3 doesn't seem to be
consistent with the behavior
> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>>
+-+--+
>> | Inner   |  Arriving TRILL 3-bit ECN
Codepoint Name     |
>> | Native
 +-+++--+
>> | Header  | Not-ECT | ECT(0)     | ECT(1)    
|   CE   |
>>
+-+-+++--+
>> | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*)
|    |
>> |  ECT(0) |  ECT(0) |  ECT(0)    |  ECT(1)  
 |   CE   |
>> |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)  
 |   CE   |
>> |    CE   |    CE |  CE    |  CE(*) | CE   |
>>
+-+-+++--+
>>
>>  Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a
currently unused
>>  combination that SHOULD be logged. In
contrast to [RFC6040], in TRILL
>>  the drop condition is the result of a valid
combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native
header value to the TRILL ECN
> codepoint (resulting in any of the four values
above) or doesn't insert
>     any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE
flag, resulting in "CE" in the
>     table above.
>
> Based on the above, a packet arriving at an
egres

Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Adam,

The just posted revision -07 is believed to resolve your comments.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

On Fri, Feb 23, 2018 at 6:57 PM, Bob Briscoe  wrote:

> @Adam, Thx for your patience. (It turned out I didn't see your DISCUSS cos
> I had created a bug in my own e-mail filters - sry for that).
>
> @Donald (as editor), Adam's right that we risk implementers doing their
> own thing if they judge that Table 3 might be wrong, because its apparent
> illogicality is not explained without reading the references. So, I've
> suggested one further change to text, inline...
>
>
>
> On 20/02/18 22:22, Adam Roach wrote:
>
> Bob --
>
> Thanks for taking the time to explain the history and rationale of Table 3
> to me. I'm going to clear my DISCUSS based on this explanation, since it
> seems that the technical solution in the document is correct, if a bit
> non-obvious. Some additional comments inline.
>
> [For those of you who did not see Bob's response: it appears that my
> original DISCUSS email did not reach him,  so he replied to a reduced
> audience. I have restored the traditional IESG review distribution to this
> email. For this reason, I am eliding less of Bob's response than I usually
> would]
>
> On 2/20/18 12:51 PM, Bob Briscoe wrote:
>
>
>
>>> On Thu, Feb 8, 2018 at 2:15 PM, Adam Roach  wrote:
>>>
 On 2/8/18 11:53 AM, Donald Eastlake wrote:

 Hi Adam,

 On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach  wrote:
 > Adam Roach has entered the following ballot position for
 > draft-ietf-trill-ecn-support-05: Discuss
 >
 > ...
 >
 > 
 --
 > DISCUSS:
 > 
 --
 >
 > Thanks to the authors, chairs, shepherd, and working group for the
 effort that
 > has been put into this document.
 >
 > I have concerns about some ambiguity and/or self-contradiction in this
 > specification, but I suspect these should be easy to fix. In
 particular, the
 > behavior defined in Table 3 doesn't seem to be consistent with the
 behavior
 > described in the prose.
 >
 > For easy reference, I've copied Table 3 here:
 >
 >>   +-+--+
 >>   | Inner   |  Arriving TRILL 3-bit ECN Codepoint Name |
 >>   | Native  +-+++--+
 >>   | Header  | Not-ECT | ECT(0) | ECT(1) | CE   |
 >>   +-+-+++--+
 >>   | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) ||
 >>   |  ECT(0) |  ECT(0) |  ECT(0)|  ECT(1)| CE   |
 >>   |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)| CE   |
 >>   |CE   |  CE |  CE|  CE(*) | CE   |
 >>   +-+-+++--+
 >>
 >>  Table 3. Egress ECN Behavior
 >>
 >>  An asterisk in the above table indicates a currently unused
 >>  combination that SHOULD be logged. In contrast to [RFC6040], in
 TRILL
 >>  the drop condition is the result of a valid combination of events
 and
 >>  need not be logged.
 >
 > The prose in this document indicates:
 >
 >  1. Ingress gateway either copies the native header value to the
 TRILL ECN
 > codepoint (resulting in any of the four values above) or doesn't
 insert
 > any ECN information in the TRILL header.
 >
 >  2. Intermediate gateways can set the CCE flag, resulting in "CE" in
 the
 > table above.
 >
 > Based on the above, a packet arriving at an egress gateway can only
 be in one of
 > the following states:
 >
 >  A. TRILL header is Not-ECT because no TRILL node inserted ECN
 information.
 >
 >  B. TRILL header value == Native header value because the ingress
 gateway
 > copied it from native to TRILL.
 >
 >  C. TRILL header is "CE" because an intermediate node indicated
 congestion.

 Sort of... But note that the TRILL header ECN bit s can indicate
 non-ECT while the CCE bit is set making the overall TRILL Header "CE".


 Right. That's part of case C. My states above assume application of
 Table 2 has already taken place.


 > If that's correct, I would think that any state other than those
 three needs
 > to be marked with an (*). In particular, these two states fall into
 that
 > classification, and seem to require an asterisk:

 [BB] These states are not tagged (*) cos they can arise with variants
> of ECN marking behaviour referred to in Section 4 (explained beneath each
> bullet b

Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Bob Briscoe]

@Adam, Thx for your patience. (It turned out I didn't see your DISCUSS 
cos I had created a bug in my own e-mail filters - sry for that).


@Donald (as editor), Adam's right that we risk implementers doing their 
own thing if they judge that Table 3 might be wrong, because its 
apparent illogicality is not explained without reading the references. 
So, I've suggested one further change to text, inline...



On 20/02/18 22:22, Adam Roach wrote:

Bob --

Thanks for taking the time to explain the history and rationale of 
Table 3 to me. I'm going to clear my DISCUSS based on this 
explanation, since it seems that the technical solution in the 
document is correct, if a bit non-obvious. Some additional comments 
inline.


[For those of you who did not see Bob's response: it appears that my 
original DISCUSS email did not reach him,  so he replied to a reduced 
audience. I have restored the traditional IESG review distribution to 
this email. For this reason, I am eliding less of Bob's response than 
I usually would]


On 2/20/18 12:51 PM, Bob Briscoe wrote:




On Thu, Feb 8, 2018 at 2:15 PM, Adam Roach
mailto:a...@nostrum.com>> wrote:

On 2/8/18 11:53 AM, Donald Eastlake wrote:

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach
mailto:a...@nostrum.com>> wrote:
> Adam Roach has entered the following ballot
position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
>

--
> DISCUSS:
>

--
>
> Thanks to the authors, chairs, shepherd, and
working group for the effort that
> has been put into this document.
>
> I have concerns about some ambiguity and/or
self-contradiction in this
> specification, but I suspect these should be easy
to fix. In particular, the
> behavior defined in Table 3 doesn't seem to be
consistent with the behavior
> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>>
+-+--+
>>       | Inner   |  Arriving TRILL 3-bit ECN
Codepoint Name   |
>>       | Native
 +-+++--+
>>       | Header  | Not-ECT | ECT(0)     | ECT(1) |
    CE   |
>>
+-+-+++--+
>>       | Not-ECT | Not-ECT | Not-ECT(*) |
Not-ECT(*) |    |
>>       |  ECT(0) |  ECT(0) |  ECT(0)    |  ECT(1)  
 | CE   |
>>       |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)  
 | CE   |
>>       |    CE   |  CE |      CE  |      CE(*) |  
  CE   |
>>
+-+-+++--+
>>
>>  Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a
currently unused
>>  combination that SHOULD be logged. In contrast to
[RFC6040], in TRILL
>>  the drop condition is the result of a valid
combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native header
value to the TRILL ECN
>     codepoint (resulting in any of the four values
above) or doesn't insert
>     any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE flag,
resulting in "CE" in the
>     table above.
>
> Based on the above, a packet arriving at an egress
gateway can only be in one of
> the following states:
>
>  A. TRILL header is Not-ECT because no TRILL node
inserted ECN information.
>
>  B. TRILL header value == Native header value
because the ingress gateway
>     copied it from native to TRILL.
>
>  C. TRILL header is "CE" because an intermediate
node indicated congestion.

Sort of... But note that the TRILL header ECN bit s
can indicate non-ECT while the CCE bit is set making
the overall TRILL Header "CE".


Right. That's part of case C. My states above assume
application of Table 2 has already taken place.



> If that's correc

Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Adam Roach]

Bob --

Thanks for taking the time to explain the history and rationale of Table 
3 to me. I'm going to clear my DISCUSS based on this explanation, since 
it seems that the technical solution in the document is correct, if a 
bit non-obvious. Some additional comments inline.


[For those of you who did not see Bob's response: it appears that my 
original DISCUSS email did not reach him,  so he replied to a reduced 
audience. I have restored the traditional IESG review distribution to 
this email. For this reason, I am eliding less of Bob's response than I 
usually would]


On 2/20/18 12:51 PM, Bob Briscoe wrote:




On Thu, Feb 8, 2018 at 2:15 PM, Adam Roach
mailto:a...@nostrum.com>> wrote:

On 2/8/18 11:53 AM, Donald Eastlake wrote:

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach
mailto:a...@nostrum.com>> wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
>

--
> DISCUSS:
>

--
>
> Thanks to the authors, chairs, shepherd, and working
group for the effort that
> has been put into this document.
>
> I have concerns about some ambiguity and/or
self-contradiction in this
> specification, but I suspect these should be easy to
fix. In particular, the
> behavior defined in Table 3 doesn't seem to be
consistent with the behavior
> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>>
+-+--+
>>       | Inner   |  Arriving TRILL 3-bit ECN
Codepoint Name |
>>       | Native
 +-+++--+
>>       | Header  | Not-ECT | ECT(0)     | ECT(1)    
| CE   |
>>
+-+-+++--+
>>       | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*)
|    |
>>       |  ECT(0) |  ECT(0) |  ECT(0)    |  ECT(1)  
 | CE   |
>>       |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)  
 | CE   |
>>       |  CE   |      CE |      CE    |  CE(*) |    
CE |
>>
+-+-+++--+
>>
>>            Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a
currently unused
>>  combination that SHOULD be logged. In contrast to
[RFC6040], in TRILL
>>  the drop condition is the result of a valid
combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native header
value to the TRILL ECN
>     codepoint (resulting in any of the four values
above) or doesn't insert
>     any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE flag,
resulting in "CE" in the
>     table above.
>
> Based on the above, a packet arriving at an egress
gateway can only be in one of
> the following states:
>
>  A. TRILL header is Not-ECT because no TRILL node
inserted ECN information.
>
>  B. TRILL header value == Native header value
because the ingress gateway
>     copied it from native to TRILL.
>
>  C. TRILL header is "CE" because an intermediate
node indicated congestion.

Sort of... But note that the TRILL header ECN bit s
can indicate non-ECT while the CCE bit is set making
the overall TRILL Header "CE".


Right. That's part of case C. My states above assume
application of Table 2 has already taken place.



> If that's correct, I would think that any state
other than those three needs
> to be marked with an (*). In particular, these two
states fall into that
> classification, and seem to require an asterisk:


[BB] These states are not tagged (*) cos they can arise with variants 
of ECN marking behaviour referred to in Section 4 (explained beneath 
each bullet below). By design (explained further below), a consistent 
encap 

Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Adam Roach]

On 2/8/18 11:53 AM, Donald Eastlake wrote:

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach > wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> Thanks to the authors, chairs, shepherd, and working group for the 
effort that

> has been put into this document.
>
> I have concerns about some ambiguity and/or self-contradiction in this
> specification, but I suspect these should be easy to fix. In 
particular, the
> behavior defined in Table 3 doesn't seem to be consistent with the 
behavior

> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>> +-+--+
>>       | Inner   |  Arriving TRILL 3-bit ECN Codepoint Name     |
>>       | Native  +-+++--+
>>       | Header  | Not-ECT | ECT(0)     | ECT(1)     |     CE   |
>> +-+-+++--+
>>       | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) |    |
>>       |  ECT(0) |  ECT(0) |  ECT(0)    |  ECT(1)    |     CE   |
>>       |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)    |     CE   |
>>       |    CE   |      CE |      CE    |      CE(*) |     CE   |
>> +-+-+++--+
>>
>>                      Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a currently unused
>>  combination that SHOULD be logged. In contrast to [RFC6040], in TRILL
>>  the drop condition is the result of a valid combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native header value to the 
TRILL ECN
>     codepoint (resulting in any of the four values above) or doesn't 
insert

>     any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE flag, resulting in "CE" in the
>     table above.
>
> Based on the above, a packet arriving at an egress gateway can only 
be in one of

> the following states:
>
>  A. TRILL header is Not-ECT because no TRILL node inserted ECN 
information.

>
>  B. TRILL header value == Native header value because the ingress 
gateway

>     copied it from native to TRILL.
>
>  C. TRILL header is "CE" because an intermediate node indicated 
congestion.


Sort of... But note that the TRILL header ECN bit s can indicate 
non-ECT while the CCE bit is set making the overall TRILL Header "CE".


Right. That's part of case C. My states above assume application of 
Table 2 has already taken place.




> If that's correct, I would think that any state other than those 
three needs

> to be marked with an (*). In particular, these two states fall into that
> classification, and seem to require an asterisk:
>
>   - Native==CE && TRILL==ECT(0)
>
>   - Native==ECT(0) && TRILL==ECT(1)

I would defer to my co-author Bob Briscoe but it looks to me like you 
have a good point.


Thanks; I'll wait to hear from Bob.

> In addition, the behavior this table defines for Native==ECT(0) && 
TRILL==ECT(1)
> is somewhat perplexing: for this case, the value in the TRILL header 
takes
> precedence; however, when Native==ECT(1) && TRILL==ECT(0) the Native 
header
> takes precedence. Or, put another way, this table defines ECT(1) to 
always
> override ECT(0). I don't find any prose in here to indicate why this 
needs to be
> treated differentially, so I'm left to conclude that this is a 
typographical
> error. If that's not the case, please add motivating text to Table 3 
explaining

> why ECT(1) is treated differently than ECT(0) for baseline ECN behavior.

As noted in Section 4.1, there is an ECN variation where ECT(0) just 
indicates ECT while ECT(1) indicates congestion of a lesser severity 
level has been encountered than that indicated by CE. I believe the 
dominance of ECT(1) over ECT(0) is designed to not interfere with this 
variation.


Yes, and section 4 opens with the explanation that "Section 3 specifies 
interworking between TRILL and the original standardized form of ECN in 
IP [RFC3168]." Beyond that, I wouldn't expect any of the text in 
non-normative section 4 or its subsections to have bearing on the 
normative table in Section 3.


My reading of RFC 8311 is that it contemplates a series of experiments 
beyond those currently under development. It may well be that the 
current experiments consider ECT(1) to have a higher severity than 
ECT(0), but that this may not make sense for future experiments. Even if 
it does, I don't see guidance in RFC 8311 (or any other update to RFC 
3168) that suggests such a relationship between ECT(0) and ECT(1) exists.


On top of this (as implied by the existence of section 4), the TRILL 
handling for ECN will need to vary from experiment to experiment. It 

Re: [trill] Adam Roach's Discuss on draft-ietf-trill-ecn-support-05: (with DISCUSS and COMMENT)

[Donald Eastlake]

Hi Adam,

On Wed, Feb 7, 2018 at 8:12 PM, Adam Roach  wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-trill-ecn-support-05: Discuss
>
> ...
>
> --
> DISCUSS:
> --
>
> Thanks to the authors, chairs, shepherd, and working group for the effort
that
> has been put into this document.
>
> I have concerns about some ambiguity and/or self-contradiction in this
> specification, but I suspect these should be easy to fix. In particular,
the
> behavior defined in Table 3 doesn't seem to be consistent with the
behavior
> described in the prose.
>
> For easy reference, I've copied Table 3 here:
>
>>   +-+--+
>>   | Inner   |  Arriving TRILL 3-bit ECN Codepoint Name |
>>   | Native  +-+++--+
>>   | Header  | Not-ECT | ECT(0) | ECT(1) | CE   |
>>   +-+-+++--+
>>   | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) ||
>>   |  ECT(0) |  ECT(0) |  ECT(0)|  ECT(1)| CE   |
>>   |  ECT(1) |  ECT(1) |  ECT(1)(*) |  ECT(1)| CE   |
>>   |CE   |  CE |  CE|  CE(*) | CE   |
>>   +-+-+++--+
>>
>>  Table 3. Egress ECN Behavior
>>
>>  An asterisk in the above table indicates a currently unused
>>  combination that SHOULD be logged. In contrast to [RFC6040], in TRILL
>>  the drop condition is the result of a valid combination of events and
>>  need not be logged.
>
> The prose in this document indicates:
>
>  1. Ingress gateway either copies the native header value to the TRILL ECN
> codepoint (resulting in any of the four values above) or doesn't
insert
> any ECN information in the TRILL header.
>
>  2. Intermediate gateways can set the CCE flag, resulting in "CE" in the
> table above.
>
> Based on the above, a packet arriving at an egress gateway can only be in
one of
> the following states:
>
>  A. TRILL header is Not-ECT because no TRILL node inserted ECN
information.
>
>  B. TRILL header value == Native header value because the ingress gateway
> copied it from native to TRILL.
>
>  C. TRILL header is "CE" because an intermediate node indicated
congestion.

Sort of... But note that the TRILL header ECN bit s can indicate non-ECT
while the CCE bit is set making the overall TRILL Header "CE".

> If that's correct, I would think that any state other than those three
needs
> to be marked with an (*). In particular, these two states fall into that
> classification, and seem to require an asterisk:
>
>   - Native==CE && TRILL==ECT(0)
>
>   - Native==ECT(0) && TRILL==ECT(1)

I would defer to my co-author Bob Briscoe but it looks to me like you have
a good point.

> In addition, the behavior this table defines for Native==ECT(0) &&
TRILL==ECT(1)
> is somewhat perplexing: for this case, the value in the TRILL header takes
> precedence; however, when Native==ECT(1) && TRILL==ECT(0) the Native
header
> takes precedence. Or, put another way, this table defines ECT(1) to always
> override ECT(0). I don't find any prose in here to indicate why this
needs to be
> treated differentially, so I'm left to conclude that this is a
typographical
> error. If that's not the case, please add motivating text to Table 3
explaining
> why ECT(1) is treated differently than ECT(0) for baseline ECN behavior.

As noted in Section 4.1, there is an ECN variation where ECT(0) just
indicates ECT while ECT(1) indicates congestion of a lesser severity level
has been encountered than that indicated by CE. I believe the dominance of
ECT(1) over ECT(0) is designed to not interfere with this variation.

> --
> COMMENT:
> --
>
> I also have a small handful of editorial suggestions and nits to propose.

I am fine with all the changes below .

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Please expand "TRILL" upon first use and in the title; see
> https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
>
>
---
> §1:
>
>>  In [RFC3168] it was recognized that tunnels and lower layer protocols
>
> "In [RFC3168], it was..."
> (insert comma)
>
>
---
>
> §2:
>
>>  These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN
>
> "...are shown..."
>
>
>>  The CRItE bit is the critical Ingress-to-Egress summary
>>  bit and will be one if and only if any of the bits in the CItE range
>>  (21-26) is