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

Ramon Casellas <ramon.casellas@cttc.es> Wed, 04 March 2015 09:30 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 225841A1A90 for <ccamp@ietfa.amsl.com>; Wed, 4 Mar 2015 01:30:17 -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 k_tOT1AAdQ6e for <ccamp@ietfa.amsl.com>; Wed, 4 Mar 2015 01:30:15 -0800 (PST)
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 B17E21A0A6A for <ccamp@ietf.org>; Wed, 4 Mar 2015 01:30:14 -0800 (PST)
Received: from [2001:40b0:7c22:6020:201a:bdd4:94e5:83cc] (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 1YT5d3-0006ML-T1; Wed, 04 Mar 2015 10:30:10 +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 3401D1FF01; Wed, 4 Mar 2015 10:30:07 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <54F6D09E.80507@cttc.es>
Date: Wed, 04 Mar 2015 10:30:06 +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>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Zhangxian (Xian)'" <zhang.xian@huawei.com>, 'CCAMP' <ccamp@ietf.org>
References: <005c01d055c9$03433cf0$09c9b6d0$@olddog.co.uk> <3820eb23b0a747ea9ff95e1a830d0676@sv-ex13-prd1.infinera.com>
In-Reply-To: <3820eb23b0a747ea9ff95e1a830d0676@sv-ex13-prd1.infinera.com>
Content-Type: multipart/alternative; boundary="------------080504060101080408080908"
X-Spamina-Bogosity: Unsure
X-Spamina-Spam-Score: -1.0 (-)
X-Spamina-Spam-Report: Content analysis details: (-1.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -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.3394] 0.0 HTML_MESSAGE BODY: HTML included in message
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/quf6mtirNSPe7uPcQTuv5dl8ILI>
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: Wed, 04 Mar 2015 09:30:17 -0000

El 04/03/2015 a las 2:11, Rajan Rao escribió:
>
> Adrian,
>
> Looks like there is different interpretation of RFC 4202 text.  RFC 4202 text in sections 2.4.2 & 2.4.3  says
> “…..an LSP at priority
>
>   p could reserve any bandwidth between the Minimum LSP Bandwidth and
>
>    the Maximum LSP Bandwidth at priority p, provided that the 
> bandwidth…..”
>
> Having only the Maximum LSP bandwidth field priority based & not the 
> Minimum LSP bandwidth field doesn’t seem right.  It is a 
> simplification for sure.  What is the correct interpretation of above 
> text?  Will be good to know.
>

Rajan, all

It is a good question, and in my humble opinion, there are different 
things (echoing Adrian's questions):

i) Whether RFC4202 text could imply that Minimum LSP bandwidth is a 
function of priority (p)

ii) The need for a priority-dependent Minimum LSP bandwidth (and, in 
particular, for flexi-grid networks) in view of the requirements of 
preemption, resource usage, etc. This is to me the most important point.

iii) The actual encoding (in terms of "m" or Hz, in the ISCD SCSI ...)

For ii) it would be good to clearly agree on the requirement (let's 
stick to current in-force grid definitions). Personally, I see that 
higher priorities are allowed higher values of Max LSP bandwidth, but 
when would you need that a lower priority LSP is allowed a lower minimum 
value (or, similiarly, why would I constraint high priority LSPs to not 
use lower LSP bandwidths?). I have no objection to work on iii) if ii) 
is clear.


Although IMHO not critical, for i) It is my understanding that the 
minimum LSP bandwidth is unique across priorities, and only the Maximum 
LSP bandwidth depends on the priority. RFC4202
- An interface may have more than one Interface Switching Capability 
Descriptor.  This is used to handle interfaces that support multiple 
switching capabilities, for interfaces that have Max LSP Bandwidth 
values that differ by priority level, and for interfaces that support  
discrete bandwidths. // Only Max is mentioned
- For a simple (unbundled) link, the Maximum LSP Bandwidth at priority p 
is defined to be (...) // there is no such definition for minimum "at 
priority p".
- The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP could 
reserve // it does not mention "at priority p" and is ISCD specific.
- an LSP at  priority p could reserve any bandwidth (...) by the Minimum 
LSP Bandwidth and the Maximum LSP Bandwidth at priority p. // It is my 
understanding that Minimum LSP Bandwidth refers to the actual definition 
in point 2, i.e., bw(p) = [min_lsp_bw, max_lsp_bw(p)]
- Actual OSPF-TE extensions (e.g. for PSC) where min_lsp_bw is unique.