Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-ieee-aq-03.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Tue, 25 Jan 2011 16:41:50 +0100

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose of
the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-isis-ieee-aq-03.txt
Reviewer: Matthew Bocci
Review Date: 24-01-11
IETF LC End Date: 18-01-11
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

Major Issues:

None

Minor Issues:

Abstract:
   802.1aq Shortest Path Bridging (SPB) is being standardized by the
   IEEE as the next step in the evolution of the various spanning tree
   and registration protocols. 802.1aq allows for true shortest path
   forwarding in a mesh network context utilizing multiple equal cost
   paths. This permits it to support much larger layer 2 topologies,
   with faster convergence, and vastly improved use of the mesh
   topology. Combined with this is single point provisioning for
   logical connectivity membership (E-LINE/E-LAN/E-TREE etc).

MB> I would suggest stating up-front that this is applicable to Ethernet
e.g. "802.1aq allows for true shortest path forwarding in an Ethernet mesh
network context utilizing multiple equal cost paths." Also, please expand
all acronyms on first use.

   Note that 802.1aq requires no state machine or other substantive
   changes to [IS-IS]. It is our intention that 802.1aq be simply a new
                                 ^^^^^^^^^
MB> Is this an intention or fact? I think this could be rephrased as e.g.
"802.1aq simply requires a new
    NLPID and set of TLVs."

   NLPID and set of TLVs. In the event of any confusion the reader
   should take [IS-IS] as authoritative.

MB> Please can you clarify the above sentence. Do you mean "In the event
of inconsistency between this document and [IS-IS], [IS-IS] should be
taken as authoritative."?

Section 1: Introduction:
This section is empty. I suggest that some text should be proposed to fill
this section.

Section 4: 
This draft specifies a number of extensions, in particular a set of new
TLVs, to allow IS-IS to support Shortest Path Bridging (SPB). Those
sections of the draft are clearly normative. It also includes a lengthy
overview (Section 4) of SPB which I do not think is intended to be
normative (the draft explains that the IEEE is responsible for the overall
standardisation of SPB).  However, that section contains some text using
normative language, e.g: MUST NOT in Section 4.3. I believe this language
should be removed and the status of section 4 clarified. You could include
a statement similar to the statement about IS-IS that you used in the
abstract, but referencing [802.1aq], as the first paragraph of section 4.

Sections 13 - 16
These sections define the new TLVs. In general, the figures do not
indicate the byte ordering/alignment and do not share a common style. For
example, in section 14.1:

   +-+-+-+-+-+-+-+-+
   |Type = SPB-Inst| = 1
   +-+-+-+-+-+-+-+-+
   |   Length      |     (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               CIST Root Identifier  (4 bytes)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               CIST Root Identifier (cont)  (4 bytes)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           CIST External ROOT Path Cost     (4 bytes)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Bridge Priority        |         (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R R R R R R R R R R R|V|              SPSourceID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Num of Trees  |       (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  VLAN-ID (1) Tuples    (8 bytes)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  VLAN-ID (N) Tuples    (8 bytes)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    where VLAN-ID tuples have the format as:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+
      |U|M|A|  Res    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ECT - Algorithm (32 bits)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Base VID (12 bits)    |   SPVID (12 bits)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It would help readability if you structured the figures throughout showing
the ordering/alignment by adding a couple of lines to the top of each one
showing the bit/byte alignment, as in the VLAN-ID tuple example above.

Nits:
- There are numerous instances where acronyms are not expanded on first
use. Please expand all unfamiliar (i.e. not very common in the routing
area) acronyms.

- Section 4, 2nd para, last line: please provide references for 802.1ag
and Y.1731.