Re: [CCAMP] OPS-DIR Review of draft-ietf-ccamp-flexi-grid-fwk-05

[Ramon Casellas <[e-mail]>]

Dear Tina, all

Thank you for your review and comments. Apologies for the delay in my 
answer due to being on holiday

Comments in-line

El 05/08/2015 a las 5:41, Tina TSOU escribió:
> Dear all,
>
>
> 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.
Ramon> I am afraid I am not sure how to address this in the draft (e.g. 
specific changes). The selection of the parameter n for each (local to a 
node) frequency slot width is part of the RSA process and can be 
selected either in a distributed way by each hop for its local frequency 
slot or by e.g. a PCE doing the path computation. In any case it is part 
of the resource allocation aspect.

> 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).
Ramon> to some extent, I would guess your questions are already addressed

    Different operational modes can be considered.  For Routing and
    Spectrum Assignment (RSA) with explicit label control, and for
    Routing and Distributed Spectrum Assignment (R+DSA), the GMPLS
    signaling procedures are similar to those described insection 4.1.3 of [RFC6163] 
<https://tools.ietf.org/html/rfc6163#section-4.1.3>  for Routing and Wavelength Assignment (RWA) and for
    Routing and Distributed Wavelength Assignment (R+DWA).


If Explicit Label Control in the ERO is used, it would indeed be in the 
Path message. Otherwise, GMPLS procedures using e.g. LABELSETs, etc. 
apply.  I think that no new node behavior in required (since existing 
procedures cover the cases, e.g. both ELC or a Labelset can be used to 
force a same "n"). Finally, whether the allocation is first-fit, random, 
etc. this is I think implementation specific and the document does not 
address how it could be done (multiple ways, as you mention).

> 2.	Section 5.5, the support for neighbor discovery should not be a MAY, consider a SHALL or even MUST.
Ramon> this point was also raised by David Black in its review. Adrian's 
answer was in the lines of common practice where automatic neighbor 
discovery may not be used, relying on validation -- once the fiber and 
transceivers are provisioned -- (in particular, It may be useful to 
clarify that this particular section is referring to the use of LMP). It 
would also exclude transparent optical networks in which direct neighbor 
discovery would be difficult unless e.g. a dedicated wavelength is 
deployed with O/E/O

(on a side node, I may be wrong but SHALL or MUST would be equivalent?)


>
> 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.
Ramon> I am afraid I do not fully agree. In my opinion, every time the 
word "slot" appears it refers to "Frequency slot" (FS). The omission of 
"frequency" is only possible because it is non ambiguously implied. In 
other words, "slot width" is always implied "frequency slot width".
If, on the contrary, there are places where the term "frequency slot 
width" can be confused with "frequency slot", please point them out, 
since the width is just an attribute of the slot (the other being the 
NCF). In any case "slot width" and "frequency slot width" are exactly 
the same.

One could then argue that every occurrence of the word "slot" should be 
preceded with "frequency" but this would also affect ITU-T docs and 
acronyms like SWG would need to change to FSWG.

> In Section 4.5 (p21), first paragraph in page 21, there are two ‘frequency slot width’, should be corrected as ‘frequency slot’.
Ramon> I think you are referring to

  A "service request" is characterized (at a minimum) by its required
    effective frequency slot width.  This does not preclude that the
    request may add additional constraints such as also imposing the
    nominal central frequency.


As stated, the minimum is to "request" the "m" (width). Requesting the 
slot would mean requesting *also* the "n" (NCF) which is later covered. 
I am not sure it needs changing.
> In Section 5.1.1 (p30), second paragraph, there is one ‘frequency slot width’, should be corrected as ‘slot width’.
Ramon> these are, IMHO, equivalent. As stated above, a slot is always a 
frequency slot.
> In Section 5.2 (p31), first paragraph, there is one ‘frequency slot width’, should be corrected as ‘slot width’.
Ramon> idem.
>
> 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’.
Ramon> A "slot nominal central frequency" refers to the central 
frequency (the "n" parameter) of a Frequency Slot (FS). It is one of a 
FS attributes/parameters along its with. In the figure, theer are many 
nominal central frequencies, but only 2 "(frequency) slot nominal 
central frequencies" for there are only 2 frequency slots drawn. I 
believe the "^" is correct. that said, due to previous emails, I have 
changed "Central F" to "Slot NCF" in the Figure

In other words, in the Figure 3, there are 2 slots == 2 frequency slots 
== 2 FS:
- the first (frequency) slot 1 is centered at the NCF 193.1 THz --> for 
slot 1, its "slot nominal central frequency" is that NCF, that is n=0.


>
> 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’.
Ramon> We are not excluding the use of centralized RSA, as in the 
snippet quoted above, a e.g. a PCE could be used to do centralized RSA 
and be implemented in terms of explicit label control in the ERO. This 
is analogous to what is done in WSON. the term distributed refers to the 
fact that some parameters (e.g. m or n) of each slot is allocated by the 
node. With ELC, it would not be the case and the procedures in Figures 
15 and 16 would not apply


Many thanks again for your review and comments

Ramon