[CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Ramon Casellas <ramon.casellas@cttc.es> Mon, 10 February 2014 10:34 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 5DC861A06C1 for <ccamp@ietfa.amsl.com>; Mon, 10 Feb 2014 02:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2nk0cPrxiCWd for <ccamp@ietfa.amsl.com>; Mon, 10 Feb 2014 02:34:26 -0800 (PST)
Received: from navarro.puc.rediris.es (navarro.puc.rediris.es [IPv6:2001:720:418:ca01::131]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C41A00AE for <ccamp@ietf.org>; Mon, 10 Feb 2014 02:34:25 -0800 (PST)
Received: from [84.88.62.208] (helo=leo) by navarro.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <ramon.casellas@cttc.es>) id 1WCoC0-0006RA-GT for ccamp@ietf.org; Mon, 10 Feb 2014 11:34:24 +0100
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 9C2E61FE2A for <ccamp@ietf.org>; Mon, 10 Feb 2014 11:34:20 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <52F8AB2D.8090206@cttc.es>
Date: Mon, 10 Feb 2014 11:34:21 +0100
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: ccamp@ietf.org
References: <005901cf1d14$69d2d550$3d787ff0$@olddog.co.uk> <D7D7AB44C06A2440B716F1F1F5E70AE53FB0E5A3@SV-EXDB-PROD2.infinera.com> <52EAFC54.1000507@labn.net> <D7D7AB44C06A2440B716F1F1F5E70AE53FB0FCA1@SV-EXDB-PROD2.infinera.com> <52EFACE3.2080300@labn.net> <D7D7AB44C06A2440B716F1F1F5E70AE53FB10F3A@SV-EXDB-PROD2.infinera.com>
In-Reply-To: <D7D7AB44C06A2440B716F1F1F5E70AE53FB10F3A@SV-EXDB-PROD2.infinera.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Spamina-Bogosity: Ham
Subject: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
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: Mon, 10 Feb 2014 10:34:29 -0000

Dear Iftekhar, All,

Thanks for volunteering to contribute with an initial set of 
requirements. Since I am going through Iftekhar requirements and how to 
map them into the framework document, I would like some clarifications 
(including comments from other authors and contributors). Please, see my 
comments inline


El 08/02/2014 8:46, Iftekhar Hussain escribió:
> R1: Single Frequency Slot Network Connection
> The control plane SHALL be able to support network media channels containing a single frequency slot.
Ramon> Ok.

> R2: Frequency Slot Width Range
>         The control plane protocols SHALL allow flexible range of values for the frequency slot width (m)  parameter. Specifically, the control plane SHALL allow  setting up a network medial channel with frequency slot width (m) ranging from a minimum of 12.5GHz to a maximum of the entire C-band with a slot width granularity of 12.5GHz.
Ramon> Ok.

>
> R3: Finer Granularity Slot Width
> The control plane SHOULD be architected to allow support network media channels with frequency slot width m ranging from a minimum of 6.25GHz to a maximum of the entire C-band with granularity of 6.25GHz
Ramon> I would disagree at this point. I don't know how to map this 
requirement in view of the framework text that defines a slot width with 
a minimum of m=1 for SWG= 12.5 GHz. Like in some requirements below, I 
don't think it is a matter of qualifying with SHALL o SHOULD a given 
capability that sticks / does not stick to the current agreed text.

>
> R4.: Flexible Mapping of Media Channels on the ITU-T defined Flexible Grid
> The control plane SHALL allow mapping of network media channels on any arbitrary nominal central frequency location (i.e., n ) on the ITU defined Flexible Grid.
Ramon> This seems to me that we would be excluding hardware that has 
some constraints related to nominal central granularity. Am I missing 
something?


>
> R5: L-band and S-band
> The control plane architecture SHOULD allow  for  L-band and S-band support.
Ramon> seems ok, any other comment?


>
> R6: Resizing of the Frequency Slot Width
>          The control plane SHALL allow resizing (grow or shrink) frequency slot width of a network media channel. In certain scenarios, the resizing of frequency slot  of a network media channel  MAY cause temporary data plane disruption.
Ramon> My only comment here is whether SHALL or SHOULD. Isn't resizing a 
somehow optional feature w.r.t a minimum set of functions? - I have no 
strong opinion here, quite willing to hear other views.


>
> R7. Network Media Channel Restoration
>        The control plane SHALL support network media channel restorations:
> a)	During the restoration process, the control plane SHALL allow to pick a different frequency slots for the media channel, keeping frequency slot width (m) the same
> b)	During the restoration process, the control plane SHOULD allow changing of m (in coordination with client e.g., needing to change modulation, using different frequency slot width for same capacity to close restoration path)
Ramon> ok
> c)	During the restoration process, the control plane SHOULD allow changing from single frequency slot (m) to multiple frequency slots (e.g., m1, m2) (to deal with blocking / fragmentation on possible restoration paths  where m1 + m2 might be greater than or equal to m
>       d)    Network media channel restoration with optional pre-computed path (with or without resource reservation) SHALL be supported.
>       e)    Revertive and Non-Revertive restoration options SHALL be provided

Ramon> IMHO, we would need to work on this requirement a bit more, from 
a descriptive text perspective, detailing inverse multiplexing of a OTS 
over more than one frequency slot, before adding it as a formal 
requirement. As a general note, I am not in a confident position to tag 
requirements with SHALL/SHOULD. Feedback and comments welcome.


>
> R8: Optical Spectrum Network Usage
> The control plane SHALL be able to keep track of (gather/disseminate) information about optical spectrum usage in the network including (but not limited to):
>      a)      Available Optical Spectral Slices
>     b)      Provisioned Optical Spectral Slices
Ramon> I believe the term slice is undefined. the part regarding routing 
also needs an overhaul in the framework text.  I would be more in favor 
of using the term frequency slot, correct?
>
> R9:  Routing of Optical Signals with Different Modulation Formats
>       The control plane SHALL be capable of placing optical signals with different modulation formats on the Flexible Grid network media channels.

Ramon> We have not addressed anything regarding  modulation formats or 
the signal layer in general. I wonder whether, at this stage, mentioning 
modulation formats explicitly (out of the descriptive text) is appropriate?

>
> R10: Network Media Channels with Multiple Frequency Slots
> The control plane architecture SHALL allow network media channels with multiple contiguous or non-contiguous frequency slots. In this scenario, it SHALL be possible to co-route all frequency slots associated with a given network media channel.
Ramon> The current frawework text, unless mistake from my part, does not 
cover a network media channel over multiple (contiguous or not) 
frequency slots. Should we re-phrase this as a "The control plane 
architecture SHOULD allow multiple media channels to be co-routed and 
logically associated" ?  (editor: I am thinking of association objects, 
or channelsets, etc.)


> R11: Embedded Control Channel for Network Media Channel Routing and Signaling
> The framework SHALL support the standard mechanism for ECC defined in [i.e., OSC based control channel], for OAM features required to be supported between network elements deploying network media channels over Flexible Grid
Ramon> Could you please provide the [i.e., OSC based control channel] 
reference?  I am not sure of making it a SHALL requirement to support 
OSC based control channel. Also, your requirement mentions "network 
media channel routing and signalling" but the text sticks to OAM. Could 
you please clarify?


Thanks again for moving this forwqaa