Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks
RFC 4257

[Ballot comment]
After discussion with the AD I have cleared Harald's DISCUSS, even though the main point raised by Elwyn Davies, the Gen-Art reviewer, (excessive tutorial, unevenness of detail, whether it really is a framework and failure to highlight conclusions/requirements) has not been fixed. This is a judgement call.

However, there is one new review comment that should be fixed editorially.

> One additional point which I didn't pick up on in the previous review is a
> 'red rag' issue in the second paragraph of 1.1: equating MPLS LSP in
> general with circuit.

[Ballot discuss]
The Security Considerations are very weak.  Section 1.4.1 says that
  manual entry errors can be reduced.  However, this means that a
  protocol is running in the customer-edge equipment.  What happens
  if an attacker is able to manipulate this device?  In the manually
  configured case, only the one link is impacted.  It seems like the
  impact will be magnified in the proposed solution.

  Section 3 says:
  >
  > (iv) Information intended only for end systems of the connection.
  > Some of the payload type information in may fall into this category.
  >
  I am baffled.  Please explain it.

[Ballot discuss]
Reviewed by Elwyn Davies, Gen-ART, who found the presentation of materials somewhat suboptimal - in particular, he found conclusions and tutorial/background materials so thoroughly mixed that it's hard to tell what the document is trying to say.

I'd like (at minimum) a response to the review before approving it.

Review from Elwyn Davies, Gen-ART:

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).

[Ballot comment]
Missing IANA Considerations.

I'm not sure I agree with the statements in the Security Considerations section about the need for GMPLS protocol specifications alone to identify and address security issues specific to protocol.  If this document is describing an extension framework, shouldn't it also address the security implications of extensions in general?  I'll leave it to Russ or Sam to determine if this merits a discuss or not.