Date: Wed, 12 Feb 2014 14:46:55 +0000
From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= <ogondio@tid.es>
In-reply-to: <52F8AB2D.8090206@cttc.es>
To: Ramon Casellas <ramon.casellas@cttc.es>, "ccamp@ietf.org" <ccamp@ietf.org>
Message-id: <CF1E6A31.2DCE5%ogondio@tid.es>
Content-id: <42939A369E59CD4BBBCC642BC71F1E00@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-language: es-ES
Content-transfer-encoding: quoted-printable
Accept-Language: es-ES, en-US
Thread-topic: [CCAMP] Flexi-Grid control plane requirements - was: Generalized
 Labels for the Flexi-Grid in LSC Label Switching Routers
Thread-index: AQHPJkvX7jXqbdqcXkqxp10OFKng7ZqxtfUA
user-agent: Microsoft-MacOutlook/14.2.5.121010
Subject: Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized
 Labels for the Flexi-Grid in LSC Label Switching Routers
Precedence: list

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=F3:
>> 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=3D1 for SWG=3D 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
>CCAMP@ietf.org
>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 nu=
estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl=
ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re=
ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx