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

["Adrian Farrel" <[e-mail]>]

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