Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

[Jonas Mårtensson <[e-mail]>]

Hi Oscar and Ramon,

A minor comment on the first point of the proposed liaison: I don't think G.694.1 talks about channel spacing in the context of flexible grid, only "nominal central frequency granularity" and "slot width granularity". Therefore I propose to change the text as follows:

NEW:

* Please comment on future changes regarding the values of nominal central frequency granularity [currently 6.25 GHz] and slot width granularity [currently 12.5 GHz], as defined in G.694.1. Is ITU-T considering alternative values in the foreseeable future? If yes, is it correct to assume, that the following always holds, w.r.t. slot width granularity (SWG) and nominal central frequency granularity (NCFG)? SWG = 2 * NCFG [Note: changes in these values may impact the need for code-points]

/Jonas


From: CCAMP [mailto:[e-mail]] On Behalf Of Oscar González de Dios
Sent: den 17 mars 2014 17:39
To: CCAMP
Subject: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

Dear CCAMP Colleagues,

We have prepared a first draft of the text for the liaison ITU-T - IETF CCAMP regarding clarifications in Flexi-Grid. Thanks for the contributions sent to us by email.

We would gladly appreciate your feedback in the liaison text. Please find attached the proposed text with comments from a review by Deborah. Also, for those of you allergic to non-standard file formats, please find bellow the plain text:

* Please comment on future changes regarding the values of nominal central frequency (NCF) granularity or channel spacing (CS) [currently 6.25 GHz] and slot width granularity [currently 12.5 GHz], as defined in G.694.1. Is ITU-T considering alternative values in the foreseeable future? If yes, is it correct to assume, that the always following holds, w.r.t. slot width granularity and CS? SWG = 2 * CS [Note: changes in these values may impact the need for code-points]

* Clarification on the maximum values of the slot width (m parameter) and expected use cases (e.g. to cover the whole C band). Knowing these values is required since it has an impact on its encoding. 

* Clarification on the need for "hitless" and "hitless" capabilities. Is ITU-T considering any hitless procedure, such as resizing / restoration of a network media channel (in terms of its frequency slot)?
* Examples of cases where hitless capabilities may be considered are:
- Case 1: Recovery where the new network media channel uses a diverse path 
- Case 2: shrink / enlarge frequency slot width, invariant NCF (n)
- Case 3: shift the NCF (n), maintaining the frequency slot width (m) 

* Clarification regarding the discussed use case where an optical tributary signal is to be supported by multiple network media channels, as in "An OTUCn is carried in its entirety over one optical channel layer connection, which is considered to be supported by multiple network media channels", where a (co-routed) group of network media channels which must be managed as a single entity - set up, restored, and cross-connected. If this is on scope, what is the estimated availability of ITU-T Recommendation (amendments?) covering this new requirement? 
[Note: CCAMP has considered so far the following requirement: "The control plane architecture SHOULD allow multiple media channels to be logically associated.  The control plane SHOULD allow the co-routing of a set of media channels logically associated".]


* G.872 defines that a media channel may carry more than one OCh-P signal. It also defines that a network media channel is a specific use of media channel with a single OCh-P.  Clarification is needed on the definition and application of network media channel and its support of multiple OCh-Ps 

Looking forward to receiving your feedback,

Oscar and Ramon

________________________________________

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