Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt
Rajan Rao <rrao@infinera.com> Thu, 24 July 2014 00:45 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 E56551A0381 for <ccamp@ietfa.amsl.com>; Wed, 23 Jul 2014 17:45:52 -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 vWJsER-8HN0w for <ccamp@ietfa.amsl.com>; Wed, 23 Jul 2014 17:45:51 -0700 (PDT)
Received: from outgoingmail1.infinera.com (outgoingmail1.infinera.com [204.128.141.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D3B1A0115 for <ccamp@ietf.org>; Wed, 23 Jul 2014 17:45:51 -0700 (PDT)
Received: from SV-EX13-PRD1.infinera.com (10.100.103.228) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 23 Jul 2014 17:45:35 -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; Wed, 23 Jul 2014 17:45:35 -0700
From: Rajan Rao <rrao@infinera.com>
To: Iftekhar Hussain <IHussain@infinera.com>, "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+kGXH6Y94TWY5qRO6+Mbd8d/ZgZwCHVBDQAC3TLQD//9EBQA==
Date: Thu, 24 Jul 2014 00:45:35 +0000
Message-ID: <fd011ca8635a42fc9fbe9a1b4573b3f7@sv-ex13-prd1.infinera.com>
References: <04d701cfa419$b7f9c1d0$27ed4570$@olddog.co.uk> <ba3fa291b1d84d2ca3dbcd7d703475fe@sv-ex13-prd1.infinera.com>, <128601cfa6b3$6438e200$2caaa600$@olddog.co.uk>
In-Reply-To: <128601cfa6b3$6438e200$2caaa600$@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/LGhMlZAbuss60jvwxXSaSSr1mSw
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, 24 Jul 2014 00:45:53 -0000
Adrian, No issues with 1-3. For # 4, As long as we don't preclude use of single label for multiple flex grid slots we should be fine. Para # 2 starts with composite label but clarification later in the section you have is good. Thx Rajan ________________________________________ From: Adrian Farrel <adrian@olddog.co.uk> Sent: Wednesday, July 23, 2014 1:19:20 PM To: Rajan Rao; Iftekhar Hussain Cc: ccamp@ietf.org Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-lambda-label-01.txt Hello Rajan, > The composite label section in the draft (sec 4.3) refers to RFC 7139. The draft says... The creation of a composite of multiple channels to support inverse multiplexing is already supported in GMPLS for TDM and OTN [RFC4606], [RFC6344], [RFC7139]. The mechanism used for flexigrid is similar. > In OTN label we did not enforce this. I don't understand that. RFC 7139 *is* signaling for OTN. What is it you didn't enforce in OTN label? > The OTN Label allows use of non-contiguous time slots within a Te-Link. This is true. > It is not clear from this draft as to why we shouldn't take the > same approach? Because the data plane to support this has not been defined by the ITU-T. (If you disagree with this, perhaps you could point me at the relevant Recommendation.) > 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? The draft says... Note further that while the mechanism described here naturally means that all component channels are corouted, a composite channel can also be achieved by constructing individual LSPs from single flexi- grid slots and managing those LSPs as a group. A mechanism for achieving this for TDM is described in [RFC6344], but is out of scope for discussion in this document because the labels used are normal, single slot labels and require no additional definitions. This seems to cover 1, 2, and 3. Do you see a way that those models are handled in our OTN signaling without sending more than one signaling message? But note that the ITU-T does not currently define how you would achieve such a composite channel in flexi-grid, and that would mean that anyone writing an I-D that explained how achieve this would be blocked until the data plane had been documented. The document also says... 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. This covers 4, and explains how that case is split into two different scenarios. What is not clear about this text? > 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. But we do take the same position! 7139 did not do anything that was not already defined in a data pane specification. We are taking the same approach. Adrian
- [CCAMP] I-D Action: draft-ietf-ccamp-flexigrid-la… internet-drafts
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Adrian Farrel
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Iftekhar Hussain
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Adrian Farrel
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Iftekhar Hussain
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Fatai Zhang
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Iftekhar Hussain
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Fatai Zhang
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Varma, Eve L (Eve)
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… John E Drake
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Huub van Helvoort
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Iftekhar Hussain
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Adrian Farrel
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Iftekhar Hussain
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Adrian Farrel
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Rajan Rao
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Adrian Farrel
- Re: [CCAMP] I-D Action: draft-ietf-ccamp-flexigri… Rajan Rao