Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Ramon Casellas <ramon.casellas@cttc.es> Fri, 31 January 2014 15: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 970331A02DF for <ccamp@ietfa.amsl.com>; Fri, 31 Jan 2014 07:27:26 -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 WWsBN_d8fmdB for <ccamp@ietfa.amsl.com>; Fri, 31 Jan 2014 07:27:24 -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 914AB1A02DA for <ccamp@ietf.org>; Fri, 31 Jan 2014 07:27:24 -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 1W9G00-0004ns-8H for ccamp@ietf.org; Fri, 31 Jan 2014 16:27:20 +0100
Received: from [84.88.61.50] (unknown [84.88.61.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 111A01FE2A for <ccamp@ietf.org>; Fri, 31 Jan 2014 16:27:15 +0100 (CET)
X-Envelope-From: ramon.casellas@cttc.es
Message-ID: <52EBC0D5.3030009@cttc.es>
Date: Fri, 31 Jan 2014 16:27:17 +0100
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: ccamp@ietf.org
References: <005901cf1d14$69d2d550$3d787ff0$@olddog.co.uk> <CF11374C.56B52%ggalimbe@cisco.com> <061c01cf1e79$cfb6e620$6f24b260$@olddog.co.uk> <52EBAD2B.3040704@pi.nu>
In-Reply-To: <52EBAD2B.3040704@pi.nu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Spamina-Bogosity: Ham
Subject: Re: [CCAMP] 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: Fri, 31 Jan 2014 15:27:26 -0000

El 31/01/2014 15:03, Loa Andersson escribió:
> Adrian,
>
> I do not have any problem with that, unless there is a intended use of
> the reserved field.
>
Loa, Adrian, all,

My thoughts, exactly, although no strong opinion. I guess the other 
question would be "why not"?
If, as Adrian mentions, we constrain the its use as defined in G.694.1 
while leaving room for growth, at least the encoding would be more 
likely be reused (as opposed to the WSON -> SSON).

For what is worth, individual drafts that are considering extending 
RSVP-TE for signaling media channels would also be affected. The 
underlying idea is to propose new types for the sender template and the 
flowspec in the flow descriptor to accommodate for the requested and 
allocated slot width. Right now, only the "m" parameter is encoded with 
the corresponding padding/reserved bytes.

Regards,
Ramon

PS: much like Adrian's draft, the label encoding proposed in 
http://tools.ietf.org/html/draft-li-ccamp-flexible-grid-label-00 also 
took into account the fact that a reduced number of bits would suffice 
to cover G.694.1

> On 2014-01-31 19:44, Adrian Farrel wrote:
>> Hi Gabriele,
>>
>> IIRC this topic has come up in various discussions.
>> I think the discussion ran aground when we tried to understand what 
>> ITU-T SG15
>> Q6 data plane capabilities this increased value of "m" modelled.
>>
>> I believe that we could easily increase the size of the m field, but 
>> as I
>> understand the status of the Q6 work, we would still need to 
>> constrain its use
>> as defined in G.694.1. Maybe that is the best compromise: it gives us 
>> scope for
>> future expansion, but it makes (for now) the value strictly limited 
>> according to
>> the current definition of the data plane we are controlling.