Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

[Oscar González de Dios <[e-mail]>]

Dear Iftekhar, Ramon, all

        Further comments inline

>Dear Iftekhar, All,
>
>Thanks for volunteering to contribute with an initial set of
>requirements. Since I am going through Iftekhar requirements and how to
>map them into the framework document, I would like some clarifications
>(including comments from other authors and contributors). Please, see my
>comments inline
>
>
>El 08/02/2014 8:46, Iftekhar Hussain escribió:
>> R1: Single Frequency Slot Network Connection
>> The control plane SHALL be able to support network media channels
>>containing a single frequency slot.
>Ramon> Ok.
>
>> R2: Frequency Slot Width Range
>>         The control plane protocols SHALL allow flexible range of
>>values for the frequency slot width (m)  parameter. Specifically, the
>>control plane SHALL allow  setting up a network medial channel with
>>frequency slot width (m) ranging from a minimum of 12.5GHz to a maximum
>>of the entire C-band with a slot width granularity of 12.5GHz.
>Ramon> Ok.
>
>>
>> R3: Finer Granularity Slot Width
>> The control plane SHOULD be architected to allow support network media
>>channels with frequency slot width m ranging from a minimum of 6.25GHz
>>to a maximum of the entire C-band with granularity of 6.25GHz
>Ramon> I would disagree at this point. I don't know how to map this
>requirement in view of the framework text that defines a slot width with
>a minimum of m=1 for SWG= 12.5 GHz. Like in some requirements below, I
>don't think it is a matter of qualifying with SHALL o SHOULD a given
>capability that sticks / does not stick to the current agreed text.
[Oscar] I do not fully understand the requirement as it is written. Do you
mean having, instead of a granularity of 12,5, have other values for the
SWG? Current granularity is set to 12,5 (full stop). There has been a set
of emails in
the ccamp mailing list questioning the need of including a field
Indicating the slot width granularity, and I have not seen agreement yet.
Gabriele reported Optical Modules with very fine granularity, 1 GHz.

Maybe it is a question to ask our dear ITU data plane folks, whether
different
SWG are envisioned. In such case, I will be more than happy to include it
as a requirement. Otherwise, I would rather drop it at present.



>
>>
>> R4.: Flexible Mapping of Media Channels on the ITU-T defined Flexible
>>Grid
>> The control plane SHALL allow mapping of network media channels on any
>>arbitrary nominal central frequency location (i.e., n ) on the ITU
>>defined Flexible Grid.
>Ramon> This seems to me that we would be excluding hardware that has
>some constraints related to nominal central granularity. Am I missing
>something?
[Oscar] Maybe a set of requirements can be added to the document
regarding feasible combinations of n and m in the hardware.


>
>
>>
>> R5: L-band and S-band
>> The control plane architecture SHOULD allow  for  L-band and S-band
>>support.
>Ramon> seems ok, any other comment?
>
>
>>
>> R6: Resizing of the Frequency Slot Width
>>          The control plane SHALL allow resizing (grow or shrink)
>>frequency slot width of a network media channel. In certain scenarios,
>>the resizing of frequency slot  of a network media channel  MAY cause
>>temporary data plane disruption.
>Ramon> My only comment here is whether SHALL or SHOULD. Isn't resizing a
>somehow optional feature w.r.t a minimum set of functions? - I have no
>strong opinion here, quite willing to hear other views.
[Oscar] It is necessary to add the data plane disruption here? What does
it imply for the control plane? At least, I would like that the change of m
(I guess that is the kind of resizement you refer to) should be hitless
in terms of control plane.

>
>
>>
>> R7. Network Media Channel Restoration
>>        The control plane SHALL support network media channel
>>restorations:
>> a)   During the restoration process, the control plane SHALL allow to
>>pick a different frequency slots for the media channel, keeping
>>frequency slot width (m) the same
>> b)   During the restoration process, the control plane SHOULD allow
>>changing of m (in coordination with client e.g., needing to change
>>modulation, using different frequency slot width for same capacity to
>>close restoration path)
>Ramon> ok
>> c)   During the restoration process, the control plane SHOULD allow
>>changing from single frequency slot (m) to multiple frequency slots
>>(e.g., m1, m2) (to deal with blocking / fragmentation on possible
>>restoration paths  where m1 + m2 might be greater than or equal to m
>>       d)    Network media channel restoration with optional
>>pre-computed path (with or without resource reservation) SHALL be
>>supported.
>>       e)    Revertive and Non-Revertive restoration options SHALL be
>>provided
>
>Ramon> IMHO, we would need to work on this requirement a bit more, from
>a descriptive text perspective, detailing inverse multiplexing of a OTS
>over more than one frequency slot, before adding it as a formal
>requirement. As a general note, I am not in a confident position to tag
>requirements with SHALL/SHOULD. Feedback and comments welcome.
>
>
>>
>> R8: Optical Spectrum Network Usage
>> The control plane SHALL be able to keep track of (gather/disseminate)
>>information about optical spectrum usage in the network including (but
>>not limited to):
>>      a)      Available Optical Spectral Slices
>>     b)      Provisioned Optical Spectral Slices
>Ramon> I believe the term slice is undefined. the part regarding routing
>also needs an overhaul in the framework text.  I would be more in favor
>of using the term frequency slot, correct?
>>
>> R9:  Routing of Optical Signals with Different Modulation Formats
>>       The control plane SHALL be capable of placing optical signals
>>with different modulation formats on the Flexible Grid network media
>>channels.
>
>Ramon> We have not addressed anything regarding  modulation formats or
>the signal layer in general. I wonder whether, at this stage, mentioning
>modulation formats explicitly (out of the descriptive text) is
>appropriate?
>
>>
>> R10: Network Media Channels with Multiple Frequency Slots
>> The control plane architecture SHALL allow network media channels with
>>multiple contiguous or non-contiguous frequency slots. In this scenario,
>>it SHALL be possible to co-route all frequency slots associated with a
>>given network media channel.
>Ramon> The current frawework text, unless mistake from my part, does not
>cover a network media channel over multiple (contiguous or not)
>frequency slots. Should we re-phrase this as a "The control plane
>architecture SHOULD allow multiple media channels to be co-routed and
>logically associated" ?  (editor: I am thinking of association objects,
>or channelsets, etc.)
[Oscar] Agree with Ramon, one minor comment: The 'logical association' of
media channels has no name yet. Do we ask ITU for a term on that? Do we
use an already existing IETF term?


>
>
>> R11: Embedded Control Channel for Network Media Channel Routing and
>>Signaling
>> The framework SHALL support the standard mechanism for ECC defined in
>>[i.e., OSC based control channel], for OAM features required to be
>>supported between network elements deploying network media channels over
>>Flexible Grid
>Ramon> Could you please provide the [i.e., OSC based control channel]
>reference?  I am not sure of making it a SHALL requirement to support
>OSC based control channel. Also, your requirement mentions "network
>media channel routing and signalling" but the text sticks to OAM. Could
>you please clarify?
>
>
>Thanks again for moving this forwqaa
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp

[Oscar] We (Ramon and me), as editors of the document, will incorporate
the requirements that have an agreement and publish them for a new
version. Please consider commenting on the set of requirements proposed by
Iktekhar and/or add more requirements.

Best Regards,

    Oscar


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx