Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

[Leeyoung <[e-mail]>]

Hi Adrian,

Thanks for your thorough comment here. 

I am not sure if my response would satisfy all your concerns/questions, especially the discussion on generalized vs. WSON-specific issues. But I believe there was some misunderstanding as to the definition of Resource Blocks and how to identify them in the advertisement. 

Please see inline for my comment. 

Regards,
Young 

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Wednesday, January 21, 2015 2:58 PM
To: Leeyoung; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

Hi,

Thanks for the response.

Many of the points you said "YES" and I have edit them out. You can fold the
changes into a new revision.

YOUNG>> OK. 

Further discussion below.

> 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.
> 
> Please also see my comment in-line for details.
> 
>> I've now done my AD review of this document. I am rather regretting
>> starting the IETF last call for draft-ietf-ccamp-general-constraint-
>> encode on which this document depends because it seems that this
>> document introduces WSON-specific encodings (all of those before
>> Section 4) that should/could have been made generic. In fact, I
>> thought the point of the general encodings document was to produce
>> protocol objects that could be used by technology-specific documents
>> like this one.
>> ===========
>> 
> Section 2.1 seems somewhere between a copy of and a modification of
> the Link Set Field in 2.3 of [Gen-Encode].
> 
> Some clarification would be useful. If this is different, why is it not
> using one of the generic encodings applied in a specific way? If it is
> the same, you should probably just reference the encoding in
> [Gen-Encode] and describe here how the fields are used, but if you
> insist in re-drawing the figure it should be aligned with the figure in
> [Gen-Encode].
> 
> [YOUNG] not quite. Link Set and Label Set are two different things with
different
> fields.
> Link Set has directionality and identifier format while Label Set does not
have
> these fields but has connectivity field.
> Not sure how we can point to each other.

First, I'm not sure why you bring label set in here since 2.1 is about "resource
block set".

YOUNG>> My bad. I think I was mixed up. My point probably was comparing RB Set Field with Link Set Field with different fields --- It would be hard to have one encoding to describe two different elements.  

This sent me back to rwa-info to see what the definition of a resource block is.

   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
   "resource block". 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.

Hmmm, now I spot another issue with this I-D.
If a resource block is the fundamental unit of identifiable resource, how come
it contains smaller identifiable units (i.e. resources)?
That is a bit confusing.
Sigh.

Anyway, in section 2.1 of this document you define the RB set to be a collection
of Resource Block identifiers. Maybe it would have helped me understand had you
said (somewhere) specifically what a resource is in the RWA/WSON context.
rwa-info suggests "resources such as regenerators or wavelength converters" and
I am unclear whether this is exactly what you mean in every further use of
"resource".

YOUNG>> Yes, resources meant regenerators/wavelength converters. 

And the concept of a resource block is also poorly introduced. If it is merely a
collection of resources, that would be good to say. And if the resource block
identifier is an arbitrary identifier assigned to this collection of resources
with no more than a local semantics, then you could say so (and possibly explain
how advertising resource block identifiers can be of any use to anyone else
because they won't know what the resource block represents - I don't see any
advertisement of "this resource block contains the following resources").

I think what you are saying by mentioning "label set" in your reply is that a
resource block is a set of things that can be labeled. That is certainly how I
interpreted it. And I thought - surely you can label things in any technology,
so there ought to be a general encoding for a resource block.

Of course, there is label set and link set in general-constraint-encode. But
neither looks much like the RB set in this document. You're probably right that
link set would be the wrong thing for RB set to try to look like (although links
are switchable/labelled quantities, too), but label set doesn't look like the RB
set you have here. Which brings me back to my main question....

What is it about a WSON RB set that makes it something that is not generalised?
I don't see anything in the description of RB set or RBs themselves that makes
them specific to WSON (possibly because there is so little description of a
resource or a resource block in any of the documents!).

YOUNG>> How about the figure 1 in Appendix A.1, I think it should have been labeled as "RB Pool" instead of WC Pool. I will change "WC" to "RB" and point to this figure from Section 2.1 and Section 3.2 where RB Set is explained in the context of Resource Pool. 

>> Section 2.1
>> 
>>    The RB identifier represents the ID of the resource block which is a
>>    32 bit integer.
>> 
>> You might note that the scope of the RB identifier is local to the node
>> on which it is applied although that node may choose to use a globally
>> known encoding such as from RFC 6205.
>> 
>> I assume that flexi-grid is out of scope for WSON. If it is not, then
>> you need to think further about your 32 bit identifiers.
> 
> [YOUNG] Flex-grid is out of scope here.

OK

> In addition, RB identifier is a resource
> block ID Which is different from wavelength identifier. I am sure how a
globally
> known encoding for Wavelength id can be used for RB identifier. They seemed
> to refer two different entities.

OK. I now understand that a resource block is NOT the fundamental unit of
resource that rwa-info claims it to be. So a resource block is a collection of
one or more wavelengths (resources) and the resource block identifier is an
arbitrary identifier for that block of resources.

As I asked above, when you advertise RB ID 1 to me, how do I know which
resources you are referring to?

YOUNG>> In Section 3.1 Resource Accessibility Field is defined and encoded as below:

   0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Reserved(8bits)|C|             Reserved (23 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Input Link Set Field A #1                  |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          RB Set Field A #1                    |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Additional Link set and RB set pairs as needed to     |
      :                    specify PoolInputMatrix                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output Link Set Field B #1                     |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             RB Set B Field #1 (for output connectivity)       |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Additional Link Set and RB set pairs as needed to     |
      :                    specify PoolOutputMatrix                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RB Set Field defines the RD ID's and Input/Output Link Sets are associated with RB ID's. 

See Appendix A.1, Figure 1 which explains the association of Link Sets with RB blocks including RB ID's. 

              +-----+       +-----+
              | 1 1 |       | 1 0 |
          WI =|     |,  WE =|     |
              | 1 1 |       | 0 1 |
              +-----+       +-----+


                    +-----------+                      +------+
                    |           |--------------------->|      |
                    |           |--------------------->|  C   |
              /|    |           |--------------------->|  o   |
             /D+--->|           |--------------------->|  m   |
            + e+--->|           |                      |  b   |=======>
   ========>| M|    |  Optical  |    +-----------+     |  i   | Port O1
   Port I1  + u+--->|   Switch  |    |  WC Pool  |     |  n   |
             \x+--->|           |    |  +-----+  |     |  e   |
              \|    |           +----+->|WC #1|--+---->|  r   |
                    |           |    |  +-----+  |     +------+
                    |           |    |           |     +------+
              /|    |           |    |  +-----+  |     |      |
             /D+--->|           +----+->|WC #2|--+---->|  C   |
            + e+--->|           |    |  +-----+  |     |  o   |
   ========>| M|    |           |    +-----------+     |  m   |=======>
   Port I2  + u+--->|           |                      |  b   | Port O2
             \x+--->|           |--------------------->|  i   |
              \|    |           |--------------------->|  n   |
                    |           |--------------------->|  e   |
                    |           |--------------------->|  r   |
                    +-----------+                      +------+
    Figure 1 An optical switch featuring a shared per fiber wavelength
                       converter pool architecture.

>> Section 3.1
>> 
>> Why isn't the Resource Accessibility Field expressed in terms of the
>> use of a generic Connectivity Matrix Field from section 2.1 of
>> [Gen-Encode]? I thought the whole point of [Gen-Encode] was to derive
>> application agnostic encodings that could be used without modification
>> (but with applicability notes) by specific technologies.
> 
> [YOUNG] Not quite. Connectivity Matrix encoding cannot be used for Resource
> Accessibility Field as the latter
> has additional entity (namely, RB set field) to describe. We generalized a
single-
> stage connectivity matrix in [Gen-Encode] that can
> be applicable to any switching technology. Here in WSON, we have a need to
> model RB constraints (for the pool of Wavelength Converters)
> from/to input/output link sets. Putting two different entities into one coding
was
> not the choice of the authors.

I don't understand.
You say that the generalized single-stage connectivity matrix can be applicable
to any switching technology and then you don't use it for WSON saying that you
need other constraints as well.
Are you, in fact, saying that the generalized single-stage connectivity matrix
is not applicable to WSON?

YOUNG>> No that is not what I am saying. WSON uses both the connectivity matrix and the RB.
The RB is only unique for WSON element. 

>> Section 3.2
>> 
>> I looked for the equivalent of the Resource Wavelength Constraints
>> Field in [Gen-Encode]. I understand that Input Wavelength Constraints
>> Field and Output Wavelength Constraints Field are encoded using the
>> generic Label Set of  [Gen-Encode], but I thought that the whole concept
>> of Resource Constraints would be generic.
> 
> [YOUNG] Again, I think the design of generalization is not intended to
> share the same encoding to describe two different entities. Besides, I do
> not see the need to generalize encoding of an entity that has no particular
> use in other technologies than WSON.

I think the point of generalization is to come up with an encoding that can be
re-used in different witching environments.
Obviously, the only environment with wavelength is WSON. But all switching
environments have labels that are switched, and have constraints applicable to
those labels and to the ability to switch the labels.

Suppose I wrote:

   Resources, such as switches and filters, may have limited
   input or output label ranges. Additionally, due to the
   structure of the switches not all labels can necessarily
   reach or leave all the resources. These properties are described by
   using one or more resource restrictions fields as defined
   below:

That is just a rewrite of 3.2 in general terms and seems to not be a problem.
Indeed, if general-constraint-encode had had...

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|O|B|                      Reserved                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     RB Set Field                              |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Input Label Constraints                         |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Output Label Constraints                       |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

...then I would have thought it a perfect fit.

> Section 3.3
> 
> As with the previous section I don't see anything that is WSON-specific
> in the concept of the 3.3. Resource Block Pool State (RBPoolState) Field
> and I wondered why [Gen-Encode] doesn't have anything to cover this.
> 
> [YOUNG] RB is wavelength converters, which is a unique WSON element.

No!
You might as well say that a lambda is a unique WSON concept and so cannot
re-use the generic concept of the LABEL object.

Isn't a "wavelength converter" just a special case of a label switch? That is
certainly how I read RFC 6163
   Wavelength converters take an input optical signal at one wavelength
   and emit an equivalent content optical signal at another wavelength
   on output.

I think you are just not stepping back far enough to see the concept of
"generalization."

YOUNG>> As the figure 1 from Appendix A, WC's are additional element on top of a label switch. I still think it is a unique WSON element which may not be relevant to Generic label switch paradigm.  

>> Why don't Sections 3.4 and 4 have a B-bit like that in 3.2?
> 
> [YOUNG] I think the reason for B bit is not included in Section 3.4 is the
context
> where it won't be very useful (even if we have a B bit) as input wavelengths
> available will hardly match with output wavelength available in most cases.
> Compared to this, wavelength constraints can more often be same for input and
> output.

This isn't very convincing.
"in most cases" suggests sometimes it will.
Are you saying the use of one extra bit outweighs the saving in encoding in the
rare cases where that bit could be used?

YOUNG>> I can add B bit if you think it must be there in Sections 3.4 and 4. 

You didn't comment about section 4.

>> Section 4
>> 
>> How do I know the length of the ResourceBlockInfo field? I need to know
>> this to decide whether to try to parse the next bytes as another
>> Optional subfield. I *do* when I reach the end of one Optional subfield,
>> but I don't know whether another follows.
>> 
>> Possibly you intend the object that includes a ResourceBlockInfo field
>> to provide the length information, but other fields defined in this
>> document do include lengths or enough information to deduce the lengths.
> 
> [YOUNG] Yes, you're right. It is not completely consistent. How about the
> following
> Encoding:
> 
>   	 0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |I|O|  Reserved                 |        Length                 |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                          RB Set Field                         |
>       :                                                               :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Optional subfield 1                    |
>       :                              ...                              :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                               :                               :
>       :                               :                               :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Optional subfield N                    |
>       :                                                               :
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OK, that would be effective.
How does that fit with your implementation?
And is this a big enough change to require returning to the working group?

YOUNG>> The object that includes a ResourceBlockInfo field provides the length info. 
I grant however there is inconsistency here. Not sure what is the best. Perhaps, effectiveness
may be sacrificed unless things are broken. 

>> Section 4.1
>> How do I interpret a Vendor-Specific Application Code? Is there an OUI
>> I'm missing?
> 
> [YOUNG] Not sure if I understood this question. What is "OUI"?

http://en.wikipedia.org/wiki/Organizationally_unique_identifier
http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802
-numbers-2

Or perhaps an Enterprise Number
http://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

The question is:

You have sections 4.1.1 through 4.1.4 to tell me how to interpret the Optical
Interface Class field when it contains an ITU-T Application Mapping.
When I received s=0 and OI=1 it means that the Optical Interface Class contains
a "Vendor Specific Optical Interface Class".
How do I interpret that Optical Interface Class?
Which vendor does it apply to?
Is there some information elsewhere that gives me a clue as to which vendor has
encoded the information?
Or is the information supposed to be encoded in the Optical Interface Class,
perhaps as the first 48 bits?
Or am I supposed to know by context?

YOUNG>>  See Giovanni's email.  

>> I discussed sections 4.1.1-4.1.4 with the authors and the WG chairs and
>> have asked the chairs to send a liaison to ITU-T Q6/15 asking them to
>> cast an eye over the text of these sections.
> 
> [YOUNG] Thanks. It is a good idea to send a liaison to Q6/15.

Great. That has now been sent and we'll see what happens.

>> 4.1.1 and 4.1.2
>> 
>>       An Optional F can be added indicating a FEC Encoding.
>> 
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |B|  D  |S|   c   |   W   |   y   |   t   |   z   |  v  |   F   |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |                           reserved                            |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>>          F (suffix): = 0 reserved, = 1 Fec Encoding
>> 
>>       Values not mentioned here are not allowed in this application
>>    code
>> 
>> If F is optional but only one value is allowed (viz. 1) how do I opt to
>> not indicate a FEC Encoding?
> 
> [YOUNG] I guess 0 will do it.

But I can't set zero because it is reserved.

[YOUNG] I can add "F bit not equal 1" implies a FEC Encoding is not included. 

Thanks,
Adrian