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

[Loa Andersson <[e-mail]>]

Iftekhar,

The "not getting ahead of ITU definitions are hard to comprehend. Does
it mean that we won't decide on the nuber of bits for m until they have
decided? I'd say that making it 16 bits would accommodate whatever they
ITU comes up with. Would that be getting ahead of ITU definitions?

/Loa

On 2014-02-03 14:07, Iftekhar Hussain wrote:
> 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
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>> ________________________________
>>
>> 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:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]