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

Ramon Casellas <ramon.casellas@cttc.es> Wed, 20 May 2015 10:27 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 310481B3660 for <ccamp@ietfa.amsl.com>; Wed, 20 May 2015 03:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.3
X-Spam-Level:
X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 MxvBuuFtoUb0 for <ccamp@ietfa.amsl.com>; Wed, 20 May 2015 03:27:11 -0700 (PDT)
Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929C81B35CC for <ccamp@ietf.org>; Wed, 20 May 2015 03:27:10 -0700 (PDT)
Received: from [84.88.62.208] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <ramon.casellas@cttc.es>) id 1Yv1DH-0001bL-7l; Wed, 20 May 2015 12:27:00 +0200
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 27CE41FD05; Wed, 20 May 2015 12:26:55 +0200 (CEST)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <555C6167.4070101@cttc.es>
Date: Wed, 20 May 2015 12:26:47 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Jonas Mårtensson <Jonas.Martensson@acreo.se>, "ccamp@ietf.org" <ccamp@ietf.org>
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>
In-Reply-To: <7ECED07E132D4B4F89DCC0FDA683C6C290C959@ACREOEXC02.ad.acreo.se>
Content-Type: multipart/alternative; boundary="------------090700050202090906010305"
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -0.2 (/)
X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: itu.int] 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4996]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/whitxut9ksvZBmYCLfujv273ECI>
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 10:27:13 -0000

> 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 byq 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