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

Rajan Rao <rrao@infinera.com> Wed, 23 July 2014 06:12 UTC

Return-Path: <rrao@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 6F3FD1A001D for <ccamp@ietfa.amsl.com>; Tue, 22 Jul 2014 23:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Level:
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 Ms3VpKKr_8U1 for <ccamp@ietfa.amsl.com>; Tue, 22 Jul 2014 23:11:54 -0700 (PDT)
Received: from outgoingmail2.infinera.com (outgoingmail2.infinera.com [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 E9BED1A0045 for <ccamp@ietf.org>; Tue, 22 Jul 2014 23:11:47 -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; Tue, 22 Jul 2014 23:11:44 -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; Tue, 22 Jul 2014 23:11:44 -0700
From: Rajan Rao <rrao@infinera.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Iftekhar Hussain <IHussain@infinera.com>
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt
Thread-Index: Ac+kGXH6Y94TWY5qRO6+Mbd8d/ZgZwCHVBDQ
Date: Wed, 23 Jul 2014 06:11:44 +0000
Message-ID: <ba3fa291b1d84d2ca3dbcd7d703475fe@sv-ex13-prd1.infinera.com>
References: <04d701cfa419$b7f9c1d0$27ed4570$@olddog.co.uk>
In-Reply-To: <04d701cfa419$b7f9c1d0$27ed4570$@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/QXZPlvdWKaYZixH3Rimb70hZNvg
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: Wed, 23 Jul 2014 06:12:01 -0000

Adrian,

The composite label section in the draft (sec 4.3) refers to RFC 7139.  In OTN label we did not enforce this.  The OTN Label allows use of non-contiguous time slots within a Te-Link.  It is not clear from this draft as to why we shouldn't take the same approach?

Perhaps we should step back and look at possible uses cases that would fall in to VCAT/inverse-muxing (IM) categories.  I can think of the following:

1. IM across Te-Links within a single fiber
2. IM across Te-links in different fibers
3. IM across Te-links within a bundle
4. IM across frequency slots within a Te-Link

While none of these are defined by ITU, this label draft seems to be addressing #4.  It is not clear why one would enforce VCAT/IM within a Te-Link.   Do you have a use case in mind?

If we take same position as in RFC 7139 then there is no reason to restrict use of single Label with non-contiguous frequency slots.

Thx
Rajan

-----Original Message-----
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Sunday, July 20, 2014 5:54 AM
To: Iftekhar Hussain
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt

> It is clear from your response that composite label portion is way 
> beyond the
ITU
> data plane definition as of today. 

I'm sorry I have given you that impression. Sorrier still if the text in the I-D leaves you with that impression.

It was my intention that this document defined a label that could be used for the limited form of concatenated slot that is currently defined by the ITU-T.
It was also my intention that the document clearly and unequivocally states that the label is not for any undefined (by the ITU-T) data plane constructs.
However, I wanted to ensure that the defined label is forward compatible.

> Do you still have reasons for keeping the composite label portion in 
> the draft? If not please take it off the WG document.

Well, it is a WG I-D so my reason, as editor, is governed by what the WG wants.
I had formed the opinion, in the run up to WG adoption, that the WG supported this idea. And before I posted the revised I-D, I circulated the text on the list, received a couple of comments, and tweaked the text. I don't believe I heard anyone objecting to the idea at that time.

Perhaps the chairs can help guide us to understand what the WG wants included in the document.

Thanks,
Adrian

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