Last Call Review of draft-ietf-ccamp-flexi-grid-fwk-05

Request Review of draft-ietf-ccamp-flexi-grid-fwk
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-04
Requested 2015-07-13
Authors Iftekhar Hussain, Xihua Fu, Fatai Zhang, Daniele Ceccarelli, Oscar de Dios, Ramon Casellas
Draft last updated 2015-08-06
Completed reviews Genart Last Call review of -05 by David Black (diff)
Genart Telechat review of -05 by David Black (diff)
Secdir Last Call review of -05 by Sam Hartman (diff)
Opsdir Last Call review of -05 by Tina Tsou (diff)
Assignment Reviewer Tina Tsou 
State Completed Snapshot
Review review-ietf-ccamp-flexi-grid-fwk-05-opsdir-lc-tsou-2015-08-06
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Review completed: 2015-08-06


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,