Document: draft-ietf-ccamp-sdhsonet-control-04.txt 
Trigger: IESG Discussion, 16 December 2004
Reviewer: Elwyn Davies
AD: Alex Zinin
Review Date: 13 December 2004

Intended status: Informational

Summary:
This document seems to be a useful adjunct to
draft-ietf-ccamp-gmpls-sonet-sdh-08.txt for which it claims to be a
'framework' but IMO is mistitled. I have some major reservations about
the way the information is presented.  Suggestions for improvements
are given in the body of the review.

Additionally there is a great deal of SONET/SDH tutorial material
which is somewhat inconsistent in level of detail, and contains some
dangling references.

The text contains a large number of unexpanded/undefined
abbreviations.

All in all, the document *will* be a helpful Informational but needs
some further work to improve the usefulness of the information.

Meta-point: This document was part of the pilot project involving
delegating AD review to WG chair(s).  It will be interesting to hear
Alex's views as to whether he would have flagged any of these issues
at an earlier stage.

Review: Having read through the document, I have some doubts about the
classification of the document as a 'framework': it contains instead a
number of different things – a tutorial on the architecture and
multiplexing structure of SDH/SONET; requirements and design goals for
controlling SDH/SONET networks; and an analysis of how to map the
SDH/SONET architecture onto the existing GMPLS framework for the
purposes of controlling the SDH/SONET network together with an outline
of the necessary protocol extensions.  Perhaps 'framework' is the last
thing it is! (The concepts, structure and mechanisms, which are what I
understand should be in a framework, are provided by GMPLS and not
significantly altered by this document).  Maybe 'requirements and
design goals for mapping SONET/SDH network control onto the GMPLS
framework' might be better.

I was generally uneasy about the way in which the document was
written.  Part of this is probably because it is apparently trying to
address a number of different goals subsidiary to its central one
(para 3, Intro: 'The goal of this work is to highlight how GMPLS could
be used to dynamically establish, maintain, and tear down SDH/SONET
circuits'), and the pieces were not very well separated. These
implicitly include providing tutorial material for SONET/SDH and
justifying expected business value of the work.

The document contains a large proportion of tutorial material
(probably more than 70%) providing the background needed for a
non-expert in SONET/SDH to understand the requirements and design
goals.  I think my main problem with this document is that the
decisions and conclusions related to the various goals (perhaps best
summarized by para 3 of the Introduction) are embedded in the tutorial
material in a way that makes it difficult for an SONET/SDH expert to
go straight for them and would make it difficult to check that the
GMPLS extension proposals match the analysis here.  The document would
be much improved by highlighting the discussion outcomes by suitable
formatting (e.g., quoted paragraphs with key phrase titles) and
providing a proper itemized summary as opposed to the 'academic paper'
style assertions that the goals have been met.  It would also help to
distinguish the points according to the goals they meet and the part
of the GMPLS framework affected (protocols, labels, etc)– some of
this is tied to the section title but some extra notation would help.

Additionally, the tutorial material is somewhat uneven providing (IMO)
excessive detail and discussion in some places (e.g., Sect 1.3 – I
think the operational processes could be compressed and the important
points for this work highlighted - and Sect 4.2 – where the details
of the different protection options are maybe not needed for the
purposes of this work), but, for example, skimping on the (textual)
description of the multiplexing structure in Sect 1.2: Figure 1 is not
terribly comprehensible and contains a set of reference points noted
at the end of para 5 but NOT explained later.  The result is that the
description of the multiplexing structure is distributed across the
document and clutters up portions where decisions are being documented
(such as 4.1).  Overall, compressing the tutorial matter and where
possible keeping it confined to a single section might clarify the
document, and make the decision points more readily visible.

In my view it is essential that the key decision points are
highlighted both as they are finalized within the body of the text,
and possibly by a real summary at the end.  The current summary is
more appropriate to an academic paper where the author is
demonstrating that the points from the intro have been ticked off: for
the purposes of this document, a checklist of things to do to
protocols and boxes plus open issues would help expert readers and
implementers who otherwise have to plough through the whole document
to find what was supposed to have been done.

On the subject of open issues, it is not clear what is being done
about these open issues and whether they ought to be solved before the
document is finalized.

At a more detailed level:
- There are a large number of unexpanded abbreviations, starting right
  from the beginning with SONET and SDH!
- I think the summary of goals in the abstract and the introduction
  are not well aligned.

There are a number of editorial nits relating to formatting: Check the
layout of tables 1 and 5. Also para 1 of 1.4.2.  Also idnits should be
run.

In s1.1, the Layer 2 technologies relevant to VPI/VCI and DLCI need to
be specified (as well as expanding the acronyms).

In s1.2, the term tributary needs to be defined.

Last para of s.1.4.1: s/dissemination/disseminate/

If the doc is going to refer to draft-ietf-ccamp-gmpls-routing-09.txt
indicating how the design decisions are implemented then the ref [12]
surely has to be normative.  I am not sure the ref is a good idea
(making a circular dependency).