Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

Hi Iftekhar,

I would like to address your comments if I can. 

I am serious and I personally think that these should be addressed in ITU-T SG15.

I would be much happy to see if there is someone from CCAMP can answer these questions. 

Best Regards

Fatai

-----Original Message-----
From: Iftekhar Hussain [mailto:IHussain@infinera.com] 
Sent: Friday, June 27, 2014 11:58 AM
To: Fatai Zhang; adrian@olddog.co.uk
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

Hi Fatai,

What do you mean by this? Seriously, I am surprised by your response.  So when you don't want to address comments juts punt to ITU :)
If that is the case I would echo Malcom's concern. 

Thanks,
Iftekhar

-----Original Message-----
From: Fatai Zhang [mailto:zhangfatai@huawei.com] 
Sent: Thursday, June 26, 2014 8:53 PM
To: Iftekhar Hussain; adrian@olddog.co.uk
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

Hi Iftekhar, 

For your first 4 questions, I don't think CCAMP experts can answer, and they should go to ITU-T, :-)

Best Regards

Fatai

-----Original Message-----
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Iftekhar Hussain
Sent: Friday, June 27, 2014 5:33 AM
To: adrian@olddog.co.uk
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

Hi Adrian,

Thanks for the reply. Okay, so understood that ITU already have defined the data plane requirements for grouping of flexible grid frequency slots. 

 So then is correct to state that the following is already defined in ITU data plane:

1. Are there any specific Latency/differential delay constraints to group adjacent slots?
2. Are there any constraints/limit on how many of these slots are allowed to be grouped?
3. Can the signal carried by these frequency slots must have the same modulation format or different?
4   What type of signals can be mapped to these frequency slots?

On the use case the composite label is addressing:

5. What is the use case and what are the use case requirements?
6. Are there any implications of this grouping to route computations?
7. What type of client signals 100G, 200G, etc. this solution is addressing.

Suggest if you would like to keep this section in this document, address the above comments either via adding specific references to ITU spec and adding some further information in the intended use case.

Thanks,
Iftekhar

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Wednesday, June 25, 2014 10:48 AM
To: Iftekhar Hussain
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

Hi Iftekhar,

> Clarification for the composite label portion:
> So does this mean that:
> a) we are moving ahead with control plane solution ahead of ITU data 
> plane definitions ?
> b) or that the ITU data plane has already defined all the data plane 
> aspects
for the
> composite label use case?
> 
> If it is case (b) - no issue.  However, if it is case (a) shouldn't we 
> wait
for ITU
> before proposing solutions?

I thought the text was clear, but I would be happy to add more clarification.

We currently have:

Section 1
   This document relies on [G.694.1] for the definition of the optical
   data plane and does not make any updates to the work of the ITU-T in
   that regard.

Section 2.1
   The slots in the set could potentially be contiguous or non-
   contiguous (as allowed by the definitions of the data plane) and
   could be signaled as a single LSP or constructed from a group of
   LSPs.
--- Maybe the parentheses are not clear and should say "(only as
   allowed...."

Section 4.3
   At the time of writing [G.694.1] only supports only groupings of
   adjacent slots (i.e., without intervening unused slots that could be
   used for other purposes) of identical width (same value of m), and
   the component slots must be in increasing order of frequency (i.e.,
   increasing order of the value n).  The mechanism defined here MUST
   NOT be used for other forms of grouping unless and until those forms
   are defined and documented in Recommendations published by the ITU-T.

So...
Case b)

>  I  disagree with the assertion "more formal discussion of media 
> channels and network media channels and their arrangement for inverse 
> multiplexing belongs in the framework" .  I believe this document 
> should  elaborate on the use case
for
> which the solution is being proposed.

I would be happy to be guided by the WG and see proposed text. Personally I have nothing to add here, but if you have then please show it to us. 

Maybe it would also help to say why you think this explanation should go in this document (which is not the first in the series) rather than in the more general discussion document that is the framework. I note that the framework already goes into some considerable detail about what media channels and network media channels are in the context of flexigrid.

Ciao,
Adrian

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp