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

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

Lou,

 Understood. All powers to the process.

 I felt that there is  insufficient use cases/requirements discussion/coverage in the framework document at this moment. We need more active discussion inputs from wider CCAMP group. Otherwise, I don't see why we have not been looking at the solution documents for a long time. 

If we are ready to look at solutions in the Flexible Grid area, the authors of the IDs ("Generalized Label for Super-Channel Assignment on Flexible Grid" and 
"OSPFTE extension to support GMPLS for Flex Grid") are  planning to make updates (possibly before the next IETF):

a)  Terminology alignment (replace the term "Super-Channel" with an appropriate alternate term/definition based on last IETF meeting discussion)
b)  Clearly separate out the label solution draft into a "single frequency slot" and "multiple frequency slots" cases. Note the single frequency slot case is in alignment with ITU frequency slot (m,n) definitions except  m field is 16-bit field).
c) Some terminology related updates in the OSPF draft. BTW, we believe, this is one of the earliest solution drafts for flexgrid related OSPF extensions.

We also would like to solicit feedback from the working and the next steps for these drafts.

Best regards,
Iftekhar
-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, January 30, 2014 5:29 PM
To: Iftekhar Hussain; Daniel King; 'CCAMP'
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

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
> -----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.
> 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)
>
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: Lou Berger <[email-masked]>
Date: Mon, 03 Feb 2014 09:51:15 -0500

Iftekhar,
	See in-line.

On 2/3/2014 2:15 AM, Iftekhar Hussain wrote:
> I felt that there is  insufficient use cases/requirements
> discussion/coverage in the framework document at this moment. We need
> more active discussion inputs from wider CCAMP group. 

> Otherwise, I
> don't see why we have not been looking at the solution documents for
> a long time.

As a general statement, I see no reason not to be discussing solution
documents. I believe I already said this to you in our Berlin session
where we had basically this exact same exchange.

> "OSPFTE extension to support GMPLS for Flex Grid") are  planning to make updates (possibly before the next IETF):

Please do! -- my main objective to jumping in on this thread is to
ensure that all are bringing their technical contributions/input to the
discussion.

> We also would like to solicit feedback from the working and the next steps for these drafts.

In addition to bringing your drafts forward, I'd also suggest that you
respond to your own message to the list (the one included below) and
provide some substance behind your comment to Dan.  (And yes, I'm
agreeing with Curtis ;-)

Thanks and see you in London!

Lou

---

From: Iftekhar Hussain <[email-masked]>
Date: Sat, 8 Feb 2014 07:46:43 +0000

Lou,

Agree with your and Curtis comments. Here is an suggested outline for the control plane requirements section of the framework WG document.

R1: Single Frequency Slot Network Connection
The control plane SHALL be able to support network media channels containing a single frequency slot.

R2: Frequency Slot Width Range
       The control plane protocols SHALL allow flexible range of values for the frequency slot width (m)  parameter. Specifically, the control plane SHALL allow  setting up a network medial channel with frequency slot width (m) ranging from a minimum of 12.5GHz to a maximum of the entire C-band with a slot width granularity of 12.5GHz. 

R3: Finer Granularity Slot Width
The control plane SHOULD be architected to allow support network media channels with frequency slot width m ranging from a minimum of 6.25GHz to a maximum of the entire C-band with granularity of 6.25GHz

R4.: Flexible Mapping of Media Channels on the ITU-T defined Flexible Grid
The control plane SHALL allow mapping of network media channels on any arbitrary nominal central frequency location (i.e., n ) on the ITU defined Flexible Grid.

R5: L-band and S-band
The control plane architecture SHOULD allow  for  L-band and S-band support.

R6: Resizing of the Frequency Slot Width
        The control plane SHALL allow resizing (grow or shrink) frequency slot width of a network media channel. In certain scenarios, the resizing of frequency slot  of a network media channel  MAY cause temporary data plane disruption.

R7. Network Media Channel Restoration
      The control plane SHALL support network media channel restorations:
a)	During the restoration process, the control plane SHALL allow to pick a different frequency slots for the media channel, keeping frequency slot width (m) the same
b)	During the restoration process, the control plane SHOULD allow changing of m (in coordination with client e.g., needing to change modulation, using different frequency slot width for same capacity to close restoration path)
c)	During the restoration process, the control plane SHOULD allow changing from single frequency slot (m) to multiple frequency slots (e.g., m1, m2) (to deal with blocking / fragmentation on possible restoration paths  where m1 + m2 might be greater than or equal to m
     d)    Network media channel restoration with optional pre-computed path (with or without resource reservation) SHALL be supported.
     e)    Revertive and Non-Revertive restoration options SHALL be provided

R8: Optical Spectrum Network Usage
The control plane SHALL be able to keep track of (gather/disseminate) information about optical spectrum usage in the network including (but not limited to):
    a)      Available Optical Spectral Slices
   b)      Provisioned Optical Spectral Slices

R9:  Routing of Optical Signals with Different Modulation Formats
     The control plane SHALL be capable of placing optical signals with different modulation formats on the Flexible Grid network media channels.

R10: Network Media Channels with Multiple Frequency Slots
The control plane architecture SHALL allow network media channels with multiple contiguous or non-contiguous frequency slots. In this scenario, it SHALL be possible to co-route all frequency slots associated with a given network media channel.

R11: Embedded Control Channel for Network Media Channel Routing and Signaling
The framework SHALL support the standard mechanism for ECC defined in [i.e., OSC based control channel], for OAM features required to be supported between network elements deploying network media channels over Flexible Grid

Thanks,
Iftekhar

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Monday, February 03, 2014 6:51 AM
To: Iftekhar Hussain; Daniel King; 'CCAMP'
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Iftekhar,
	See in-line.

> Otherwise, I
> don't see why we have not been looking at the solution documents for a 
> long time.

As a general statement, I see no reason not to be discussing solution documents. I believe I already said this to you in our Berlin session where we had basically this exact same exchange.

> If we are ready to look at solutions in the Flexible Grid area, the 
> authors of the IDs ("Generalized Label for Super-Channel Assignment on Flexible Grid" and "OSPFTE extension to support GMPLS for Flex Grid") are  planning to make updates (possibly before the next IETF):

Please do! -- my main objective to jumping in on this thread is to ensure that all are bringing their technical contributions/input to the discussion.

> 
> a)  Terminology alignment (replace the term "Super-Channel" with an 
> appropriate alternate term/definition based on last IETF meeting 
> discussion)

In addition to bringing your drafts forward, I'd also suggest that you respond to your own message to the list (the one included below) and provide some substance behind your comment to Dan.  (And yes, I'm agreeing with Curtis ;-)

Lou

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

---

From: Iftekhar Hussain <[email-masked]>
Date: Sat, 8 Feb 2014 08:32:58 +0000

Dan,

As a follow up to my earlier , I have provided an outline of control plane requirements for the framework WG document.

 I would like you to bring to your attention that there is another individual draft ("Generalized Label for Super-Channel Assignment on Flexible Grid")  that also defines Flexible Grid label. 

***************************************************************************
Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers:

Label Encoding:

Grid field (3) bit
C.S field (3) bit
Identifier (9) bit
n (16-bit)            - ITU Frequency slot n parameter
m (8-bit)             - ITU Frequency slot m parameters
***************************************************************************

####################################################################################
Generalized Label for Super-Channel Assignment on Flexible Grid

Label Encoding (option A): For Single Frequency Slot Case

Grid (3-bit)   - same meaning as in your draft
S.S (3-bit)     - same meaning  as in your draft.
n (16-bit)      - same meaning as in your draft
m (16-bit)     - same meaning except that it is 16-bit in this draft and is 8-bit in yours

Super-Channel ID (16-bt) - Note we plan to rename this field in the next revision. Open for discussion on this field.
Number of Entries (16-bit): For the single frequency slot case - Open for discussion

######################################################################################

The authors of "Generalized Label for Super-Channel Assignment on Flexible Grid" believe there is lot of similarities between the two label definitions for the single frequency slot case.  Please take a look and see whether the two can be merged for the single frequency slot case. 

Thanks,
Iftekhar
-----Original Message-----
From: Iftekhar Hussain 
Sent: Thursday, January 30, 2014 3:26 PM
To: 'Daniel King'; 'CCAMP'
Subject: RE: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

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. 

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: "Zhangxian (Xian)" <[email-masked]>
Date: Sat, 8 Feb 2014 10:36:04 +0000

Hi, Giovanni, 

  When we resize a LSP, the label value needs to change for sure in transport networks. An example would be OTN and captured in Section 7 of draft-ietf-ccamp-gmpls-signaling-g709v3-12. The procedure described/cited there should also be applicable to resizing a LSP in flexi-grid as well, if I understand correctly. The difference is, in OTN the data plane can support hitless adjustment of the bandwidth, thus the need of explanation of interaction of both planes; not sure it is the case for flexi grid at the moment. So, I wonder if change a bandwidth of a flex-lsp means taking the steps of tearing down the old one and establishing a new one, thus already supported by RFC3209 from control plane perspective? 

  I think we are discussing some advanced issues and currently won't be needed in solutions drafts. If needed, a note may be added somewhere to the framework draft. Thoughts?

Regards,
Xian  

-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Giovanni Martinelli (giomarti)
Sent: 2014年1月31日 23:55
To: Daniel King
Cc: CCAMP
Subject: Re: [CCAMP] Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

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

On 29 Jan 2014, at 18:06, Daniel King <[email-masked]> wrote:

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

---

From: Ramon Casellas <[email-masked]>
Date: Mon, 10 Feb 2014 11:34:21 +0100

Dear Iftekhar, All,

Thanks for volunteering to contribute with an initial set of 
requirements. Since I am going through Iftekhar requirements and how to 
map them into the framework document, I would like some clarifications 
(including comments from other authors and contributors). Please, see my 
comments inline

> The control plane SHALL be able to support network media channels containing a single frequency slot.
Ramon> Ok.

>         The control plane protocols SHALL allow flexible range of values for the frequency slot width (m)  parameter. Specifically, the control plane SHALL allow  setting up a network medial channe…
Ramon> Ok.

> The control plane SHOULD be architected to allow support network media channels with frequency slot width m ranging from a minimum of 6.25GHz to a maximum of the entire C-band with granularity of 6…
Ramon> I would disagree at this point. I don't know how to map this 
requirement in view of the framework text that defines a slot width with 
a minimum of m=1 for SWG= 12.5 GHz. Like in some requirements below, I 
don't think it is a matter of qualifying with SHALL o SHOULD a given 
capability that sticks / does not stick to the current agreed text.

> The control plane SHALL allow mapping of network media channels on any arbitrary nominal central frequency location (i.e., n ) on the ITU defined Flexible Grid.
Ramon> This seems to me that we would be excluding hardware that has 
some constraints related to nominal central granularity. Am I missing 
something?

> The control plane architecture SHOULD allow  for  L-band and S-band support.
Ramon> seems ok, any other comment?

>          The control plane SHALL allow resizing (grow or shrink) frequency slot width of a network media channel. In certain scenarios, the resizing of frequency slot  of a network media channel  M…
Ramon> My only comment here is whether SHALL or SHOULD. Isn't resizing a 
somehow optional feature w.r.t a minimum set of functions? - I have no 
strong opinion here, quite willing to hear other views.

> b)	During the restoration process, the control plane SHOULD allow changing of m (in coordination with client e.g., needing to change modulation, using different frequency slot width for same capaci…
Ramon> ok
>       e)    Revertive and Non-Revertive restoration options SHALL be provided

Ramon> IMHO, we would need to work on this requirement a bit more, from 
a descriptive text perspective, detailing inverse multiplexing of a OTS 
over more than one frequency slot, before adding it as a formal 
requirement. As a general note, I am not in a confident position to tag 
requirements with SHALL/SHOULD. Feedback and comments welcome.

>     b)      Provisioned Optical Spectral Slices
Ramon> I believe the term slice is undefined. the part regarding routing 
also needs an overhaul in the framework text.  I would be more in favor 
of using the term frequency slot, correct?
>       The control plane SHALL be capable of placing optical signals with different modulation formats on the Flexible Grid network media channels.

Ramon> We have not addressed anything regarding  modulation formats or 
the signal layer in general. I wonder whether, at this stage, mentioning 
modulation formats explicitly (out of the descriptive text) is appropriate?

> The control plane architecture SHALL allow network media channels with multiple contiguous or non-contiguous frequency slots. In this scenario, it SHALL be possible to co-route all frequency slots…
Ramon> The current frawework text, unless mistake from my part, does not 
cover a network media channel over multiple (contiguous or not) 
frequency slots. Should we re-phrase this as a "The control plane 
architecture SHOULD allow multiple media channels to be co-routed and 
logically associated" ?  (editor: I am thinking of association objects, 
or channelsets, etc.)

> The framework SHALL support the standard mechanism for ECC defined in [i.e., OSC based control channel], for OAM features required to be supported between network elements deploying network media c…
Ramon> Could you please provide the [i.e., OSC based control channel] 
reference?  I am not sure of making it a SHALL requirement to support 
OSC based control channel. Also, your requirement mentions "network 
media channel routing and signalling" but the text sticks to OAM. Could 
you please clarify?

Thanks again for moving this forwqaa

---

From: Oscar González de Dios <[email-masked]>
Date: Wed, 12 Feb 2014 14:46:55 +0000

Dear Iftekhar, Ramon, all

        Further comments inline

>>         The control plane protocols SHALL allow flexible range of
>>values for the frequency slot width (m)  parameter. Specifically, the
>>control plane SHALL allow  setting up a network medial channel with
>>frequency slot width (m) ranging from a minimum of 12.5GHz to a maximum
>>of the entire C-band with a slot width granularity of 12.5GHz.
>Ramon> Ok.
>
>>
>> The control plane SHOULD be architected to allow support network media
>>channels with frequency slot width m ranging from a minimum of 6.25GHz
>>to a maximum of the entire C-band with granularity of 6.25GHz
[Oscar] I do not fully understand the requirement as it is written. Do you
mean having, instead of a granularity of 12,5, have other values for the
SWG? Current granularity is set to 12,5 (full stop). There has been a set
of emails in
the ccamp mailing list questioning the need of including a field
Indicating the slot width granularity, and I have not seen agreement yet.
Gabriele reported Optical Modules with very fine granularity, 1 GHz.

Maybe it is a question to ask our dear ITU data plane folks, whether
different
SWG are envisioned. In such case, I will be more than happy to include it
as a requirement. Otherwise, I would rather drop it at present.

>> The control plane SHALL allow mapping of network media channels on any
>>arbitrary nominal central frequency location (i.e., n ) on the ITU
>>defined Flexible Grid.
[Oscar] Maybe a set of requirements can be added to the document
regarding feasible combinations of n and m in the hardware.

>>          The control plane SHALL allow resizing (grow or shrink)
>>frequency slot width of a network media channel. In certain scenarios,
>>the resizing of frequency slot  of a network media channel  MAY cause
>>temporary data plane disruption.
[Oscar] It is necessary to add the data plane disruption here? What does
it imply for the control plane? At least, I would like that the change of m
(I guess that is the kind of resizement you refer to) should be hitless
in terms of control plane.

>> a)   During the restoration process, the control plane SHALL allow to
>>pick a different frequency slots for the media channel, keeping
>>frequency slot width (m) the same
>> b)   During the restoration process, the control plane SHOULD allow
>>changing of m (in coordination with client e.g., needing to change
>>modulation, using different frequency slot width for same capacity to
>>close restoration path)
>Ramon> ok
>> c)   During the restoration process, the control plane SHOULD allow
>>changing from single frequency slot (m) to multiple frequency slots
>>(e.g., m1, m2) (to deal with blocking / fragmentation on possible
>>restoration paths  where m1 + m2 might be greater than or equal to m
>>       d)    Network media channel restoration with optional
>>pre-computed path (with or without resource reservation) SHALL be
>>supported.
>> The control plane SHALL be able to keep track of (gather/disseminate)
>>information about optical spectrum usage in the network including (but
>>not limited to):
>>       The control plane SHALL be capable of placing optical signals
>>with different modulation formats on the Flexible Grid network media
>>channels.
>
>> The control plane architecture SHALL allow network media channels with
>>multiple contiguous or non-contiguous frequency slots. In this scenario,
>>it SHALL be possible to co-route all frequency slots associated with a
>>given network media channel.
[Oscar] Agree with Ramon, one minor comment: The 'logical association' of
media channels has no name yet. Do we ask ITU for a term on that? Do we
use an already existing IETF term?

>> The framework SHALL support the standard mechanism for ECC defined in
>>[i.e., OSC based control channel], for OAM features required to be
>>supported between network elements deploying network media channels over
>>Flexible Grid

[Oscar] We (Ramon and me), as editors of the document, will incorporate
the requirements that have an agreement and publish them for a new
version. Please consider commenting on the set of requirements proposed by
Iktekhar and/or add more requirements.

Best Regards,

    Oscar

________________________________

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: Iftekhar Hussain <[email-masked]>
Date: Thu, 13 Feb 2014 02:16:57 +0000

Please see few comments in-line.

-----Original Message-----
From: Oscar González de Dios [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 6:47 AM
To: Ramon Casellas; [email-masked]
Subject: Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

        Further comments inline

>(including comments from other authors and contributors). Please, see 
>my comments inline
>
>
>> R1: Single Frequency Slot Network Connection  The control plane SHALL 
>>be able to support network media channels containing a single 
>>frequency slot.
>Ramon> Ok.
>
>>frequency slot width (m) ranging from a minimum of 12.5GHz to a 
>>maximum of the entire C-band with a slot width granularity of 12.5GHz.
>Ramon> Ok.
>
>>
>> The control plane SHOULD be architected to allow support network 
>>media channels with frequency slot width m ranging from a minimum of 
>>6.25GHz to a maximum of the entire C-band with granularity of 6.25GHz
>requirement in view of the framework text that defines a slot width 
>with a minimum of m=1 for SWG= 12.5 GHz. Like in some requirements 
>below, I don't think it is a matter of qualifying with SHALL o SHOULD a 
>given capability that sticks / does not stick to the current agreed text.
[Oscar] I do not fully understand the requirement as it is written. Do you mean having, instead of a granularity of 12,5, have other values for the SWG? Current granularity is set to 12,5 (full stop). There has been a set of emails in the ccamp mailing list questioning the need of including a field Indicating the slot width granularity, and I have not seen agreement yet.
Gabriele reported Optical Modules with very fine granularity, 1 GHz.

Maybe it is a question to ask our dear ITU data plane folks, whether different SWG are envisioned. In such case, I will be more than happy to include it as a requirement. Otherwise, I would rather drop it at present.

[Iftekhar] Yes, I meant finer granularity than 12.5GHz.  

Thanks,
Iftekhar

>
>>
>> R4.: Flexible Mapping of Media Channels on the ITU-T defined Flexible 
>>Grid  The control plane SHALL allow mapping of network media channels 
>>on any arbitrary nominal central frequency location (i.e., n ) on the 
>>ITU defined Flexible Grid.
[Oscar] Maybe a set of requirements can be added to the document regarding feasible combinations of n and m in the hardware.

>Ramon> My only comment here is whether SHALL or SHOULD. Isn't resizing 
>Ramon> a
[Oscar] It is necessary to add the data plane disruption here? What does it imply for the control plane? At least, I would like that the change of m (I guess that is the kind of resizement you refer to) should be hitless in terms of control plane.

>Ramon> I believe the term slice is undefined. the part regarding 
>Ramon> routing
>the signal layer in general. I wonder whether, at this stage, 
>mentioning modulation formats explicitly (out of the descriptive text) 
>is appropriate?
>
>>
>> R10: Network Media Channels with Multiple Frequency Slots  The 
>>control plane architecture SHALL allow network media channels with 
>>multiple contiguous or non-contiguous frequency slots. In this 
>>scenario, it SHALL be possible to co-route all frequency slots 
>>associated with a given network media channel.
>Ramon> The current frawework text, unless mistake from my part, does 
>Ramon> not
[Oscar] Agree with Ramon, one minor comment: The 'logical association' of media channels has no name yet. Do we ask ITU for a term on that? Do we use an already existing IETF term?

>
>
>> R11: Embedded Control Channel for Network Media Channel Routing and 
>>Signaling  The framework SHALL support the standard mechanism for ECC 
>>defined in [i.e., OSC based control channel], for OAM features 
>>required to be supported between network elements deploying network 
>>media channels over Flexible Grid

[Oscar] We (Ramon and me), as editors of the document, will incorporate the requirements that have an agreement and publish them for a new version. Please consider commenting on the set of requirements proposed by Iktekhar and/or add more requirements.

Best Regards,

    Oscar

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 28 Feb 2014 09:38:25 +0000

Hi, Iftekhar, Ramon, Oscar,

    Thank you all for the good discussion. Please see my further thoughts inline, marked with [Xian]: 
    
-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Oscar González de Dios
Sent: 2014年2月12日 22:47
To: Ramon Casellas; [email-masked]
Subject: Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

        Further comments inline

>>of the entire C-band with a slot width granularity of 12.5GHz.
[Xian]: I think it is also possible that a device support a range smaller than C-band. If you all agree, then probably can modify the above statement slightly, such as:
"Specially, the control plane SHALL allow setting up a media channel from a minimum frequency slot width (e.g., 12.5GHz) to a maximum value supported by a node (e.g., the entire C-band)."

[Xian]: Agree with Oscar's proposal; better than asking instead of guessing, :-). So, I assume we do not need anything added in the fwk draft unless we get positive feedbacks from ITU experts.

>>Grid

[Xian] I concur with Ramon. Even in the appendix of G.694.1, it states the following: 

" The flexible DWDM grid defined in Clause 7 has a nominal central frequency granularity of 
6.25 GHz and a slot width granularity of 12.5 GHz. However, devices or applications that make use 
of the flexible grid may not have to be capable of supporting every possible slot width or position. 
In other words, applications may be defined where only a subset of the possible slot widths and 
positions are required to be supported. 
For example, an application could be defined where the nominal central frequency granularity is 
12.5 GHz (by only requiring values of n that are even) and that only requires slot widths as a 
multiple of 25 GHz (by only requiring values of m that are even)."

So I think we should not write a too strong requirement.

>Ramon> seems ok, any other comment?

[Xian]: Could we be a bit more specific? Cite a reference to give reader the hint of the range supported or just say it explicitly? 

[Xian]: My understanding is whether the resizing is hit or hitless is a data plane feature, *not* on a requirement or feature of the control plane. Please correct me if I am wrong. 

So from control plane point of view, changing the size of LSP is a generic function fulfilled by RFC3209 already, i.e., tearing down the old and establishing the new one. Unless we see new requirements about flexi-grid resizing, I do not see it is a particular requirement to flexi-grid. So when discussing among authors of the fwk draft, I do not see the need to write such a requirement. But after a second thought, I think it make senses to add this requirement. However, I reckon existing mechanism will suffice. So, I would suggest to follow the framework of WSON / OTN draft in describing the requirement. Signaling, routing, also list the items and describes whether existing protocols can support it or not. 

Examples can be seen here, talking about the signaling requirement (plz see: http://tools.ietf.org/html/rfc7062#section-5.2 and http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-12#section-6)

>requirements with SHALL/SHOULD. Feedback and comments welcome.

[Xian]: I think it may be too early to include these and we should focus on the basic requirements first. Of course, Iftekhar may have other thoughts in mind for why including these. If so, would be good to hear.

>of using the term frequency slot, correct?

[Xian]: I also suggest we use standard terms. But I understand this is a basic requirement on routing, just as WSON advertises available lambdas.

[Xian]: Is the existing term Virtual Concatenation applicable, I wonder? 

Regards,
Xian

>>Signaling

Best Regards,

    Oscar