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

"Zhangxian (Xian)" <zhang.xian@huawei.com> Wed, 19 March 2014 02:31 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBD51A0308 for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 19:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level:
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSAnkeKFRWon for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 19:31:20 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 52B611A0338 for <ccamp@ietf.org>; Tue, 18 Mar 2014 19:31:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BES13489; Wed, 19 Mar 2014 02:31:10 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 02:30:58 +0000
Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 02:31:08 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.22]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 10:30:56 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Iftekhar Hussain <IHussain@infinera.com>, Ramon Casellas <ramon.casellas@cttc.es>
Thread-Topic: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
Thread-Index: AQHPPSwcqGay97GfJkiJ4/JTd6KXbZrcCU0AgAAXtHCACPbDAIAAZOSwgAAHvID//4WcAIAAjaGAgAAx4QCAAB1UAIAAuCtA//+ODQCAALsogIAA0NTw
Date: Wed, 19 Mar 2014 02:30:55 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B30213972@SZXEMA512-MBS.china.huawei.com>
References: <D7D7AB44C06A2440B716F1F1F5E70AE53FB23DC1@SV-EXDB-PROD1.infinera.com> <OFD8D21453.D491AE4A-ON48257C9F.0023736F-48257C9F.0024039F@zte.com.cn> <C636AF2FA540124E9B9ACB5A6BECCE6B302137BE@SZXEMA512-MBS.china.huawei.com> <53282314.1040201@cttc.es> <D7D7AB44C06A2440B716F1F1F5E70AE53FB2643D@SV-EXDB-PROD1.infinera.com>
In-Reply-To: <D7D7AB44C06A2440B716F1F1F5E70AE53FB2643D@SV-EXDB-PROD1.infinera.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B30213972SZXEMA512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/3hxYe8ApJbKUOP-0Mw2OENsYBQU
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 02:31:25 -0000

Hi,  Ramon, Iftekhar
   I am not sure either why we ask that question in the last point (i.e., May a network media channel be defined as associated with more than one OCh-P?)  and we can expect a “No” answer from current G.872 specification. But I am also concerned about directly using the text provided by Iftekhar since it implies “we are disagreeing with current G.872 and would suggest a change to this Rec.”. There is nothing with the text itself but this would not be appropriate in a liaison.   How about condensing it to the following?
“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 application of network media channel.”
Regards,
Xian
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Iftekhar Hussain
Sent: 2014年3月19日 5:52
To: Ramon Casellas; ccamp@ietf.org
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

Hi Ramon,
“- A NMC as bound to 1 OCh-P by definition of the in-force G.872.
- a Media channel may carry more than 1 OCh-P, but MC != NMC”

The above looks fine and we have the same understanding. What needs clarification is that (a) is NMC required? If so why?  Note that MC already is a superset of NMC. The bullet didn’t have whole text we prefer the following full text in the liaison for clarity:
“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. If intent is that there is always an end-to-end network media channel, then it should support multiple OCh-Ps. Alternatively, eliminate the network media channel definition altogether, in favor of always using the media channel term which already supports this capability. Requiring a one-to-one mapping between OCh-P and network media channels would be restrictive in cases where multiple OCh-P need to go between the same destinations. The most spectrally efficient packing of them may not allow each OCh-P to use its own network media channel within the defined flexible grid granularity”
Please let us know if any further clarification is required.
Thanks,
Iftekhar
From: Ramon Casellas [mailto:ramon.casellas@cttc.es]
Sent: Tuesday, March 18, 2014 3:42 AM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

Dear all,

Thanks for your comments. Below a revised text, still open for discussion.

Personally, I am afraid i still don't fully grasp the last bullet, so please elaborate a bit more or re-formulate (Iftekhar, Rajan?)

[Editor: In my limited understanding:
- A NMC as bound to 1 OCh-P by definition of the in-force G.872.
- a Media channel may carry more than 1 OCh-P, but MC != NMC
- With a Optical Tributary Signal (OTS) there is a 1:1 mapping between OTS:NMC.
- A particular case of OTS is an OCh-P
For my understanding, can a OTS group multiple OCh-P?]


Thanks
R.

--------------------------------------------------------

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 as follows (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) 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).
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]

*    Current in-force G.872 recommendation 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.  May a network media channel be defined as associated with more than one OCh-P?

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