Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt

Ramon Casellas <ramon.casellas@cttc.es> Tue, 03 March 2015 07:07 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 27E3D1A90D6 for <ccamp@ietfa.amsl.com>; Mon, 2 Mar 2015 23:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 88WpXqb5mtBc for <ccamp@ietfa.amsl.com>; Mon, 2 Mar 2015 23:07:52 -0800 (PST)
Received: from villa.puc.rediris.es (villa.puc.rediris.es [IPv6:2001:720:418:ca00::7]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3F31A90D4 for <ccamp@ietf.org>; Mon, 2 Mar 2015 23:07:51 -0800 (PST)
Received: from [84.88.62.208] (helo=leo) by villa.puc.rediris.es with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <ramon.casellas@cttc.es>) id 1YSgvb-0007h0-Rh; Tue, 03 Mar 2015 08:07:44 +0100
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 37CA71FE10; Tue, 3 Mar 2015 08:07:36 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <54F55DB9.7090102@cttc.es>
Date: Tue, 03 Mar 2015 08:07:37 +0100
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Rajan Rao <rrao@infinera.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
References: <E0C26CAA2504C84093A49B2CAC3261A438C46E2F@SZXEMA504-MBX.china.huawei.com> <E0C26CAA2504C84093A49B2CAC3261A438C5B0E1@SZXEMA504-MBX.china.huawei.com> <2f2dfa0579c44d9f878526197442ae8d@sv-ex13-prd1.infinera.com> <1b93fa3f01e54e78ac7796e70154205b@sv-ex13-prd1.infinera.com> <E0C26CAA2504C84093A49B2CAC3261A438C5FDF5@SZXEMA504-MBX.china.huawei.com> <fda31af8ac0e4bdcb5ba4305239a28aa@sv-ex13-prd1.infinera.com> <4A1562797D64E44993C5CBF38CF1BE4812888A23@ESESSMB301.ericsson.se> <98bf7b4a8a424578bab48c9892aabba1@sv-ex13-prd1.infinera.com> <C636AF2FA540124E9B9ACB5A6BECCE6B4717EFA0@SZXEMA512-MBS.china.huawei.com> <a82fbed51e7c4a0c9f36537f2df92384@sv-ex13-prd1.infinera.com> <C636AF2FA540124E9B9ACB5A6BECCE6B4717F257@SZXEMA512-MBS.china.huawei.com> <b921dd1336ff4bc7b0a3771f52e3fb4b@sv-ex13-prd1.infinera.com> <C636AF2FA540124E9B9ACB5A6BECCE6B47180979@SZXEMA512-MBS.china.huawei.com> <84b74393e892444ab2770fc5327e66d3@sv-ex13-prd1.infinera.com>
In-Reply-To: <84b74393e892444ab2770fc5327e66d3@sv-ex13-prd1.infinera.com>
Content-Type: multipart/alternative; boundary="------------030104040409060409060202"
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -1.0 (-)
X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- 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: ietf.org] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3260] 0.0 HTML_MESSAGE BODY: HTML included in message
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/vfQiT_-7-2NFtPzGfMf9NL1hF7w>
Cc: Iftekhar Hussain <IHussain@infinera.com>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
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, 03 Mar 2015 07:07:55 -0000

Dear all,

Please see inline


El 03/03/2015 a las 1:55, Rajan Rao escribió:
>
> Xian,
>
> Minimum LSP bandwidth will address technological advances. For e.g. 
> tomorrow’s 6.25GHz  instead of today’s 12.5GHz. GMPLS extensions 
> should cover the case of network having a mix of different hardware 
> capabilities. Advertising per priority aligns with RFC4202.  I don’t 
> see any issues.
>
Ramon> I have no objections to adding Min LSP bw if we need it, I just 
want to point out one remark. If I remember correctly, we had discussed 
the issue whether we should be "future-proof" and take into account 
future versions of the flexi-grid, notably, the granularity. In 
particular, the following question was raised:

• 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) for NCFG 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

The reply we got was: 
[https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-23-itu-t-sg-15-ccamp-lsr-on-flexible-grid-reply-to-ietf-ccamp-ls012-attachment-1.pdf]
Currently, there have been no proposals made to Q6/15 to standardize a 
flexible grid with different granularity of slot width or nominal 
central frequency. If such a proposal is made in the future, it is more 
likely that a second flexible grid with different granularity will be 
defined in addition to the existing grid rather than changes made to the 
current flexible grid. (...) If in future a flexible grid with finer 
granularity is introduced, the same 2:1 relationship should not be assumed.

So IMHO, the text gives arguments to mainly limit ourselves to current 
in force documents. That said, I think it is worth considering other 
reasons (if any) to disseminate min-lsp-bw. It may be short-sighted to 
discard the option.

> As far as Maximum LSP bandwidth goes, either option would work but my 
> preference would be to put it in technology specific part (SCSI).
>

> *From:*Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
> *Sent:* Sunday, March 01, 2015 10:35 PM
> *To:* Rajan Rao; CCAMP (ccamp@ietf.org); 'Ramon Casellas'
> *Cc:* Khuzema Pithewan; Iftekhar Hussain; Biao Lu
> *Subject:* RE: [CCAMP] I-D Action: 
> draft-ietf-ccamp-flexible-grid-ospf-ext-01.txt
>
> Hi, Rajan, all,
>

>       Why do we need to advertise Min LSP bandwidth per priority in 
> ISCD, e.g., a request cannot set up a LSP smaller than X GHz and it 
> varies per priority? If you  meant to say the interface limitation, it 
> is covered in Section 4.3 already.
>
Ramon> See above.
>
>       As for the Max LSP bandwidth information, I agree with you that 
> RFC4204 has this requirement. This draft 
> (draft-ietf-ccamp-flexible-grid-ospf-ext-01) needs to be updated to 
> reflect this. I can think of two options:
>
> Option A: use the existing fields (MAX LSP Bandwidth at priority x, 
> x=0-7)  in the ISCD (defined in Section 1.4. of RFC4203). The point 
> that we need to update is the unit to be usable in the context of 
> Flexi-grid. It will be Hz not byte per second.
>
Ramon> I am wary of this one. With the original goal of "separation of 
concerns", we focus on the media layer and usually express optical 
spectrum widths in terms of "m" values. It seems clear that we must not 
talk about bytes per second  (modulation formats spectral efficiency) 
but I would not directly introduce "Hz" (along the minor issues of 
encoding IEEE Giga Hertz  etc.). Also, I am not fully convinced of 
reusing an existing information object and change the unit. In other 
words, IMHO min and max LSP bw values should be stated in terms of "m"s, 
and all fields related to bytes / sec should be set to e.g. zero.


> Option B: We add the max LSP bandwidth field (16 bit) in the Available 
> Labels Field by using the Reserved field.
>
>
Ramon> Are these the only options we have? Although adding the max LSP 
bw field in the reserved field (currently 24 bits, enough) may end up 
being the preferred option, I am not sure why we are discarding adding 
in the ISCD/SCSI new sub TLVs for this purpose, specially if we also 
justify having the min-LSP-bw? I have no strong opinion, but I do agree 
it makes sense to have it in the SCSI.

Thanks and best regards
Ramon