Re: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info
Leeyoung <leeyoung@huawei.com> Fri, 23 January 2015 20:12 UTC
Return-Path: <leeyoung@huawei.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 37BA31A0379 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 12:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level:
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TUuSe1p8hXL1 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 12:12:43 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95B91A0399 for <ccamp@ietf.org>; Fri, 23 Jan 2015 12:12:42 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOJ12559; Fri, 23 Jan 2015 20:12:41 +0000 (GMT)
Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 23 Jan 2015 20:12:40 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Fri, 23 Jan 2015 12:12:38 -0800
From: Leeyoung <leeyoung@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org" <draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>
Thread-Topic: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info
Thread-Index: AdA3HZjonkvmk8bgRpWytOzEjnSVrwABW8lgABdiggAAD0AlwA==
Date: Fri, 23 Jan 2015 20:12:38 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C7E1C0@dfweml706-chm>
References: <006a01d03721$11490170$33db0450$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm> <010801d0373d$865ae160$9310a420$@olddog.co.uk>
In-Reply-To: <010801d0373d$865ae160$9310a420$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.120]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/wwBGKS62sJn1ea1hK562wJCPxLs>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-chairs@tools.ietf.org" <ccamp-chairs@tools.ietf.org>
Subject: Re: [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
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 20:12:46 -0000
Hi Adrian, Ok. Here's my suggestion below. Thanks. Young ------------------------------------------------------------------------------------------- 5. Node Information (WSON specific) As discussed in [RFC6163] a WSON node may contain electro-optical subsystems such as regenerators, wavelength converters or entire switching subsystems. The model present here can be used in characterizing the accessibility and availability of limited resources such as regenerators or wavelength converters as well as WSON signal attribute constraints of electro-optical subsystems. As such this information element is fairly specific to WSON technologies. /* Add: 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. */ A WSON node may include regenerators or wavelength converters arranged in a shared pool. As discussed in [RFC6163] this can include OEO based WDM switches as well. There are a number of different approaches used in the design of WDM switches containing regenerator or converter pools. However, from the point of view of path computation the following need to be known: 1. The nodes that support regeneration or wavelength conversion. 2. The accessibility and availability of a wavelength converter to convert from a given input wavelength on a particular input port to a desired output wavelength on a particular output port. 3. Limitations on the types of signals that can be converted and the conversions that can be performed. Since resources tend to be packaged together in blocks of similar devices, e.g., on line cards or other types of modules, the fundamental unit of identifiable resource in this document is the Bernstein & Lee Expires June 4, 2015 [Page 6] Internet-Draft WSON Information Model December 2014 "resource block". /* Add: 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. */ /* Delete: A resource block may contain one or more resources. A resource is the smallest identifiable unit of processing allocation. One can group together resources into blocks if they have similar characteristics relevant to the optical system being modeled, e.g., processing properties, accessibility, etc. */ /* Add: 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. */ This leads to the following formal high level model: <Node_Information> ::= <Node_ID> [<ConnectivityMatrix>...] [<ResourcePool>] Where <ResourcePool> ::= <ResourceBlockInfo>... [<ResourceAccessibility>...] [<ResourceWaveConstraints>...] [<RBPoolState>] -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, January 23, 2015 12:51 PM To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org Subject: RE: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info OK, this is looking good. I think some more work is needed on pool and set. Looks like my text for pool should be used for set, and a new definition is needed for pool to describe a collection of sets. If you can do this and suggest to me where in rwa-info to put that text, I'll work it with the RFC Editor. Then later docs will only need to point at rwa-info. Thanks! Adrian > -----Original Message----- > From: Leeyoung [mailto:leeyoung@huawei.com] > Sent: 23 January 2015 15:57 > To: adrian@olddog.co.uk; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: RE: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp- > rwa-wson-encode and draft-ietf-ccamp-rwa-info > > Hi Adrian, > > I think we are on the same page. Please see inline for specific comment. > > Best regards, > Young > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, January 23, 2015 9:27 AM > To: Leeyoung; draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org > Cc: ccamp@ietf.org; ccamp-chairs@tools.ietf.org > Subject: Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa- > wson-encode and draft-ietf-ccamp-rwa-info > > 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). > > YOUNG>> Yes, I have just noticed that you held rwa-info and I hope you can > suggest some clarifying text into that draft, which I see below. > > 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. > > YOUNG>> Great suggestion. Yes, that is what is Resource is. The part of the > problem has been that the term 'resource' was picked when the WG asked us to > generalize Regenerators/wavelength converters. This term 'resource' may have > not been perfect, but it was chosen as such to have its meaning in a specific > context. > > 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. > > YOUNG>> Yes, it is correct. > > 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. > > YOUNG>> Yes. > > 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. > > YOUNG>> Yes, "sets" make it clearer. > > 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. > > YOUNG>> They are different. Resource Block Pool is sitting above the RB Sets. > There may be multiple RB Sets in a node that behave differently, e.g., different > input/output constraints on the access/egress to the Pool. > > > Have I finally got this right? > > YOUNG>> Yes, I think so. > > If so, then can we agree precise text and where to put it? > > YOUNG>> Yes. > > Thanks for your patience. > Adrian