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

"Giovanni Martinelli (giomarti)" <> Fri, 31 January 2014 15:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A49B81A0522 for <>; Fri, 31 Jan 2014 07:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RAatseTvrBfL for <>; Fri, 31 Jan 2014 07:47:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0665E1A0367 for <>; Fri, 31 Jan 2014 07:47:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2380; q=dns/txt; s=iport; t=1391183222; x=1392392822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=c1WfCkt9fAbtIk77HvbP/SxUsmEgb+Lwd5yu9iiGMes=; b=NLvt8IXToumfZfy3nX87jmp/fCNtSjOGj2yWcXwR6zZB7MqQvpB0XuDJ 6zlgQNDKBClpsMSU4AzwwHiC3TZOmukMtVBjccx1ESq+k/HeY+IqFiuc6 m8T02Z9jbPnpDMtknlAuRT05e34VWIe1a9X39g6Ooh/LsAwqOVYFE70eP 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.95,758,1384300800"; d="scan'208";a="300984973"
Received: from ([]) by with ESMTP; 31 Jan 2014 15:47:02 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s0VFl2P0001312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jan 2014 15:47:02 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 31 Jan 2014 09:47:01 -0600
From: "Giovanni Martinelli (giomarti)" <>
To: Ramon Casellas <>
Thread-Topic: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
Thread-Index: AQHPHo0/fGbjWdhXDUqKr14iKNSXdJqfWVOAgAAFhIA=
Date: Fri, 31 Jan 2014 15:47:01 +0000
Message-ID: <>
References: <005901cf1d14$69d2d550$3d787ff0$> <> <061c01cf1e79$cfb6e620$6f24b260$> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP <>
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jan 2014 15:47:08 -0000

On 31 Jan 2014, at 16:27, Ramon Casellas <> wrote:

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

GM> is not mere reuse but future protocol compatibility.  Sounds to me that’s better to allocate few more bits know than looking for them in the future. Btw, to answer Loa doubts, there’s no idea about how using reserved bits right now. 


> 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 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. 
> _______________________________________________
> CCAMP mailing list