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

[Iftekhar Hussain <[e-mail]>]

It is clear from your response that composite label portion is way beyond the ITU data plane definition as of today. Do you still have reasons for keeping the composite label portion in the draft? If not please take it off the WG document.

Thanks,
Iftekhar

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Saturday, June 28, 2014 10:28 AM
To: Iftekhar Hussain; 'Fatai Zhang'
Cc: [e-mail]
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

There is a certain extent to which this conversation has a gyratory nature :-)

Maybe a piece of information missing here is that CCAMP defines control plane mechanisms to enable the operation of networks composed of data plane technologies that have been specified in other SDOs or (only in the case of IP and MPLS) in the IETF. CCAMP does not define data plane technologies.

My intent in selecting the wording was to say "The ITU-T has currently defined a data plane that allows contiguous slots to be treated as a single unit. This composite label format supports that mechanism. Future uses of this composite label format are dependent on the ITU-T adding further data plane definitions, and those future uses must not be defined until the ITU-T has provided those definitions." 

I am pretty sure that that is what the document says. I'd be happy if someone was able to show me where the document is misleading in that respect and even happier if they suggested tighter wording.

Returning to Iftekhar's questions:

> 1. Are there any specific Latency/differential delay constraints to 
> group adjacent slots?

I should be surprised if adjacent slots (on the same fiber, remember) had different latencies/delays. But Q6 would be able to give a definitive answer.

> 2. Are there any constraints/limit on how many of these slots are 
> allowed to be grouped?

I think that is a matter for the ITU-T. Again Q6, I think.
I believe we have a mechanism here that would allow an arbitrary number of slots to be grouped, but I also suspect that such grouping would not be arbitrarily large in reality and I think that I have heard 8 and 16 talked about by hardware manufacturers. Beyond that, I think it becomes unmanageable and it would be normal to select a smaller number of larger slots.

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

I would expect that the purpose here is to create a larger slot for carrying payload and so the modulation format would be the same. But my expectations are not relevant! The text attempts to be clear that the encoding of signal into slot is not a function of the label format. It might be a feature in the signaling protocol (separate document) and could be described in the framework draft (also separate document).

Clearly, these types of question are best addressed to the ITU-T. Q6 and Q12, I should think.

> On the use case the composite label is addressing:
> 
> 5. What is the use case and what are the use case requirements?

I would expect to see the use case detailed further in the framework draft.
The use case is currently to support identifying a set of slots as single switchable unit, but not going any further than the data plane mechanisms defined in existing ITU-T Recommendations.

> 6. Are there any implications of this grouping to route computations?

Yes, I believe there are. I believe that the usage described in my text implies that the group members are on the same fiber (which implies, I think, that they are corouted).

> 7. What type of client signals 100G, 200G, etc. this solution is addressing.

Why would a document that defines a label format be concerned about the answer to this question?

Cheers,
Adrian


> -----Original Message-----
> From: Iftekhar Hussain [mailto:[e-mail]]
> Sent: 27 June 2014 19:04
> To: Fatai Zhang; [e-mail]
> Cc: [e-mail]
> Subject: RE: [CCAMP] I-D Action:
draft-ietf-ccamp-flexigrid-lambda-label-01.txt
> 
> If we are deferring these to ITU-T then we should hold of including 
> this
section in
> the label WG document until all these has been clarified/understood.
> 
> Thanks,
> Iftekhar
> -----Original Message-----
> From: Fatai Zhang [mailto:[e-mail]]
> Sent: Thursday, June 26, 2014 10:00 PM
> To: Iftekhar Hussain; [e-mail]
> Cc: [e-mail]
> Subject: 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:[e-mail]]
> Sent: Friday, June 27, 2014 11:58 AM
> To: Fatai Zhang; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Thursday, June 26, 2014 8:53 PM
> To: Iftekhar Hussain; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]] On Behalf Of Iftekhar 
> Hussain
> Sent: Friday, June 27, 2014 5:33 AM
> To: [e-mail]
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Wednesday, June 25, 2014 10:48 AM
> To: Iftekhar Hussain
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp