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

Oscar González de Dios <> Fri, 31 January 2014 16:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F10C1A1F5F for <>; Fri, 31 Jan 2014 08:05:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.437
X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1jS2sXcWi6Od for <>; Fri, 31 Jan 2014 08:05:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EF3811A1F1A for <>; Fri, 31 Jan 2014 08:05:54 -0800 (PST)
Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet []) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N0900BW4WPPHF@tid.hi.inet> for; Fri, 31 Jan 2014 17:05:50 +0100 (MET)
Received: from vanvan (vanvan.hi.inet []) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 96.9E.05896.DD9CBE25; Fri, 31 Jan 2014 17:05:50 +0100 (CET)
Received: from (mailhost.hi.inet []) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0N0900BVVWPPHF@tid.hi.inet> for; Fri, 31 Jan 2014 17:05:49 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Fri, 31 Jan 2014 17:05:49 +0100
Date: Fri, 31 Jan 2014 16:05:48 +0000
From: Oscar González de Dios <>
In-reply-to: <>
X-Originating-IP: []
To: "Giovanni Martinelli (giomarti)" <>, Ramon Casellas <>
Message-id: <>
Content-id: <675804B03D88B442A5E8EF45C1D32E98@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-language: es-ES
Content-transfer-encoding: quoted-printable
Accept-Language: es-ES, en-US
Thread-topic: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers
Thread-index: AQHPHo1DDBMGqArkrEiH8ma0g7/pdJqe4/uAgAAFg4CAABYDAA==
user-agent: Microsoft-MacOutlook/
X-AuditID: 0a5f4e69-b7f778e000001708-e9-52ebc9ddd4e2
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1L138nWQwclHbBZP5txgcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrylv9gKbklXPDw+lbWB8YpYFyMnh4SAicTDPxOZIGwxiQv3 1rN1MXJxCAlsY5TYuGUFlPODUeJowwN2CGcao8T8LXNZQFpYBFQlVn1rAWtnE3CQWLeoF6iD g0NYIFrizyxmkDCngK3E7pbjUBsUJP6cewzWKiKQIvHoZyMriM0sICWx630PO4jNK6AtcXXy J3aIuJnEvXknoOKCEj8m32OBiOtI9H7/xgxhi0vM+TURao62xJN3F8BsRgFZiZXnTzNC7IqR WHN1GjPIaSICThJzTuuBhEUF9CTajp1hhzhNQGLJnvPMELaoxMvH/1gnMErMQnLFLCRXzEJy xSwkV8xCcsUCRtZVjGLFSUWZ6RkluYmZOekGRnoZmXqZeaklmxghUZe5g3H5TpVDjAIcjEo8 vDPTXgUJsSaWFVfmHmKU4GBWEuHlKnsdJMSbklhZlVqUH19UmpNafIiRiYNTqoExasoUe7aP Czae+Vm+YM2+owcXqB/uPLztr2RE6fLtW1cqn7/ZKyAm+mtmtWep2uY3z3mesaWtOcr4YccE x2fBzgZBbyRkchYXOZ+U2PPrjUWI+tLda6zMlqX6eM18KnBObv/ktMenZ6yV2f8zIcPnzYeb miutl4n6l1pMD13WeHfiX75s3/+sXEosxRmJhlrMRcWJAB/LTviYAgAA
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 16:05:58 -0000

Hi, my 2 cents...

  With the encoding, you should be able to describe a frequency slot as
big as the whole spectrum available in the band. If 8 bits (that give a
width of 1593,75 GHz using the granularity of 6,25) is not enough, then it
MUST be extended to a bigger value. The flexi-grid framework allows a
hierarchy of frequency slots, so the ³entire spectrum² slot is feasible
and in line with current ITU recommendations. We are not saying a single
signal uses that amount of spectrum.


El 31/01/14 16:47, "Giovanni Martinelli (giomarti)" <>

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


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: