Last Call Review of draft-ietf-ccamp-flexi-grid-fwk-05
review-ietf-ccamp-flexi-grid-fwk-05-opsdir-lc-tsou-2015-08-06-00

Dear all,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

Technical Comments:
This document provides a complete framework for GMPLS flexi-grid network.
Technical comments are as follow: 1.      It is not clear how the parameter n
are determined. In page 22 the last two paragraphs are as follow: o  Each
downstream node ensures that m is >= requested_m. o  A downstream node cannot
foresee what an upstream node will allocate.  A way to ensure that the
effective frequency slot is valid along the length of the LSP is to ensure that
the same value of n is allocated at each hop.  By forcing the same value of n
we avoid cases where the effective frequency slot of the media channel is
invalid (that is, the resulting frequency slot cannot be described by its n and
m parameters).

When mentioning “a downstream nod cannot foresee…”, it should be clear that
what the downstream node can receive from upstream adjacent node (probably in
PATH message). Do downstream node(s) need to select an effective central
frequency (n) from a set of them? And what is corresponding criteria? Random
selection? It may be a little bit ‘solution’ instead of ‘framework &
requirement’, however, it is mentioned ‘forcing the same value of n’ (should
consider changing to ‘standard track’ if new node behavior introduced), so it
had better to specify what kind of information is included in both request
message (PATH) and response message (RESV). Moreover, if Path message include
any central frequency information (n), or a set of them, the Path message in
Fig. 15 and 16 should be shown as Path(n, m_req).

2.      Section 5.5, the support for neighbor discovery should not be a MAY,
consider a SHALL or even MUST.

Editorial Comments:
1.      Some terminologies are misleading. There are a few places using term
‘frequency slot width’, which confuses the reader (can be either understand of
frequency slot or slot width) and should be corrected. In Section 4.5 (p21),
first paragraph in page 21, there are two ‘frequency slot width’, should be
corrected as ‘frequency slot’. In Section 5.1.1 (p30), second paragraph, there
is one ‘frequency slot width’, should be corrected as ‘slot width’. In Section
5.2 (p31), first paragraph, there is one ‘frequency slot width’, should be
corrected as ‘slot width’.

2.      The description of Fig. 3, now saying “The ‘^’ represents the slot
nominal central frequency”, it is not clear what is ‘slot nominal central
frequency’, should be ‘nominal central frequency’ or ‘the position of nominal
central frequency’.

3.      Figure 15 and 16 are labeled as ‘Distributed Allocation with Different
m and Same/Different n’ respectively, however it is not clear why we need to
mention ‘distributed’. There is no centralized mechanism in this draft, suggest
removing the ‘distributed’.

Have a good summer vacation to those of you who is having/will have it..

Thank you,
Tina