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

[Ramon Casellas <[e-mail]>]

El 27/08/2015 a las 5:52, Tina TSOU escribió:
>
> Dear Ramon et al,
>
> 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?


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

OLD


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

NEW

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


Best regards,
Ramon