[CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 23 January 2015 15:27 UTC
Return-Path: <adrian@olddog.co.uk>
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 81FEC1A914E for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 07:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
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 6ttM5f2ZRduX for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 07:27:35 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDBB1A90BA for <ccamp@ietf.org>; Fri, 23 Jan 2015 07:27:34 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NFRGc3006450; Fri, 23 Jan 2015 15:27:17 GMT
Received: from 950129200 (089144224197.atnat0033.highway.a1.net [89.144.224.197]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NFRERO006327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 15:27:15 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Leeyoung' <leeyoung@huawei.com>, draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org
Date: Fri, 23 Jan 2015 15:27:10 -0000
Message-ID: <006a01d03721$11490170$33db0450$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdA3HZjonkvmk8bgRpWytOzEjnSVrw==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.000
X-TM-AS-Result: No--14.837-10.0-31-10
X-imss-scan-details: No--14.837-10.0-31-10
X-TMASE-MatchedRID: V7+YOFQa11Eol39hmeEcd4zb2GR6Ttd3bayJNjpJvsazU0R+5DbDbKGM dMUDv3NC7Z2Ub9WArt0IThkg+gnWEO26dmaIobujSDkh6bW+bcdYfDj3hIJgka+WgCcaviqGIZn pVU5Vh5YIl5LoEUEJGtJOk2AbaE/FqW0LH7DLBaXK09/T6AzbVkyQ5fRSh265CVuEXtlNqcshuv 9XGd2ScmZskvJo0aBBTpApQ5mX86rODBDKbmK9pcWUKBjERoYTWwKGivsEuI2e8oYCLa7A46MOK npzjnVIVH9uf5GqbbIQbg/yAcf3PtOlZ6Jznao8hrs6JAEL1u44WsSNiH/UXkhkYHhloziiK5/V s9QmFLCTEmvX2xcMHinx5D0LD290QdZuZ42vrpHMrZu+Xb3+2Z6KYa03LCO2myiLZetSf8nJ4y0 wP1A6AMaUO+wtQNbajoczmuoPCq0G3jDd1UNPMHVlxHCgLB+noVceYt5Zmq1Z/RKsbmMCsnQJru 67Hfym
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/ffnDTUVJL9O5IPY6MS5aJ1hnTf0>
Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org
Subject: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Fri, 23 Jan 2015 15:27:37 -0000
Hello, Continuing this discussion, I think we are getting closer. > > My comment for general vs. WSON-specific issue is that the design philosophy > > of general encoding was to generalize a common element that can be applied > > to different technologies. For instance, connectivity matrix definitely can be > > applied to WSON, OTN and other Switching technology as one encoding can > > fit to all. You seemed to desire a sharing of the same encoding to describe > > different entities where possible. This is fine for label vs. wavelength as > > there is one-to-one mapping for this. However, Resource Block encoding > > cannot properly share with the connectivity matrix encoding with two > > reasons: > > > > 1. They refer to different elements in the node. > > 2. They require different sets of fields with different number of fields. OK, what we really seem to be running into is some rather vague definitions of "resource" and "resource block". Do you think we could spend some time nailing those down. Then we'll work out where to put them (possibly in rwa-info). The question is not about the protocol element "resource block" but is about what it represents. So, as a starter, what is a Resource in a WSON system? You have said (lower down this email) that " resources meant regenerators/wavelength converters". I can live with this (although it is a long way from the term "resource" used in 3473 etc. where it is taken to mean buffers, bandwidth, memory, labels, lambdas,... That difference in interpretation is sufficiently large that it needs to be brought out and made very clear. You need something like: In this document the term "Resource" is used to refer to a physical component of a WSON node such as a regenerator or a wavelength converter. Multiple instances of such components are often present within a single WSON node. This term is not to be confused with the concept of forwarding or switching resources such as bandwidth or lambdas. Then you can answer what is a Resource Block in a WSON system? >From what I think I now understand, a resource block is simply a collection of resources on a WSON network node that behave in the same way. This allows easier description in the protocol encoding, but has no other meaning. So you could say: A Resource Block is a collection of Resources from the same WSON node that are grouped together for administrative reasons and for ease of encoding in the protocols. All Resources in the same Resource Block behave in the same way and have similar characteristics relevant to the optical system, e.g., processing properties, accessibility, etc. Then comes, what is a Resource Pool? Actually, this is only implicitly defined in draft-ietf-ccamp-rwa-info and so we have quite a gap. It looks like you might say: A Resource Pool is a collection of Resource Blocks for the purpose of representing throughput or cross-connect capabilities in a WSON node. A Resource Pool associates input ports or links on the node with output ports or links and is used to indicate how signals may be passed from an input port or link to an output port or link by way of a Resource Block (in other words, by way of a Resource). A Resource Pool may, therefore, be modelled as a matrix. A Resource Block may be present in multiple Resource Pools. And finally, we have Resource Block Set. What is that? I *think* it is just the encoding concept for a Resource Block Pool. You have (in 2.1) In a WSON node that includes resource blocks (RB), denoting subsets of these blocks allows one to efficiently describe common properties of the blocks and to describe the structure and characteristics, if non-trivial, of the resource pool. *Now* I see that your "subsets" should actually be "sets" and that will make more sense. But do you need the two terms "Resource Block Pool" and "Resource Block Set"? Are they the same or different? When I read 3.2 it looks like the Resource Block Pool is a collection of Resource Block Sets. Have I finally got this right? If so, then can we agree precise text and where to put it? Thanks for your patience. Adrian