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

Iftekhar Hussain <IHussain@infinera.com> Wed, 19 March 2014 17:58 UTC

Return-Path: <IHussain@infinera.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 542B21A0779 for <ccamp@ietfa.amsl.com>; Wed, 19 Mar 2014 10:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hSePwD929HQK for <ccamp@ietfa.amsl.com>; Wed, 19 Mar 2014 10:58:51 -0700 (PDT)
Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDCB1A042C for <ccamp@ietf.org>; Wed, 19 Mar 2014 10:58:51 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0174.001; Wed, 19 Mar 2014 10:58:42 -0700
From: Iftekhar Hussain <IHussain@infinera.com>
To: "Zhangxian (Xian)" <zhang.xian@huawei.com>, Ramon Casellas <ramon.casellas@cttc.es>
Thread-Topic: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
Thread-Index: AQHPQkxtwHQNFaGUKU2KbhNzE13MpJrnX2QwgADH3YCAAQMwMA==
Date: Wed, 19 Mar 2014 17:58:42 +0000
Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE53FB277A1@SV-EXDB-PROD1.infinera.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> <C636AF2FA540124E9B9ACB5A6BECCE6B30213972@SZXEMA512-MBS.china.huawei.com>
In-Reply-To: <C636AF2FA540124E9B9ACB5A6BECCE6B30213972@SZXEMA512-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.96.93]
Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE53FB277A1SVEXDBPROD1infi_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/WdKfGbynJ-VxOrFk9NkilkNzAVM
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 17:58:54 -0000

Hi Xian and Ramon,
Personally I don’t see anything wrong in the text asking for a clarification on this ambiguity of a standard. However, if abbreviating the text will get the question across more clearly and get the required clarification, I am okay to use text suggested by Xian with small addition.
“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 and media channel given that a media channel is a superset and can support the network media channel functionality. ”
Thanks,
Iftekhar
From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: Tuesday, March 18, 2014 7:31 PM
To: Iftekhar Hussain; Ramon Casellas
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

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