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

["Zhangxian (Xian)" <[e-mail]>]

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:[e-mail]] On Behalf Of Oscar González de Dios
Sent: 2014年2月12日 22:47
To: Ramon Casellas; [e-mail]
Subject: Re: [CCAMP] Flexi-Grid control plane requirements - was: Generalized Labels for the Flexi-Grid in LSC Label Switching Routers

Dear Iftekhar, Ramon, all

        Further comments inline

>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
>
>
>El 08/02/2014 8:46, Iftekhar Hussain escribió:
>> R1: Single Frequency Slot Network Connection
>> The control plane SHALL be able to support network media channels
>>containing a single frequency slot.
>Ramon> Ok.
>
>> 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.
>Ramon> Ok.
>
[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)."

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

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

>
>>
>> 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.
>Ramon> This seems to me that we would be excluding hardware that has
>some constraints related to nominal central granularity. Am I missing
>something?
[Oscar] Maybe a set of requirements can be added to the document
regarding feasible combinations of n and m in the hardware.

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

>
>
>>
>> R5: L-band and S-band
>> The control plane architecture SHOULD allow  for  L-band and S-band
>>support.
>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? 

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

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

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

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

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

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

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

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

Regards,
Xian

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

[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

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp