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

From: Ramon Casellas <[email-masked]>
Date: Mon, 24 Aug 2015 13:44:45 +0200

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

---

From: Tina TSOU <[email-masked]>
Date: Thu, 27 Aug 2015 03:52:45 +0000

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:[email-masked]]
Sent: Monday, August 24, 2015 7:45 PM
To: Tina TSOU; [email-masked]
Cc: [email-masked]; [email-masked]
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

Dear all,

Technical Comments:

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.

   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

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.

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.

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.

Ramon

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 27 Aug 2015 07:59:46 +0200

> Thank you for getting back to me and OPS DIR.
Dear Tina, all,

Please see inline (stripped to the pending points)
Thanks again you for your comments
>
>
> 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.
>
Ramon> for the sake of completeness, let me mention that n _may_ be 
included in the path, but it is not mandatory. See also next point (related)

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

Ramon> As mentioned before, a Path message may imply n or not (for 
simplicity, lets just focus in undir connections). We have the cases:
- Path message has explicit label control, n is included in the label 
sub-object => path implies n
- Path message has a labelset. A particular case is when the labelset 
has a single entry (n)  -- which, by the way, is a means to implement 
ELC -- => path implies n
- Path message has no labelset, no ELC => path message does not imply n 
and the selection of "n" is postponed until Resv processing. The "first 
n" appears in the Resv message of the egress node.

The current text says:

    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
    of [RFC6163] for Routing and Wavelength Assignment (RWA) and for
    Routing and Distributed Wavelength Assignment (R+DWA).  The main
    difference is that the label set specifies the available nominal
    central frequencies that meet the slot width requirements of the LSP.
    The intermediate nodes use the control plane to collect the
    acceptable central frequencies that meet the slot width requirement
    hop by hop.

IMHO, it covers the cases. Could you please clarify what would be worth 
changing?

> 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.
>
>
Ramon> Proposed change

OLD

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

NEW

effective slot width.

Best regards,
Ramon