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

"BRUNGARD, DEBORAH A" <db3546@att.com> Wed, 19 March 2014 18:55 UTC

Return-Path: <db3546@att.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 EF6031A06FD for <ccamp@ietfa.amsl.com>; Wed, 19 Mar 2014 11:55:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.746
X-Spam-Level:
X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 beZlvgoxK_Cf for <ccamp@ietfa.amsl.com>; Wed, 19 Mar 2014 11:55:31 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4E61A042B for <ccamp@ietf.org>; Wed, 19 Mar 2014 11:55:31 -0700 (PDT)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id b18e9235.2b5dae27c940.6980340.00-2461.19598599.nbfkord-smmo06.seg.att.com (envelope-from <db3546@att.com>); Wed, 19 Mar 2014 18:55:23 +0000 (UTC)
X-MXL-Hash: 5329e81b1a54b9db-03320d2a42cfdb1799a8d61afa012c9313f8844e
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 518e9235.0.6980276.00-2141.19598420.nbfkord-smmo06.seg.att.com (envelope-from <db3546@att.com>); Wed, 19 Mar 2014 18:55:20 +0000 (UTC)
X-MXL-Hash: 5329e818263f4d4e-da8237f12241039c3492510a9e227e1e2f0a1218
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2JItHnJ008827; Wed, 19 Mar 2014 14:55:17 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2JIt2uC008560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Mar 2014 14:55:09 -0400
Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 19 Mar 2014 18:54:52 GMT
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0174.001; Wed, 19 Mar 2014 14:54:52 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: Iftekhar Hussain <IHussain@infinera.com>, "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: AQHPPSwcqGay97GfJkiJ4/JTd6KXbZrcCU0AgAAXtHCACPbDAIAAZOSwgAAHvICAAE7GAIAAjaKAgAAx4ACAAB1UAIAAN3EAgAAOyACAALsngIAATdeAgAEDOQD//8FL0A==
Date: Wed, 19 Mar 2014 18:54:51 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C80C16D989@MISOUT7MSGUSR9O.ITServices.sbc.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> <D7D7AB44C06A2440B716F1F1F5E70AE53FB277A1@SV-EXDB-PROD1.infinera.com>
In-Reply-To: <D7D7AB44C06A2440B716F1F1F5E70AE53FB277A1@SV-EXDB-PROD1.infinera.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.16.234.214]
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C80C16D989MISOUT7MSGUSR9O_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=IZIwrxWa c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=wObguHc-6fMA:10 a=ofMgfj31e3cA:10 a=RWEAq7CW3jcA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUA]
X-AnalysisOut: [AAA:8 a=i0EeH86SAAAA:8 a=ZiPXb0p5dJaRMEKap7UA:9 a=QEXdDO2u]
X-AnalysisOut: [t3YA:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=PlUy0ZwTwOMA]
X-AnalysisOut: [:10 a=SgkjiEQe2XYHR_qP:21 a=lQz_KdKpq6vvTott:21 a=yMhMjlub]
X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=rwKldEKW-azWNJ9VzlMA:9 a=gKO2Hq4]
X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU]
X-AnalysisOut: [A:10 a=XjT71mIOvfVXPQCv:21 a=tpCZ0gzv2W626L0Q:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <db3546@att.com>
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/c3guBPUUJi-KukpOu0DK8sDS0w4
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 18:55:35 -0000

Hi,
We need to be careful to ask clarification about management/configuration of the technology, and not appear that we are questioning data plane definitions. Considering G872 says “Note that the apparent containment relationship of the media channels is actually an allocation dependency. No hierarchy is created in either the media channels or the signals carried”, I think we should refrain from saying the media channel is a superset and imply there is no need for the network media channel.

Iftekhar, if you have concerns with these data plane definitions and spectral efficiency, these concerns should be contributed directly to ITU-T.

We need to finish this liaison if we expect to get a response over the next two weeks. I’d suggest on this one to use Xian’s proposal with a slight tweak as the G.872 model is very clear the network media channel supports a single OCh-P network connection.

Propose to say:
“G.872 defines that a media channel may carry more than one OCh-P signal. It also defines that a network media channel is the end-to-end channel allocated to transport a single OCh-P.  We would appreciate clarification on the application of network media channel with respect to media channel with respect to management and configuration aspects.”

Ok?

Thanks,
Deborah

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Iftekhar Hussain
Sent: Wednesday, March 19, 2014 1:59 PM
To: Zhangxian (Xian); Ramon Casellas
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Draft Text for ITU-T - CCAMP Liason regarding Flexi-grid

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<mailto: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<mailto: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<mailto: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