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

[Tina TSOU <[e-mail]>]

Dear Ramon et al,

Thank you for getting back to me and OPS DIR.

Comments are in line.


Thank you,
Tina

From: Ramon Casellas [mailto:[e-mail]]
Sent: Monday, August 24, 2015 7:45 PM
To: Tina TSOU; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: OPS-DIR Review of draft-ietf-ccamp-flexi-grid-fwk-05

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 in section 4.1.3<https://tools.ietf.org/html/rfc6163#section-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).

[TT] From RFC 6163 it is clear that n is included in path, I agree with your clarification that it is not flexi-grid specific. A proper mentioning may help remove confusion from readers.





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
[TT] Good. No further Comments.


(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.
[TT] The relationship should be: the information of ‘frequency slot’ includes the central frequency (n) and slot width (m). My understanding is that the following should be changed to frequency slot, as path message already implies n and m is needed to be extended in flexi-grid literature.

A "service request" is characterized (at a minimum) by its required  effective frequency slot width.

If the frequency slot width is equivalent with slot width, why not just keep it consistent? I think the latter have more popular appearance in the draft.





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.

[TT] OK, no further comments.





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
[TT] Fine for me, no further comments.

Many thanks again for your review and comments

Ramon