Liaison statement
ITU-T - CCAMP Liason regarding Flexi-grid Redux

State Posted
Posted Date 2014-03-22
From Group ccamp
From Contact John Drake
To Group ITU-T-SG-15
To Contacts greg.jones@itu.int
Ccghani.abbas@ericsson.com
lbpanslow@ciena.comerger
akatlas@juniper.net
lberger@labn.net
Malcolm.BETTS@zte.com.cn
db3546@att.com
adrian@olddog.co.uk
greg.jones@itu.int
kam.lam@alcatel-lucent.com
scott.mansfield@ericsson.com
Peter.Stassar@huawei.com
sshew@ciena.com
Steve.Trowbridge@alcatel-lucent.com
ccamp@ietf.org
tsbsg15@itu.int
Response Contact jdrake@juniper.net
Technical Contact jdrake@juniper.net
Purpose For action
Deadline 2014-07-04 Action Taken
Attachments (None)
Liaisons referred by this one LS/r on CCAMP Liaison to ITU-T SG15 Q6 and Q12 on flexible grid
Liaisons referring to this one LS/r on flexible grid (reply to IETF-CCAMP-LS012)
Body
The CCAMP Working Group would like to thank you for your response liaison,
COM-15-LS 079, titled “LS/r on CCAMP Liaison to ITU-T SG15 Q6 and Q12 on
flexible grid”, dated 29 October 2013

In order to progress our work on the draft “Framework and Requirements for
GMPLS based control of Flexi-grid DWDM networks” [1] and subsequent solution
documents within the IETF CCAMP working group, we would like to receive your
comments/clarification on the following items (addressing ITU-T experts within
Q6, Q12 and Q14):

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

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

• Opinion / Clarification on the data plane “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:

o   Case 1: Recovery where the new network media channel uses a diverse path
o   Case 2: shrink / enlarge frequency slot width, invariant NCF (n)
o   Case 3: shift the NCF (n), maintaining the frequency slot width (m)


• Clarification on the case where an OTUCn is carried by a (co-routed) group
of network media channels which must be managed as a single entity (including
set up, recovery, and hardware cross-connection). If this is in scope, what is
the estimated availability of ITU-T Recommendation 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”. If ITU-T covers this new requirement, it may
have an impact on the control plane representation and related procedures.]

• G.872 defines that a media channel may carry more than one OCh-P signal. It
also defines that a network media channel is the end-to-end channel allocated
to transport a single OCh-P.  We would appreciate clarification on the
application of network media channel with respect to media channel related to
management and configuration aspects.

We would appreciate if you would continue to keep us informed of your progress
and development on capabilities for the data plane that may affect the control
plane.

Best regards,
Lou Berger and Deborah Brungard
IETF CCAMP Working Group Co-Chairs

[1] http://tools.ietf.org/html/draft-ietf-ccamp-flexi-grid-fwk-01