Re: [CCAMP] Resource, Resource Block, and Resource Pool in draft-ietf-ccamp-rwa-wson-encode and draft-ietf-ccamp-rwa-info

["Adrian Farrel" <[e-mail]>]

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:[e-mail]]
> Sent: 23 January 2015 15:57
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> Sent: Friday, January 23, 2015 9:27 AM
> To: Leeyoung; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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