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 08:52 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 BB83C1A1AE6 for <ccamp@ietfa.amsl.com>; Wed, 20 May 2015 01:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_FORM=2.3, 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 sQHyFey_rcCY for <ccamp@ietfa.amsl.com>; Wed, 20 May 2015 01:52:36 -0700 (PDT)
Received: from smtp304-outgoing.stejtech.net (smtp304.stejtech.net [IPv6:2001:67c:27e0:2212::5304]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAAA01A1A9F for <ccamp@ietf.org>; Wed, 20 May 2015 01:52:35 -0700 (PDT)
X-Spam-STAY-ID: v=2.0 cv=R+OB6KtX c=1 sm=0 a=fpfCo9GHTwTpwwPQDU8l2g==:17 a=dBZgz0PQq4UA:10 a=xqWC_Br6kY4A:10 a=h1PgugrvaO0A:10 a=48vgC7mUAAAA:8 a=k5Tf46Y5WNoERa5XVNwA:9 a=wPNLvfGTeEIA:10 a=QiUDj9SLOcNwOKlf:21 a=9l_7OMhDL6n5QtVy:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=u3KKLRwlgC032Lp_mGMA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=UBZuAtqXqftS4hJh:21 a=sC27VrhxhJXEUj7C:21
Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp304.stejtech.net (Postfix) with ESMTPSA id 8F51628205F; Wed, 20 May 2015 10:52:26 +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 10:52:25 +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//9RWQA==
Date: Wed, 20 May 2015 08:52:24 +0000
Message-ID: <7ECED07E132D4B4F89DCC0FDA683C6C290C959@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>
In-Reply-To: <555C3FC6.80106@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_7ECED07E132D4B4F89DCC0FDA683C6C290C959ACREOEXC02adacreo_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/6agEO9JCmnxTcCI_JKFQ9Qo12gc>
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 08:52:42 -0000

"In other words, I guess that the text before latest changes was ok, barred the unfortunate choice of names. But I would like to request for comments on this. Or maybe I am making things worse :)"

Older versions had:

<Available Central Frequency Granularity> ::= n x 6.25GHz

<Available Slot Width Granularity> ::= m x 12.5GHz

In -03 it was instead:

<Available Central Frequency Granularity> ::= (2^n) x 6.25GHz

<Available Slot Width Granularity> ::= (2^m) x 12.5GHz

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).

Anyway, I agree with your suggestion to use different parameter names (p and q) for specifying granularities to reduce risk for confusion.

/Jonas

From: Ramon Casellas [mailto:ramon.casellas@cttc.es]
Sent: den 20 maj 2015 10:03
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

El 20/05/2015 a las 9:29, Jonas Mårtensson escribió:
Hi Ramon,

4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.
Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot.

How do you figure that? Doesn't

<Available Slot Width Granularity> ::= (2^m) x 12.5GHz

imply that the available SWGs start at 25 GHz if "m" is positive integer?


Hi Jonas,

True, I think you spotted an error; in any case there is significant room for confusion, and now I regret that the model in section 4.8.4 uses "n" and "m" mixing the ITU-T definitions and the variables in the formulas themselves to describe granularities.

- The parameter m is defined by ITU G.694.1 "a slot width defined by: 12.5 × m where m is a positive integer and 12.5 is the slot width granularity in GHz."
- The parameter n is defined 193.1 + n × 0.00625 where n is a positive or negative integer including  0, parameter to describe nominal central frequencies (for which n can be indeed negative).
- Unfortunately both are used to describe granularities in the model and are not the same concepts.

In the formulas, both are ok using 0.
I would suggest this (using p and q). IMHO, we will need to upload a -05 asap.



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

     where p is a non negative integer, giving rise to granularities

     such as 6.25GHz, 12.5GHz, 25GHz, 50GHz, and 100GHz



   <Available Slot Width Granularity> ::= (2^q) x 12.5GHz

     where q is a non negative integer

In other words, I guess that the text before latest changes was ok, barred the unfortunate choice of names. But I would like to request for comments on this. Or maybe I am making things worse :)

R.



/Jonas

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Ramon Casellas
Sent: den 14 maj 2015 11:22
To: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexi-grid-fwk-03 and call for sheperd

Dear Matt, all

Thank you very much for the review and comments, please see inline (aligned with Adrian's reply).

For what is worth, there were some comments that I received post LC, that will also be in next updated version.


El 12/05/2015 a las 0:02, Matt Hartley (mhartley) escribió:
All,

I've reviewed this revision of the document, and I think it's almost ready for publication. I have a few comments (below) but I don't think there's any major issues.

3.1: definition of OTN could be moved up to section 2.2, if you want.
Ramon> Added as acronym, and removed the expansion, thank you



3.2.1: you state that the Nominal Central Frequency Granularity is 6.25GHz, but there's no reference for this. I assume it's in an ITU doc somewhere? If so, it'd be good to say so (and where)
Ramon> Indeed. Much like SWG being 12.5GHz, added [G.694.1]



The document refers to "OTSi signals" in several places, but the definition of "OTSi" includes "signal" :) I don't know whether or not this is normal usage or whether it's worth fixing... but it looks technically wrong to me (like people talking about "PIN numbers" whenever they get cash out of the bank).

Ramon> changed OTSi signals to OTSi



3.2.5, first bullet: "This group of OTSi should be carried over a single fibre." Is that a normal English should, or a 2219 SHOULD? If the former, it might be worth rephrasing to avoid ambiguity.
Ramon> changed to "are" as per Adrian's suggestion



4.2: "The association of the three components a filter, a fiber, and a filter, is a media channel in its most basic form.". It'd be nice to clarify that this is a fiber with a filter at each end - that's not immediately obvious on first reading, especially with the diagram that makes it clear on the next page.

Ramon> Likewise, changed to "association sequence"



The paragraph below figure 8 is... unclear. Is it just trying to say that media channels can be joined together to make a new media channel? Or is there more to it than that?

Ramon> Basically the intent is that one, although it should reflect more to the join of "basic" media channels (defined as an association sequence of filter-fiber-filter as above). This, and the architectural construct being an LSP.  Changed to also use the term "association sequence"

OLD



   Additionally, when a cross-connect for a specific frequency slot is

   considered, the underlying media support is still a media channel,

   augmented, so to speak, with a bigger association of media elements

   and a resulting effective slot.  When this media channel is the

   result of the association of basic media channels and media layer

   matrix cross-connects, this architectural construct can be

   represented as (i.e., corresponds to) a Label Switched Path (LSP)

   from a control plane perspective.  In other words, It is possible to

   "concatenate" several media channels (e.g., Patch on intermediate

   nodes) to create a single media channel.

NEW



   Additionally, when a cross-connect for a specific frequency slot is

   considered, the resulting media support of joining basic media channels

   is still a media channel, i.e., a longer association sequence of media

   elements and its effective frequency slot. In other words, It is possible to

   "concatenate" several media channels (e.g., patch on intermediate

   nodes) to create a single media channel.



   The architectural construct resulting of the association sequence

   of basic media channels and media layer matrix cross-connects can be

   represented as (i.e., corresponds to) a Label Switched Path (LSP)

   from a control plane perspective.




Fig 12: OTSi trail? Did you mean OCh trail?
Ramon> The error comes from the text, since the correct term is OTSi.

OLD



   In Figure 12 a Network Media Channel is represented as terminated at

   the DWDM side of the transponder.  This is commonly named as OCh-

   trail connection.


NEW



   In Figure 12 a Network Media Channel is represented as terminated at

   the network side of the transponders.  This is commonly named as OTSi-

   trail connection.




Fig 14: MLN/MRN needs explaining. Or removing.
Ramon> Removed.



4.3, towards the end: "there must be enough guard band between adjacent OTSis in any media channel to compensate filter concatenation effect and other effects caused by signal layer switching elements". Maybe "...to compensate for the filter concatenation effect and..." or "...to compensate for filter concatenation effects and..."?

Ramon> new text
"there must be  enough guard band between adjacent OTSis in any media channel to  compensate for the filter concatenation effects and other effects caused by signal layer switching elements"



4.8.4: bear in mind that 0 is not a positive integer, and it looks like the definitions involving (2^n) and (2^m) are intended to include the case where n/m is 0.
Ramon> Changed for "n" to say "non-negative integer". For "m", I am leaving it as positive integer, since m=0 would imply an empty frequency slot.


If no further comments, I will proceed to upload these changes for -04 (with other backlogged changes such as affiliation changes, CCAMP WG, Informational, nits, editorial changes , typos, etc. ). Please see the attached diff


Thanks
Ramon