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

Ramon Casellas <ramon.casellas@cttc.es> Wed, 19 March 2014 06:50 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 3E3091A04F1 for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 23:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.345
X-Spam-Level:
X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no
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 V7rZ_8QSdXAY for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 23:50:51 -0700 (PDT)
Received: from rudy.puc.rediris.es (unknown [IPv6:2001:720:418:ca01::140]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE601A0395 for <ccamp@ietf.org>; Tue, 18 Mar 2014 23:50:51 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by rudy.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ramon.casellas@cttc.es>) id 1WQAKl-0000iM-08; Wed, 19 Mar 2014 07:50:39 +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 EEFE41FF83; Wed, 19 Mar 2014 07:50:01 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <53293E19.2080806@cttc.es>
Date: Wed, 19 Mar 2014 07:50:01 +0100
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Iftekhar Hussain <IHussain@infinera.com>, "ccamp@ietf.org" <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> <53282314.1040201@cttc.es> <D7D7AB44C06A2440B716F1F1F5E70AE53FB2643D@SV-EXDB-PROD1.infinera.com>
In-Reply-To: <D7D7AB44C06A2440B716F1F1F5E70AE53FB2643D@SV-EXDB-PROD1.infinera.com>
Content-Type: multipart/alternative; boundary="------------030102020405030908050003"
X-Spamina-Bogosity: Ham
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/MwfZOig_G2gbgiuxGEIo4SqKrMg
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 06:50:54 -0000

El 18/03/2014 22:52, Iftekhar Hussain escribió:
>
> 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"
>
>

Iftekhar, all

Following several comments received, your text was edited in past 
versions of the liaison draft. I would be ok to leave the text as is in 
the liaison if the working group agrees or does not object. However, I 
still wonder what kind of clarification/question do we need from the 
ITU-T (in such text), related the control plane protocol requirements 
and extensions.

Like Xian, I am also slightly afraid that the last bullet may be 
basically challenging the definition of the network media channel, 
something that is, IMHO, ITU-T business. Im am also reluctant to use a 
wording that seems to be issuing direct recommendations to ITU-T whether 
this or that term is required or whether this or that entity should 
support this or that capability or whether it would be too restrictive. 
That said, I may be completely wrong, and I am just editing :-)

Thanks
R.


-- 
Ramon Casellas, Ph.D. -- Senior Research Associate -- Networks Division
Optical Networks and Systems Department -- http://networks.cttc.es/ons
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya
Parc Mediterrani de la Tecnologia (PMT) - Edifici B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 ext 2168-- Fax. +34 93 645 29 01