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

["Gabriele Maria Galimberti (ggalimbe)" <[e-mail]>]

Hi All,

I think 16 bits is enough to support any future application (the
granularity would be 0.07GHz.)
Including the 1GHz granularity.

Regards, 

Gabriele



Gabriele Galimberti
Technical Leader
Cisco Photonics Srl


Via Philips, 12
20900 - Monza (MI)
Italy
www.cisco.com/global/IT/ <http://www.cisco.com/global/IT/>

[e-mail]
Phone :[phone]
Mobile :[phone]
Fax :[phone]
















On 2/3/14 10:18 AM, "Huub van Helvoort" <[e-mail]> wrote:

>Hello Zafar,
>
>Do you mean that every time the ITU needs another bit the RFC has to
>be changed, e.g. now define/use 8 bits and in the future 9 or 10...
>
>Regards, Huub.
>
>
>> I agree and don't see any strong reason for why CCAMP should not go with
>> m=16. However, at the moment we can say that usage of only x number of
>> bits is define (to match current DP definition in ITU-T).
>>
>> Thanks
>>
>> Regards … Zafar
>>
>>
>> -----Original Message-----
>> From: "Iftekhar com>" <[e-mail]>
>> Date: Monday, February 3, 2014 1:07 AM
>> To: Daniele Ceccarelli <[e-mail]>, Oscar de Dios
>> <[e-mail]>, "Giovanni Martinelli (giomarti)" <[e-mail]>,
>> "[e-mail]" <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>
>> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
>> Switching Routers
>>
>>> This is a very interesting discussion.  I believe extending the value
>>>of
>>> m to 16-bit makes sense. BTW, that is why in our label definition we
>>>had
>>> proposed a 16-bit for the m to begin with.
>>>
>>> Regarding "why not", all along there has been recurring theme of not
>>> getting ahead of ITU definitions. So I am afraid, we can be selective.
>>> Having said this, if the collective wisdom is to go ahead - that is
>>>fine
>>> with me. But then let us look at all aspects and solutions (routing,
>>> signaling, etc.).
>>>
>>> Regarding the "entire spectrum slot is feasible", I agree. So let us
>>> first start with discussing/capturing this requirement/use case in the
>>> framework document?
>>>
>>> Best regards,
>>> Iftekhar
>>> -----Original Message-----
>>> From: Daniele Ceccarelli [mailto:[e-mail]]
>>> Sent: Friday, January 31, 2014 8:08 AM
>>> To: Oscar González de Dios; Giovanni Martinelli (giomarti); Ramon
>>>Casellas
>>> Cc: CCAMP
>>> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
>>> Switching Routers
>>>
>>>>> My thoughts, exactly, although no strong opinion. I guess the other
>>>>> question would be "why not"?
>>>
>>> +1
>>>
>>> We still have 16 bits reserved...
>>>
>>> BR
>>> Daniele
>>>
>>>> -----Original Message-----
>>>> From: CCAMP [mailto:[e-mail]] On Behalf Of Oscar
>>>> González de Dios
>>>> Sent: venerdì 31 gennaio 2014 17:06
>>>> To: Giovanni Martinelli (giomarti); Ramon Casellas
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC
>>>> Label Switching Routers
>>>>
>>>> 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.
>>>>
>>>>
>>>>   Oscar
>>>>
>>>>
>>>> El 31/01/14 16:47, "Giovanni Martinelli (giomarti)"
>>>> <[e-mail]>
>>>> escribió:
>>>>
>>>>>
>>>>> On 31 Jan 2014, at 16:27, Ramon Casellas <[e-mail]>
>>>> 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
>>>>> GM> 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.
>>>>>
>>>>> Cheers
>>>>> G
>>>>>
>>>>>
>>>>>> 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.
>
>
>-- 
>*****************************************************************
>               请记住，你是独一无二的，就像其他每一个人一样
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp