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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Jan 2015 20:14:47 -0000

Hello,

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.

If you can respond to my comments below, we can work out whether the
general encodings document needs to be brought back for more work.

Thanks for your efforts with this.

Adrian

===========

Abstract

   while other parts are fairly specific to WSONs.

They are either specific or they are not. I think you need
s/fairly specific/specific/

---

Shouldn't the Introduction include a discussion of and reference to
[Gen-encode]?

---

The Introduction has

   This document provides efficient encodings

and

   Note that since these encodings are relatively efficient

Which are they? And relative to what?

---

Section 1.1 has

   Refer to Section 5 of [Gen-Encode] for the terminology of Resources,
   Resources Blocks, and Resource Pool.

I think you mean [RWA-Info]. That would also make [RWA-Info] a normative
reference which seems correct anyway.

---

Section 1.1 makes RFC 6163 a normative reference.

---

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].

---

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.

---

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.

---

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.

---

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.

---

Section 3.3

   Where Action = 0 denotes a list of 16 bit integers and Action = 1
   denotes a bit map. In both cases the elements of the RB Set field
   are in a one-to-one correspondence with the values in the usage RB
   usage state area.

This is not clear. I think the Action field is explaining how the
RB Usage State field is encoded.
- Not sure why you call it "Action"
- Would be good if you could make it clear that "16 bit integers"
  or "bit map" apply to the RB Usage State field.

But...

   RB#i State (16 bits, unsigned integer): indicates Resource Block #i
   is in use or available.

- You might say what value of the 16 bit unsigned integer indicates in
  use and what value indicates available.
- You should explain to me why a list of 16 bit integers to encode a
  set of Booleans is in anyway efficient or appropriate.

It is *really* hard to parse from this section that the state applies
to the whole RB when Action is 0, but applies to the elements of the RBs
when Action is 1. At least, that is what I think I parsed from the text
although I also found text in the section that convinced me you meant
something else.

In short, this section is not clear!

---

Why don't Sections 3.4 and 4 have a B-bit like that in 3.2?

---

Sections 3.4 and 4 should list the allowed settings of I and O
(presumably: 01, 10, 11). Cf. Section 3.2.

---

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.

---

Section 4.1

   The following I and E combination are defined:

s/E/O/

---

Section 4.1

           1: [ITU-G.698.1] application code.

           2: [ITU-G.698.2] application code.

           3: [ITU-G.959.1] application code.

           4: [ITU-G.695] application code.

You should use the same format as in the references section. E.g.,
[G.959.1].

Do you mean 698 or 694? You have references for 694.1 and 694.2, but
not 698.1 or 698.2. But 694.1 does not seem to include any "application
codes" - they're in 698.1 and 698.2.

Each of the subsections 4.1.1-4.1.4 should include a citations.

---

Section 4.1
How do I interpret a Vendor-Specific Application Code? Is there an OUI
I'm missing?

---

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.

---

4.1.1 

   Where (values between parenthesis refer to ITU defined values as
   reported above):

Please remove the parentheses from this sentence.

---

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?

---

4.1.1 and 4.1.2

Your definition of parameter c makes RFC 6205 a normative reference.
                                                                              .
I think you could usefully point with more precision to Figure 2 in 
Section 3.2 of RFC 6205.

However, I wonder whether you want to allow new values that may be added
to the IANA registry created by Section 5.2 of RFC 6205

---

4.1.3 and 4.1.4

         n: maximum number of channels (10 bits, up to 1024 channels)

Hmmm, 2^10 is 1024, but 10 bits can only encode 1023 unless you say that
n=0 is not valid and so n is actually max channels minus one.

---

4.4

   The processing capability list field is then given by:

      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           |        Processing Cap ID      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Possible additional capability parameters depending upon    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :   the processing ID                                           :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When the processing Cap ID is "regeneration capability", the

I don't believe you have told me how to encode "regeneration
capability" into the Processing Cap ID field. Possibly you mean that the
numbered list above is intended to define the settings of this field.
                                            
If so then:
- say so
- explain that "Fault and performance monitoring" and "Vendor Specific
  capability" have no additional capability parameters
- probably remove the note about "Fault and performance monitoring" and
  "vendor specific capability" because if it isn't here it is, of
  course, for future study.

---

4.4

   Note that when the capability of regenerator is indicated to be
   Selective Regeneration Pools, regeneration pool properties such as
   input and output restrictions and availability need to be specified.
   The code point for this is subject to further study.

I think you mean to replace that final line with...

   These properties will be encoded in the capabilities field starting
   with the bits marked Reserved in the figure.  An additional
   specification describing the encoding of these parameters is required
   before the value C=2 can be used.

---

Section 6

In Section 6 and 6.1 you appear to be creating a new top-level registry
called "GMPLS Routing Parameters for WSON" with a sub-registry called
"Types for subfields of WSON Resource Block Information".

It's a shame to create a whole new top-level registry. I suppose you 
think that this information will only ever be used in routing and
never in signaling. Probably right, in which case you are good to go,
although your text could be clearer.

---

Section A.3 is using some form of BNF to represent information.

This is probably RBNF from RFC 5511. Anyway, you need to give a
reference so people can read it.

It would be nice to lay the BNF out on the page in a more readable way.

---

From: Leeyoung <[email-masked]>
Date: Wed, 14 Jan 2015 23:20:20 +0000

Hi Adrian,

Thanks. 

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.

Thanks,
Young
-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, January 02, 2015 2:15 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

Hello,

Adrian

===========

Abstract

[YOUNG] YES. 

---

[YOUNG] A good point. Will add this. 

---

The Introduction has

and

[YOUNG] will remove 'relatively'.

---

Section 1.1 has

[YOUNG] Yes. Will change. 
---

[YOUNG] Yes. Will correct. 

---

[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. 
---

Section 2.1

[YOUNG] Flex-grid is out of scope here. 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. 
 
---

Section 3.1

[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. 

---

Section 3.2

[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. 

---

Section 3.3

[YOUNG] RB is wavelength converters, which is a unique WSON element. 
---

Section 3.3

But...

[YOUNG] Indeed it is not clear. For this, let me get back to you shortly. 

---

[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. 

---

[YOUNG] OK. How adding:

Currently the only valid combinations of (I,O) are (0,1), (1,0), or (1,1). 

---

Section 4

[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                    |
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      
Length: 16 bits

   The total length of this field in bytes.

---

Section 4.1

s/E/O/

[YOUNG] Agree. Thanks.
---

Section 4.1

[YOUNG] Yes, for the reference format. The right references are 698.1 and 698.2 --- will correct with the right references. Citations will be added in each of the subsections. 
---

Section 4.1

[YOUNG] Not sure if I understood this question. What is "OUI"? 

---

[YOUNG] Thanks. It is a good idea to send a liaison to Q6/15. 

---

4.1.1 

[YOUNG] OK. 
---

4.1.1 and 4.1.2

      0                   1                   2                   3

[YOUNG] I guess 0 will do it. 

---

4.1.1 and 4.1.2

[YOUNG] OK. Will change RFC 6205 as a normative reference and point with more precision to Fig. 2 in Section 3.2 of RFC 6205. Since we are not adding values to the channel spacing here, I am not sure if it is appropriate to discuss this in this document.
---

4.1.3 and 4.1.4

[YOUNG] I would change: 1024 -> 1023.
---

4.4

      0                   1                   2                   3

                                            
If so then:
- say so

[YOUNG] Yes, how about adding right after the encoding and before, "when ..." the following: 

   The processing capability ID field defines the following processing capabilities:

     0: Reserved

     1: Regeneration capability

     2: Fault and performance monitoring

     3: Vendor Specific capability

[YOUNG] OK, will remove the note on the further study and add: 

"Fault and performance monitoring" and "Vendor Specific
  capability" have no additional capability parameters. 

---

4.4

[YOUNG] Thanks. Agree. 

---

Section 6

[YOUNG] Unfortunately it is only intended for Routing. Will add this is the case in the text. 

---

[YOUNG] OK, will reference and do some cosmetic surgery on this. 

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Leeyoung <[email-masked]>
Date: Thu, 15 Jan 2015 20:06:22 +0000

Hi Adrian, 

There was one question I left unanswered in the previous email. Here's my comment. You said:

---

Section 3.3

But...

[YOUNG]  How about: 

OLD: RB#i State (16 bits, unsigned integer): indicates Resource Block #i
   is in use or available.
NEW: RB#i State (16 bits, unsigned integer): indicates the number of resources available in Resource Block #i.

Action = 1 covers the case where each resource block only contains a single element. 
Action = 0 covers the case where there are multiple elements for each resource block. 

Hope this helps. Thanks.

Young

-----Original Message-----
From: Leeyoung 
Sent: Wednesday, January 14, 2015 5:20 PM
To: [email-masked]'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

Hi Adrian,

Thanks. 

Thanks,
Young
-----Original Message-----
From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, January 02, 2015 2:15 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

Hello,

Adrian

===========

Abstract

[YOUNG] YES. 

---

---

The Introduction has

and

---

Section 1.1 has

---

Section 2.1

 
---

Section 3.1

---

Section 3.2

---

Section 3.3

Section 3.3

But...

---

---

[YOUNG] OK. How adding:

---

Section 4

  	 0                   1                   2                   3
      
Length: 16 bits

---

Section 4.1

s/E/O/

[YOUNG] Agree. Thanks.
---

Section 4.1

Section 4.1

---

---

4.1.1 

[YOUNG] OK. 
---

4.1.1 and 4.1.2

      0                   1                   2                   3

---

4.1.1 and 4.1.2

4.1.3 and 4.1.4

4.4

      0                   1                   2                   3

                                            
If so then:
- say so

     0: Reserved

---

4.4

[YOUNG] Thanks. Agree. 

---

Section 6

---

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 Jan 2015 20:35:50 -0000

This is much clearer. Thanks!
Adrian

> From: Leeyoung [mailto:[email-masked]]
> Sent: 15 January 2015 20:06
> To: Leeyoung; [email-masked]; draft-ietf-ccamp-rwa-wson-
> [email-masked]
> different entities where possible. This is fine for label vs. wavelength as
there is
> one-to-one mapping for this.
> [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.
> [YOUNG] Flex-grid is out of scope here. In addition, RB identifier is a
resource
> block ID
> Wavelength id can be used for RB identifier. They seemed to refer two
different
> entities.
> 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.
> 
> ---
> 
> Section 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.
> 
> ---
> 
> [YOUNG] Yes, for the reference format. The right references are 698.1 and
698.2
> --- will correct with the right references. Citations will be added in each of
the
> subsections.
.
> [YOUNG] OK. Will change RFC 6205 as a normative reference and point with more
> precision to Fig. 2 in Section 3.2 of RFC 6205. Since we are not adding values
to the
> channel spacing here, I am not sure if it is appropriate to discuss this in
this
> document.
> [YOUNG] Unfortunately it is only intended for Routing. Will add this is the
case in
> the text.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Jan 2015 20:57:56 -0000

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.

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
there
> is one-to-one mapping for this. However, Resource Block encoding cannot
> properly share with the connectivity matrix encoding with two reasons:
> 
different
have
> 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".

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

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] 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?

single-
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?

> 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.

> [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."

context
> Compared to this, wavelength constraints can more often be same for input and

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?

You didn't comment about section 4.

> [YOUNG] Yes, you're right. It is not completely consistent. How about the

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] 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] 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.

> [YOUNG] I guess 0 will do it.

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

Thanks,
Adrian

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Wed, 21 Jan 2015 21:21:59 +0000

Specifically to the Interface class here below… 

In the initial draft merged to this one there was the usage of OUI however (I guess after chatting with Lou) we decided to remove any encoding when the Interface class is not standard. 
In term of semantic the protcol does not need to decode the Interface class since it only assess the interface compatibility if two interfaces has a class value that match two interfaces cann be connected.  

Having saying that I don’t have strong opinion in adding the OUI or leaving room for maybe future public interfaces database. For sure there’s a need to leave room for specific compatibility assesment since there optical multivendor compatibility has been already demonstrated. 

hope this help …

Cheers
G

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Jan 2015 21:55:16 -0000

Hi,

Well, you seem to have a half-way house.

You have specified the existence of a thing, but not how to read it.

If you wanted to make a statement that this object will only be used when it is
known that all systems in a network come from the same vendor and/or have the
same understanding of the encoding, that might be OK (although how you would
ascertain this might also need to be described).

Or you could entirely remove the vendor-specific option.

Or you could put in an OUI / enterprise number followed by transparent bytes.

Adrian

> From: Giovanni Martinelli (giomarti) [mailto:[email-masked]]
> Sent: 21 January 2015 21:22
> To: [email-masked]
> Cc: Leeyoung; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
> 
> Specifically to the Interface class here below.
> 
> In the initial draft merged to this one there was the usage of OUI however (I
> guess after chatting with Lou) we decided to remove any encoding when the
> Interface class is not standard.
> In term of semantic the protcol does not need to decode the Interface class
since
> it only assess the interface compatibility if two interfaces has a class value
that
> match two interfaces cann be connected.
> 
> Having saying that I don't have strong opinion in adding the OUI or leaving
room
> for maybe future public interfaces database. For sure there's a need to leave
> room for specific compatibility assesment since there optical multivendor
> compatibility has been already demonstrated.
> 
> hope this help .
> 
> Cheers
> G
> 
>

---

From: Leeyoung <[email-masked]>
Date: Wed, 21 Jan 2015 22:58:02 +0000

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:[email-masked]] 
Sent: Wednesday, January 21, 2015 2:58 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

Hi,

Thanks for the response.

YOUNG>> OK. 

there
different
have

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.  

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

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. 

OK

globally

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.

single-
was

I don't understand.

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. 

Suppose I wrote:

No!

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.  

context

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

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. 

The question is:

YOUNG>>  See Giovanni's email.  

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

Thanks,
Adrian

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Thu, 22 Jan 2015 08:42:39 +0000

Hi Adrian,

> ascertain this might also need to be described).

The statement is to ensure the interface compatibility without encoding all the possible details and parameter that define an interface (e.g. modulation format, forward error correction etc.). This was the initial solution in the draft then replaced by the interface class concept.   The WSON (RWA-only) has the requirement is to make sure two interface are compatible. This requirement, imho, can be satisfy by a simple comparison which has a boolean result. 

We end up then in  the ITU application codes for the “certified” (we’ll this is my term not 100% sure is the best one) compatibility where proper encoding is provided. 

> Or you could put in an OUI / enterprise number followed by transparent bytes.

To me I’m perfectly fine with the second option. 

Cheers
G

---

From: "Giovanni Martinelli (giomarti)" <[email-masked]>
Date: Fri, 23 Jan 2015 13:49:39 +0000

One additional comment (hoping not additional confusion). 

The idea about Optical Interface Class was taken from SRLG. Good or bad is a plain number and you do simple operations on it. 

Cheers
G

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Jan 2015 18:34:11 -0000

Hi,

Picking up the remaining comments that I haven't cut out into separate threads.

> 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.

 I don't think you should point to the Appendix to achieve explanation in your
text. You should explain the terms more clearly as in my other thread.

That said, figure 1 *is* very helpful. I don't think you should change the
labelling in the figure. The thing it shows is a pool of wavelength converters.
That's good. Perhaps you could add a note as:

OLD
   This wavelength converter pool can be encoded as follows:
NEW
   The wavelength converters are resource blocks and the wavelength
   converter pool is a resource block pool. This can be encoded as follows:
END

> >>    The RB identifier represents the ID of the resource block which is a
[snip] 
> RB Set Field defines the RD ID's and Input/Output Link Sets are associated
with RB
> ID's.

Let me try a different way:
- Who assigns a RB ID?
- Who actually knows what it refers to (in the physical space)?
- Does anyone outside the node itself need to know anything other than
   "A resource block exists, with these properties, and this is its ID"?
- Shouldn't all of the discussion and explanation of terms and concepts 
  be in the Information Model document?

> > single-stage connectivity matrix in [Gen-Encode] that can
> > was not the choice of the authors.
> 
> I don't understand.

OK. I think this may drop out from getting the definition of RB clear as in the
separate thread.
In order that RB is a unique concept applicable only to a WSON node, it must
follow that Resource is similarly a unique concept applicable only to a WSON
node.

Now, the definition we have been arriving at for Resource becomes circular :-(
It is defined in terms of WSON technology (it is a regenerator or a wavelength
converter component in a WSON node).
Could you describe those concepts generically? For example, a wavelength
converter is a component that does a label swap and has severely restricted swap
capabilities. For example, a regenerator is a component that sits in the path,
retains the label, but has a limited input label capability.
It could quite probably be the case that these components only arise in a WSON
system, but it is very helpful to properly describe them in general terms.

Once described in general terms we can decide whether they should be generic
components of the encoding model, or remain as specific for WSON.

> 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.

OK. Got it. We were talking past each other with terminology because I was
looking for the black-box behaviour of a WSON node while you are modelling and
controlling the internal components of a WSON node.

With this in mind, of course you are right. The physical components, that is the
partitioned physical components, only exist in a WSON node.

I, on the other hand, was looking at how you model the generic multi-function
switch. How would you model a switch that was able to selectively switch signals
from one port to another and selectively change the labels applied to those
signals? My claim would be that you use (or could use) exactly the same abstract
components. 

That said, this conversation has gone on long enough. I think that only you and
I are interested in the outcome. That makes me pretty sure that the WG is not
very interested. Equally, it makes me sure I shouldn't get in the way.

> > 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.
> 

I'm sorry if I am driving you to do things "because Adrian says so."

My job is to get you to come to the right answer. It doesn't matter what I think
now. What matters is that you come to the right answer and are able to defend
it. There can be a convincing technical reason that you can explain, or you can
say that there is no significant technical reason to jump either way and so you
have simply picked one way.

> >> document do include lengths or enough information to deduce the lengths.
[snip]
> I grant however there is inconsistency here. Not sure what is the best.
Perhaps,
> effectiveness may be sacrificed unless things are broken.

That is fine.
Please, for the sake of future reviewers, add a note so say "The length of the
ResourceBlockInfo field is determined from the length of the object that
includes it."

> > [YOUNG] Not sure if I understood this question. What is "OUI"?
[snip]
Moved to a separate thread to try to get conclusion.

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

Why can't you
OLD
An Optional F can be added indicating a FEC Encoding.
NEW
The F flag indicates the presence or not of an optional FEC Encoding suffix.
END

and
OLD
F (suffix): = 0 reserved, = 1 Fec Encoding
NEW
F (suffix): = 0 No FEC Encoding suffix present, = 1 FEC Encoding suffix present
END

Adrian

---

From: Leeyoung <[email-masked]>
Date: Mon, 26 Jan 2015 18:20:24 +0000

Hi Adrian,

Thanks. Please see inline for my response. 

Young

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, January 23, 2015 12:34 PM
To: Leeyoung; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode

Hi,

to

OLD

YOUNG>> OK. That's fine with me. 

[snip] 
with RB

YOUNG>> I think it can be assigned by the configuration entity of the management plane or can be manually configured. 

YOUNG>> In the physical space it is wavelength converter pool. The network operators must know this entity as they are installing this block in their nodes.

YOUNG>> The specified list is sufficient and the RB encoding is exactly trying to give these information to outsiders (e.g., path computation entity) so that these constraints would be factored in. 

YOUNG>> Yes, per your request, this is done in the info. Model doc. 

YOUNG>> In light of the next point below, shall we drop out this discussion? 

YOUNG>> Yes, thanks. 

YOUNG>> I will add an extra bit in Sections 3.4 and 4. I wouldn't imagine this bit will be ever useful in practices, but as you convinced me there may be a very rare case for the usefulness of this bit. 

[snip]
Perhaps,

That is fine.

YOUNG>> OK. 

[snip]

Why can't you
OLD

and
OLD

YOUNG>> Thanks, will change as such.

Adrian