Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Jonas Mårtensson <Jonas.Martensson@acreo.se> Wed, 20 May 2015 12:51 UTC

Return-Path: <Jonas.Martensson@acreo.se>
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 B61C61A0115 for <ccamp@ietfa.amsl.com>; Wed, 20 May 2015 05:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 cauEjsrmEtFa for <ccamp@ietfa.amsl.com>; Wed, 20 May 2015 05:51:22 -0700 (PDT)
Received: from smtp301-outgoing.stejtech.net (smtp301.stejtech.net [IPv6:2001:67c:27e0:2212::5301]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B692F1A0121 for <ccamp@ietf.org>; Wed, 20 May 2015 05:51:18 -0700 (PDT)
X-Spam-STAY-ID: v=2.0 cv=atIw+FlV c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=dBZgz0PQq4UA:10 a=xqWC_Br6kY4A:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=hZG83p_yAAAA:8 a=DiyQPNL_zmzEgXyKQ84A:9 a=wPNLvfGTeEIA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=ewTqpK25P96tV11YlpgA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp301.stejtech.net (Postfix) with ESMTPSA id 0D4FC196194F; Wed, 20 May 2015 14:51:14 +0200 (CEST)
Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.03.0210.002; Wed, 20 May 2015 14:51:13 +0200
From: Jonas Mårtensson <Jonas.Martensson@acreo.se>
To: Ramon Casellas <ramon.casellas@cttc.es>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd
Thread-Index: AdCAxt9X5E05ipNNTWCBtB1iqh4XcgLE00wAABLQzYAAfE4sAAEtqgIQ///qtAD//9RWQIAAU8GA///H9HA=
Date: Wed, 20 May 2015 12:51:13 +0000
Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C290CC98@ACREOEXC02.ad.acreo.se>
References: <4A1562797D64E44993C5CBF38CF1BE48128F2479@ESESSMB301.ericsson.se> <5550A8BC.4090005@labn.net> <9D50FCE7413E3D4EA5E42331115FB5BC29C85B6B@xmb-rcd-x03.cisco.com> <55546934.8070806@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C76A@ACREOEXC02.ad.acreo.se> <555C3FC6.80106@cttc.es> <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se> <555C6167.4070101@cttc.es>
In-Reply-To: <555C6167.4070101@cttc.es>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.4.144.165]
Content-Type: multipart/alternative; boundary="_000_7ECED07E132D4B4F89DCC0FDA683C6C290CC98ACREOEXC02adacreo_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/31yxUOixeVRrYiafobP4eVngOAQ>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd
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, 20 May 2015 12:51:27 -0000

A)  <Available Central Frequency Granularity> ::= p x 6.25GHz

"A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed."

Still... I don't really see a good reason why you would exclude those values (which are compliant with G.694.1) at this point... More generally, I think an information model should describe the needed information, not necessarily limit values representing the information (that could be done in a future encoding draft).

Anyway, and sorry if I confuse things even more, it seems to me that what you actually want to capture with the information model is available center frequencies and slot widths, not the granularities per se. Granularities are one way to represent available values but how to represent those could be left for a future encoding draft. So a more general information model could be:

<Available Spectrum> ::=
       <Available Frequency Range-List>
       <Available Central Frequencies>
       <Available Slot Widths>

<Available Central Frequencies> ::= the subset of supported n values (where n is defined as in G.694.1)

<Available Slot Widths> ::= the subset of supported m values (where m is defined as in G.694.1)

If you want to go one step further and limit how to represent these subsets by introducing granularities (and possibly offsets but that is maybe unnecessarily complex) you could have:

<Available Central Frequencies> ::=
        <Available Central Frequency Granularity>
        <Offset>

One possible representation would be to say that available center frequencies are the subset of supported n values given by p x n + q where p (granularity) is a positive integer and q (offset) belongs to 0,..,q-1.

<Available Slot Widths> ::=
        <Available Slot Width Granularity>
        <Min Slot Width>
        <Max Slot Width>

/Jonas

From: Ramon Casellas [mailto:ramon.casellas@cttc.es]
Sent: den 20 maj 2015 12:27
To: Jonas Mårtensson; ccamp@ietf.org
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd



i.e. "n" and "m" were changed to "2^n" and "2^m" but it still said that "n" and "m" were positive integers which is wrong. The new formulas (even if n,m = 0 is included) also change the available granularities but I assume this was intended (I was not involved).
Jonas, all

Let's try to re-visit this again and come up with some definitive text. I also wonder about:

* the need to introduce formulas or similar o just provide a list of acceptable values.
* whether a single value captures the intended model attribute (e.g. granularity is X) or multiple values are acceptable.

IMHO: we should ideally list the acceptable values and capture common deployments, rather than exotic configurations such as "this node only supports ncf of 6.25 if between this frequency and that frequency and 25 otherwise, or it can support width granulaties of x,y,z depending on ...)

ITU rec is not extremely helpful, and only provides main guidelines: ITU-T Rec G.694.1 ( http://www.itu.int/rec/T-REC-G.694.1-201202-I/en ) states Appendix I: "The flexible DWDM grid defined in clause 7 has a nominal central frequency granularity of 6.25 GHz and a slot width granularity of 12.5 GHz. However, devices or applications that make use of the flexible grid may not have to be capable of supporting every possible slot width or position. In other words, applications may be defined where only a subset of the possible slot widths and positions are required to be supported. For example, an application could be defined where the nominal central frequency granularity is 12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a multiple of 25 GHz (by only requiring values of m that are even)."



For nominal central frequency granularity
=========================================
we had:

A) <Available Central Frequency Granularity> ::= p x 6.25GHz
B) <Available Central Frequency Granularity> ::= (2^p) x 6.25GHz for p>=0

Typically, values used for this (in fixed grid)  "The frequency grid defined by this Recommendation supports a variety of fixed channel spacings ranging from 12.5 GHz to 100 GHz and wider (integer multiples of 100 GHz) as well as a flexible grid. Uneven channel spacings using the fixed grids are also allowed." Note that in section 6, values with n=0 are used as reference for all the grids. IOW, we are implying that the granularity is given wrt n=0.

A) yields 6.25, 12.5, 18.75, 25.0, 31.25, etc... a list of values that are not necessarily common or deployed.
B) yields 6.25, 12.5, 50.0, 100, 200, 400... it fails to capture the "integer multiples of 100",

Questions:
Q1: should we cover values above 100/200 ? if yes, B) fails.
Q2: do we need to explictly mention that granularity itself is not enough without mentioning a "reference/anchor" NCF that is not n=0? do we assume that n=0 is always available and the granularity is always wrt to it -- relying on the " <Available Frequency Range-List> " to complete this information?"


For nominal central frequency granularity
=========================================
we had :
C) <Available Slot Width Granularity> ::= q x 12.5GHz
D) <Available Slot Width Granularity> ::= (2^q) x 12.5GHz q>= 0

C) yields 12.5, 25, 37.5, 50, 62.5, 75
D) yields  12.5, 25, 50, 100, 200, 400,

D) is excluding restrictions such as "frequency slots with m=3 (37.5 GHz)" so I am not sure it is ok if we want to cover those. It seems safer to stick to C) imho

For available frequency range
==========================================
In -03, -04



   <Available Frequency Range> ::=

     ( <Start Spectrum Position> <End Spectrum Position> ) |

     <Sets of contiguous slices>

I don't like neither the use of "position" nor the use of the undefined term "slice"

Proposed text
=====================



<Available Central Frequency Granularity> ::=

    A value from within the list 6.25GHz, 12.5GHz, 25GHz, 50GHz, 100GHz, 200GHz, 300GHz, 400GHz...

    -- Note that the granularity is defined with respect to anchor frequency given by n=0



<Available Slot Width Granularity> ::=

    A value from within the list defined by q x 12.5GHz where q is a positive integer (q>0)

    -- It is the minimum slot width that can be defined



<Available Frequency Range> ::=

     ( <Start Nominal Central Frequency> <End Nominal Central Frequency> ) |

       <A frequency slot defined by its n and m contaning a set of contiguous nominal central frequencies>



Any comments? Yes/no? suggested alternatives?  much appreciated :)

Thanks

Ramon