[CCAMP] Benoit Claise's No Objection on draft-ietf-ccamp-flexi-grid-fwk-05: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-ccamp-flexi-grid-fwk-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-flexi-grid-fwk/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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