Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
draft-ietf-isis-rfc6326bis-03

From Carlos' OPS-DIR review:

This is a really well written document. It addresses operational considerations of backwards compatibility of the new protocol constructs defined. Other considerations for operational impact are covered in the base protocol.

Nits: RFC 5342 was obsoleted by RFC 7042 and the pointer should probably be updated.

Alexey Melnikov raised two valid points in his Gen-ART review. I'm hoping the draft is revised according to the discussion that took place after the review.

This draft is nicely written. Thank you for that.

I did have one comment. Please consider it along with any other comments you receive.

In 2.2.3 Appointed Forwarders Sub-TLV

   o  Start.VLAN, End.VLAN: These fields are the VLAN IDs of the
      appointment range, inclusive. To specify a single VLAN, the VLAN's
      ID appears as both the start and end VLAN. As specified in
      [RFC6439], appointing an IS forwarder on a port for a VLAN not
      enabled on that port has no effect. If the range specified is or
      includes the value 0x000 or 0xFFF, such values are ignored as they
      are not valid VLAN numbers and a port cannot be enabled for them.

and in 2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV

      -  VLAN.start and VLAN.end: This VLAN ID range is inclusive.
         Setting both VLAN.start and VLAN.end to the same value
         indicates a range of one VLAN ID. If VLAN.start is not equal to
         VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as
         if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end
         and VLAN.end is 0xFFF, the sub-TVL is interpreted as if
         VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the
         sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000
         or both are 0xFFF, the sub-TLV is ignored.

I THINK these descriptions are saying the same thing, but the description in 2.3.6 was more precise and more clear to me. If they are saying the same thing, I'd suggest using the 2.3.6 description in both places. 

For extra credit, the point from 2.2.3 that "0x000 and 0xFFF are not valid VLAN numbers and a port cannot be enabled for them" could usefully appear in both places.