Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
Ramon Casellas <ramon.casellas@cttc.es> Tue, 18 March 2014 10:42 UTC
Return-Path: <ramon.casellas@cttc.es>
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 7FC411A06D5 for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 03:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 EEd_2ksZXJWY for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 03:42:43 -0700 (PDT)
Received: from villa.puc.rediris.es (villa.puc.rediris.es [130.206.18.7]) by ietfa.amsl.com (Postfix) with ESMTP id BD30B1A03BA for <ccamp@ietf.org>; Tue, 18 Mar 2014 03:42:42 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ramon.casellas@cttc.es>) id 1WPrTc-0006mj-FY for ccamp@ietf.org; Tue, 18 Mar 2014 11:42:32 +0100
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 715C91FDFD for <ccamp@ietf.org>; Tue, 18 Mar 2014 11:42:28 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <53282314.1040201@cttc.es>
Date: Tue, 18 Mar 2014 11:42:28 +0100
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: ccamp@ietf.org
References: <D7D7AB44C06A2440B716F1F1F5E70AE53FB23DC1@SV-EXDB-PROD1.infinera.com> <OFD8D21453.D491AE4A-ON48257C9F.0023736F-48257C9F.0024039F@zte.com.cn> <C636AF2FA540124E9B9ACB5A6BECCE6B302137BE@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B302137BE@SZXEMA512-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------050707070100020109040305"
X-Spamina-Bogosity: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/7qN-KWn9vLFM6Qh7WoPbWH9I7yU
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: Tue, 18 Mar 2014 10:42:47 -0000
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
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Iftekhar Hussain
- [CCAMP] Draft Text for ITU-T - CCAMP Liason regar… Oscar González de Dios
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Huub van Helvoort
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… fu.xihua
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… fu.xihua
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Jonas Mårtensson
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Zhangxian (Xian)
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Ramon Casellas
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Ramon Casellas
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Fatai Zhang
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Iftekhar Hussain
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Iftekhar Hussain
- [CCAMP] FW: Draft Text for ITU-T - CCAMP Liason r… Zhangxian (Xian)
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Zhangxian (Xian)
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Ramon Casellas
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Iftekhar Hussain
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… BRUNGARD, DEBORAH A
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… Iftekhar Hussain
- Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason r… wang.qilei
- [CCAMP] Final Text ITU-T Liaison flexi-grid // Wa… Ramon Casellas