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

From: Iftekhar Hussain <[email-masked]>
Date: Mon, 3 Feb 2014 06:07:48 +0000

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:[email-masked]] 
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:[email-masked]] 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)" 
> <[email-masked]>
> escribió:
> 
> >
> >On 31 Jan 2014, at 16:27, Ramon Casellas <[email-masked]> 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
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >
> >_______________________________________________
> >CCAMP mailing list
> >[email-masked]
> >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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Loa Andersson <[email-masked]>
Date: Mon, 03 Feb 2014 14:39:25 +0800

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 3 Feb 2014 07:59:45 +0000

Hi:

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>" <[email-masked]>
Date: Monday, February 3, 2014 1:07 AM
To: Daniele Ceccarelli <[email-masked]>, Oscar de Dios
<[email-masked]>, "Giovanni Martinelli (giomarti)" <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 03 Feb 2014 16:15:26 +0800

Zafar,

Do you imply that we might need more than 16 bits???

/Loa

--

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 03 Feb 2014 10:18:36 +0100

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.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 3 Feb 2014 13:29:38 +0000

Hi- 

I am happy if we don't need to do so. But is this not better than
defining/ extending a new label format when ITU-T changes the data plane?

Thanks

Regards … Zafar

-----Original Message-----
From: Huub van Helvoort <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Monday, February 3, 2014 4:18 AM
To: zali <[email-masked]>, "Iftekhar com>" <[email-masked]>,
Daniele Ceccarelli <[email-masked]>, Oscar de Dios

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 03 Feb 2014 14:33:15 +0100

> defining/ extending a new label format when ITU-T changes the data plane?

Dear all,

I may be missing something (apologies in advance if it is the case) and 
since I don't have them here right now, for the sake of this discussion, 
maybe could anyone point to the relevant part of the document(s) e.g. 
G.694.1 / G.872 etc. where it is said that the value of m is bound to 256?
We are aware of the concept of frequency slot, nominal central 
frequencies (n, and their values) and the concept of frequency slot 
width, but I cannot recall now such a bound.

Thanks
R.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 3 Feb 2014 13:27:45 +0000

No Loa, I mentioned m = 16.

Thanks

Regards … Zafar

-----Original Message-----
From: Loa Andersson <[email-masked]>
Date: Monday, February 3, 2014 3:15 AM
To: zali <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
Switching Routers

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 3 Feb 2014 10:34:23 +0000

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/>

[email-masked]
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 03 Feb 2014 15:25:46 +0100

Hola Ramon,

G.694.1 does not define a maximum value for "m".

However G.697 gives in Appendix V.1: Wavelength ID.
"m" = 9 bits (m is encoded as a 9-bit unsigned integer).

Regards, Huub.

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 3 Feb 2014 14:34:09 +0000

I agree Ramon, 

I didn't see any constraints WRT m values.
In any case, if there are constraints, the idea is to submit a proposal to
ITU-T to extend m coding to 16 bits.

Best Regards, 

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

[email-masked]
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Mon, 3 Feb 2014 14:48:21 +0000

Thanks Huub,

At this point we have to options:

1) update the IETF draft to m = 9 bits  (note this m value range covers
the whole spectrum if the granularity is 12.5GHz.)
2) propose to ITU-T Q6 to amend the G.697 (m from 9 to 16 bits) and modify
the IETF draft to m = 16 bits.

Regards, 

Gabriele

Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy

[email-masked]
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 Feb 2014 11:18:46 -0000

I think I see a general set of agreements coming along.

Appendix V.1 gives an example of needing 9 bits to encode m.
Although an Appendix is not part of the normative spec, we might assume two things from this appendix:
1. Currently only up to 8 bits are needed
2. The is a trend toward more than 8 bits

As Gabriele suggests, 16 bits is a lot. So I don't think we need to worry about extensibility if we go there.

I will update the I-D to make m 16 bits wide, and I will (continue to) say that the definition of m is per the slot width formula defined in G.694.1. This makes no comment within the draft on the legitimate values of m, but defers the data plane specification to the ITU-T.

As to describing such things in the framework, I would be opposed to an IETF document that describes the flexi-grid data plane in any detail. That is, IMNSHO, not our remit and not the scope of CCAMP. But we could ask the AD for an opinion on that ;-)

A

> From: CCAMP [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: 03 February 2014 14:26
> To: Ramon Casellas; Oscar González de Dios
> Cc: CCAMP

---

From: Loa Andersson <[email-masked]>
Date: Tue, 04 Feb 2014 19:31:06 +0800

All,

16 bits and deferring the specification of of dataplane specifiction to
the Recommendation seems quite reasonable.

/Loa

--

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Wed, 5 Feb 2014 09:37:32 +0000

btw sorry for being pedantic, G.697 Appendix V.1 state a 32 bits wavelength ID. So are we already buying a larger dress?

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 05 Feb 2014 10:57:00 +0100

> btw sorry for being pedantic, G.697 Appendix V.1 state a 32 bits wavelength ID. So are we already buying a larger dress?

For what concerns me, I just see this appendix as a place in which an 
explicit encoding for "m" (the value of slot width) is given, hopefully 
giving some idea of the range of values that are "acceptable". I did not 
draw any other analogy between that appendix and label format (be in 
WSON or SSON)

R.

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 05 Feb 2014 11:12:58 +0100

Hola Ramon,

You replied:

>> btw sorry for being pedantic, G.697 Appendix V.1 state a 32 bits
>> wavelength ID. So are we already buying a larger dress?
>

I agree with you.
An Appendix in G.697 is informative and not normative.
It is an example. The fact that 9 bits are used for "m" in this
example indicates that IMHO 8 bits for "m" is not enough.
So 16 bits is a "future proof" value.
Any other value between 8 and 16 is not useful, the remaining
unused bits in a byte will be sent anyway.

Regards, Huub.