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

Iftekhar Hussain <IHussain@infinera.com> Thu, 26 June 2014 21:33 UTC

Return-Path: <IHussain@infinera.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871871B2F46 for <ccamp@ietfa.amsl.com>; Thu, 26 Jun 2014 14:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.562
X-Spam-Level: *
X-Spam-Status: No, score=1.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9F2K0QbZkOV for <ccamp@ietfa.amsl.com>; Thu, 26 Jun 2014 14:33:38 -0700 (PDT)
Received: from outgoingmail2.infinera.com (unknown [204.128.141.24]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6BC1B2F42 for <ccamp@ietf.org>; Thu, 26 Jun 2014 14:33:37 -0700 (PDT)
Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd2.infinera.com (10.100.103.229) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 26 Jun 2014 14:33:07 -0700
Received: from SV-EX13-PRD1.infinera.com ([10.100.97.11]) by sv-ex13-prd1.infinera.com ([10.100.97.11]) with mapi id 15.00.0847.030; Thu, 26 Jun 2014 14:33:07 -0700
From: Iftekhar Hussain <IHussain@infinera.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt
Thread-Index: Ac+QnUWyyMOhUqRVTrGiod0Cvt+RXQA4siJw
Date: Thu, 26 Jun 2014 21:33:06 +0000
Message-ID: <3cb78df56a2a4c278b8112fecd887796@sv-ex13-prd1.infinera.com>
References: <065601cf909d$a08e4fa0$e1aaeee0$@olddog.co.uk>
In-Reply-To: <065601cf909d$a08e4fa0$e1aaeee0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.99.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/mv4ivriy4txTzG6Lqrfrb-l3Iwc
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jun 2014 21:33:40 -0000

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