Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks
draft-ietf-ccamp-flexi-grid-fwk-07

The RFC Editor will fiddle with your "Authors" and "Contributing Authors" sections... just so you know.

To folluw up on the recent OPS-DIR reveiw by Tina Tsou:

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

- (Nearly a discuss) Section 7 refers back to RFC5920
(from 5 years ago) and RFC6163 (presumably the 3 paragraph
section 7) and also claims that there is "no substantial
reason to to expect the security considerations to be any
different." That's pretty unimpressive to be honest. Don't
you think it'd be reasonable to expect that a new
architecture, framework and set of protocols for high
speed networks should today include a thorough security
and privacy analysis done afresh and not simply referring
back to previous work? For example, is it not likely that
in some cases new IGP security primitives might be needed,
or that virtualisation and data centre trends would mean
that some additional isolation between different folks'
data was desirable or that some kind of automated key
management be finally required to be included from the
start of the design of any new control plane? (This isn't
a discuss as it's probably better to hold that kind of
discussion for a next stage when some architecture or
protocols are defined.)

- typo: trnaponders, I like it:-)

wow.. what a read. Thanks for the best example of meaningful ASCII art I have seen in a long long time :-)