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

[Iftekhar Hussain <[e-mail]>]

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:[e-mail]] 
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.

On 2/3/2014 2:15 AM, Iftekhar Hussain wrote:
> 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.

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

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

> Best regards,
> Iftekhar
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> 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 
> <[e-mail]>
> 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:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> 
> 
> 
>