Re: [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 18:51 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 EB0271A8700 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 10:51:43 -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 VXI70H1CGhaO for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 10:51:41 -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 3D5D91A86E3 for <ccamp@ietf.org>; Fri, 23 Jan 2015 10:51:08 -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 t0NIow8O022977; Fri, 23 Jan 2015 18:50:58 GMT
Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIotc5022942 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:50:57 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Leeyoung'" <leeyoung@huawei.com>, <draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>
References: <006a01d03721$11490170$33db0450$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7E013@dfweml706-chm>
Date: Fri, 23 Jan 2015 18:50:54 -0000
Message-ID: <010801d0373d$865ae160$9310a420$@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: AQMHSijD9OtehoLW+lP6yANWbX4HwgK+NNsPmkn0fDA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21278.002
X-TM-AS-Result: No--23.640-10.0-31-10
X-imss-scan-details: No--23.640-10.0-31-10
X-TMASE-MatchedRID: x2HXvaraFom+9Go4BgFPZgRH1Nr7oERdGSqdEmeD/nVJJReS9JUB3AaT alM8C773QQtdgo5YSWhIsgeX/PG9Zba06Jggiu2V3FqOVb7PDEKeimGtNywjttp1biJhIyNRXa2 +zE1cP+U3jelxKeBccKTRVhN59X1QgRy3HHXz6caaVoAi2I40/QXXmzqmsIi70KiNejbR39D6QR zjTw1oytJVo98vHaBPH84/fI58amMItMWhbSshqnV895e/Bd2JpfVcx39Kq+4b4NAU3x/cGUfl+ H4+MqTJvkVmw2xxRFia8KBvLePZCR1YpEPWJiyz84dsinZ5e1g0AKed0u9fB7rfxlRjqBJ3C9u4 t4siKdfXuKn6Epb/8XJx+bDPe9HX1M73D0qKwJQS7luGt6tlhlXKDhjPZTukdvZ5LJp45ksz6n4 2mzBmahD04cBTzvBYRWqZS1D9m9FFsw2Lp+kSuMOvQCMFyZ9Gecvjbu/xDjpV84HrPxCfbHLxsR yKaXupwM2jgIXgmkYs+lHplZhRHupLXJKeenhQj5hLPCX3ZdO/yN2q8U674tqCxkzSpW/XIEFqD yMwcNonAC0lpjxIxscHvwkNmxhvGAdnzrnkM485f9Xw/xqKXcidYBYDjITp+gD2vYtOFhgqtq5d 3cxkNQP90fJP9eHt
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/0n7QVHH46HofyQ3XjgAmAVp_Pwk>
Cc: ccamp@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
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 18:51:44 -0000

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