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

Iftekhar Hussain <IHussain@infinera.com> Tue, 18 March 2014 21:52 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 0FC6F1A030F for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 14:52:32 -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 9ziGjFI-vKeM for <ccamp@ietfa.amsl.com>; Tue, 18 Mar 2014 14:52:28 -0700 (PDT)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83E1A040E for <ccamp@ietf.org>; Tue, 18 Mar 2014 14:52:27 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0174.001; Tue, 18 Mar 2014 14:52:19 -0700
From: Iftekhar Hussain <IHussain@infinera.com>
To: Ramon Casellas <ramon.casellas@cttc.es>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid
Thread-Index: AQHPQkxtwHQNFaGUKU2KbhNzE13MpJrnX2Qw
Date: Tue, 18 Mar 2014 21:52:19 +0000
Message-ID: <D7D7AB44C06A2440B716F1F1F5E70AE53FB2643D@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>
In-Reply-To: <53282314.1040201@cttc.es>
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_D7D7AB44C06A2440B716F1F1F5E70AE53FB2643DSVEXDBPROD1infi_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/xB1W7qeqcDKzCVILDMO_ArvwU9w
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 21:52:32 -0000

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