[trill] AD review of draft-ietf-trill-rfc7180bis

[Alia Atlas <[e-mail]>]

As is customary, I have done my AD review of
draft-ietf-trill-rfc7180bis-05.  First, I'd like to thank the authors
Donald, Mingui, Radia, Ayan, Anoop, and Sujay for their work on this.

Due to some oddity in the datatracker, I didn't learn that the WG had
requested publication until I got a private email.  I apologize for the
delay in review.

Below are my comments.  The only one that is really blocking for starting
IETF Last Call is about Appendix C.   If we can get the comments resolved
and a new draft issued before next Thursday, then this draft should be able
to make the Oct 22 telechat.


1)In Sec 8.2: " Control packets can be ordered into priority classes as
shown below.
   Although few implementations will actually treat all of these classes
   differently, lower numbered classes SHOULD NOT be treated as lower
   priority than higher numbered class."

  Can you clarify what the point of listing these different priority
classes, if the lower number classes aren't lower priority & treated that
way??

2) Sec 8.4:  I would really like to see an explanation for why the Nickname
Flags APPSub-TLV is needed.  I see the description and efforts to clarify
edge cases, which is great, but nothing that says "This is the problem a
Nickname Falgs APP sub-TLV is solving and the types of problems additional
flags might solve in the future."

3) In Sec 10.2.1.3: "   3. If the Hop Count is zero, it is set to the
maximum value of 63 and
      the extended Hop Count is decremented."  What happens to the Critical
Bit Summary when the extended Hop Count goes to 0?  I don't see any mention
of it after the ingress RBridge setting it.

4) In Sec 10.2.2: "The meaning of the possible non-zero values of this
2-bit field (1, 2 or 3) is implementation dependent."  Is this assuming
that the zero value has a specific meaning of being unset or something
else?  Please clarify.

5) In Sec 10.3: "Finally,   there is the Non-Critical Ingress-to-Egress
field, the top two bits
   of which are specified herein as the Extended Color field."  The figure
shows bits 27 and 28 of the word, which are the low bits of the field - not
the top 2 bits.

5) Appendix C makes me uncomfortable in a Proposed Standard RFC.  Either
you are loosening the restrictions in a normative way or not...  This reads
like an "implementation hints to not quite conform".  Can you and the WG
figure out a better plan?

Thanks again,
Alia