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

From: "Daniel King" <[email-masked]>
Date: Wed, 29 Jan 2014 18:06:12 +0100

Hi CCAMP'rs,

The authors are planning a revision of this I-D before London, but the only
changes will be the addition of an Implementation Status section as per
RFC6982.

It seems to us that this I-D is stable and that there are no further
technical issues. The label format documented in the I-D has been picked up
by the RSVP-TE extensions draft and the ongoing OSPF work. 

We would like to take this opportunity to solicit feedback from the working
group:

- Are there any changes you would like to see in the draft? 
- Are you happy with the label format described? 
- What do you think the next steps should be for this draft?

Thanks,
Dan (for the authors)

---

From: Iftekhar Hussain <[email-masked]>
Date: Thu, 30 Jan 2014 23:26:01 +0000

Hi Dan,

Thanks for the update. In my view, there are number of areas which still needs to be addressed in the framework document (e.g., control plane requirements) before we move toward solution drafts.

BR,
Iftekhar
-----Original Message-----
From: Daniel King [mailto:[email-masked]] 
Sent: Wednesday, January 29, 2014 9:06 AM
To: 'CCAMP'
Subject: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Hi CCAMP'rs,

The authors are planning a revision of this I-D before London, but the only changes will be the addition of an Implementation Status section as per RFC6982.

It seems to us that this I-D is stable and that there are no further technical issues. The label format documented in the I-D has been picked up by the RSVP-TE extensions draft and the ongoing OSPF work. 

Thanks,
Dan (for the authors)

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jan 2014 20:28:52 -0500

Iftekhar,

Speaking purely from a process standpoint: adoption is the start of work
on a topic, not a codification of an end state.  This is why we
typically ask if a document reflects a "good starting point for WG
activity" when discussing the adoption of a draft.

Again, speaking from a general perspective, I certainly don't think the
process requires discussion/adoption to be blocked while a framework (or
even requirement) document has some open points.

Lou

On January 30, 2014 6:26:40 PM Iftekhar Hussain <[email-masked]>
wrote:

> Hi Dan,
>
> Thanks for the update. In my view, there are number of areas which still 
> needs to be addressed in the framework document (e.g., control plane 
> requirements) before we move toward solution drafts.
>
> BR,
> Iftekhar
> From: Daniel King [mailto:[email-masked]] Sent: Wednesday, January 29, 
> 2014 9:06 AM
> To: 'CCAMP'
> - Are there any changes you would like to see in the draft? - Are you happy 
> with the label format described? - What do you think the next steps should 
> be for this draft?
>
> Thanks,
> Dan (for the authors)
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 31 Jan 2014 10:35:07 +0000

Hi Daniel 

I have a change request on the label:

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0  1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Grid | C.S.  |    Identifier      |               n                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       m     |                     Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I'd like to extend the m value range to 16 bits to have the possibility to
Allocate the whole C-band spectrum if needed.
With 8 bits we can allocate only 60% of it.
Another reason is that when new technologies will be available the
Slot Width Granularity may increase (to 6.25GHz or better).

So the proposed change is:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0  1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Grid | C.S. |    Identifier    |                n              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                m              |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 m field = 16 bits.

Best 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: "Adrian Farrel" <[email-masked]>
Date: Fri, 31 Jan 2014 11:44:30 -0000

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.

Thoughts?
Adrian

> From: CCAMP [mailto:[email-masked]] On Behalf Of Gabriele Maria
> Galimberti (ggalimbe)
> Sent: 31 January 2014 10:35
> To: Daniel King; 'CCAMP'
> Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label
Switching
> Routers

---

From: Loa Andersson <[email-masked]>
Date: Fri, 31 Jan 2014 22:03:23 +0800

Adrian,

Do you say that even though the size required Q6/15 would fit in 8 bits
we can as well reserve 16 bits now to make sure that we can expand in
the future.

I do not have any problem with that, unless there is a intended use of
the reserved field.

/Loa

-- 

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

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 31 Jan 2014 16:27:17 +0100

> I do not have any problem with that, unless there is a intended use of
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).

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

---

From: "Gabriele Maria Galimberti (ggalimbe)" <[email-masked]>
Date: Fri, 31 Jan 2014 15:46:48 +0000

Hi Adrian,

Thanks for the clarification.
If We talk about the the slot with granularity specified by G.694.1
To be 12.5GHz, I agree that we have to wait any ITU feedback.
On the other hand I don't see any constraint of Spectrum Width
Size in G.694.1.  So there is no specification/limitation to m value.

In this sense I'd agree with Ramon: why not extend it.

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

On 1/31/14 12:44 PM, "Adrian Farrel" <[email-masked]> wrote:

>> >technical issues. The label format documented in the I-D has been
>>picked
>> >up

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 31 Jan 2014 15:47:01 +0000

On 31 Jan 2014, at 16:27, Ramon Casellas <[email-masked]> wrote:

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

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
>

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 31 Jan 2014 15:54:37 +0000

Hi Dan,

a comment from my side. Nothing precluding the draft to progress but having the m value in the label make me thinking.

I know there was lots of discussion in the past and likely the result is somewhat described section 4.2 however the use case I have in mind is when an established flex-lsp (hence a w/ flexgrid labels)  needs to be enlarged/shrinked. This operation implies a label value change. 

Now, does this consideration needs room in this draft /within framework /nowhere? I don’t have strong opinion just throwing a doubt on the table.

Cheers
G

---

From: Oscar González de Dios <[email-masked]>
Date: Fri, 31 Jan 2014 16:05:48 +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.

 Oscar

El 31/01/14 16:47, "Giovanni Martinelli (giomarti)" <[email-masked]>
escribió:

>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.
>
>Cheers
>G
>
>

________________________________

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 31 Jan 2014 16:08:02 +0000

>>question would be "why not"?

+1

We still have 16 bits reserved...

BR
Daniele

> 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
> Switching Routers
>   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
> 
> 
> >>> I do not have any problem with that, unless there is a intended use
> >>> of the reserved field.
> >>>
> >> Loa, Adrian, all,
> >>
> >> 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).
> >>
> >
> >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
> >
> >
> >>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
> >>
> >>>> 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.
> 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:

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 31 Jan 2014 12:01:36 -0500

In message <[email-masked]>
Lou Berger writes:
 
> Iftekhar,
>  
> Speaking purely from a process standpoint: adoption is the start of
> work on a topic, not a codification of an end state.  This is why we
> Again, speaking from a general perspective, I certainly don't think
> the process requires discussion/adoption to be blocked while a
> framework (or even requirement) document has some open points.
>  
> Lou

Lou, Iftekhar,

I don't see this as a request to block progress.

Perhaps Iftekhar (or someone) could first outline the control plane
requirements and "other areas" that need to be addressed and suggest
text to address them in the framework.

Curtis