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

"Adrian Farrel" <> Wed, 21 January 2015 20:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D216A1A8839 for <>; Wed, 21 Jan 2015 12:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -97.978
X-Spam-Status: No, score=-97.978 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FRT_SLUT=2.522, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B0zmVQecSIYO for <>; Wed, 21 Jan 2015 12:58:59 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E79F31A8830 for <>; Wed, 21 Jan 2015 12:58:58 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t0LKvxn7002976; Wed, 21 Jan 2015 20:58:00 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0LKvvEH002967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2015 20:57:58 GMT
From: "Adrian Farrel" <>
To: "'Leeyoung'" <>, <>
References: <00dd01d026c8$c3bd9280$4b38b780$> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm>
Date: Wed, 21 Jan 2015 20:57:56 -0000
Message-ID: <02f401d035bc$efc05ef0$cf411cd0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujnPuGDVA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--15.477-10.0-31-10
X-imss-scan-details: No--15.477-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtGnykMun0J1wrmR+C0l9vjV8GRhP/nTHNbYWrp179pohj0J SifQ1MZ5roveI71hB0Qjk/kPI8DPx05GqmwdJt7C6vGX8vR+hqjiXOoSlo9AtYJMlS+kMGbc0xj TQ8V5r3Fs9C4m/Ueo/d+Jza/a9teag+QbvWfvu8i8coKUcaOOve8lj2kHOCDUidYwmfMI8uBBD+ z28Qkmd+17CrIRoHb2BupkzfMOQXS/JxRBHWTApiArD+K6XhnH9xIiieITJaiynk7TnYzMuvJvf lJl1oGsw/UdL9EcJmaOVKjw5IrenybZZYAQu9H5y7TSWcbz49b4uJ1REX4MHX3hz57t9YhwAy7F ge6wFlu91njNIDBTO5LC6W0yRmUXw96zDQifY+gIVoCLGbl5T0GtrAxy5ENO9WxlDvtT3Nz+1Hn niUzVLbe0s3JW76HN8TxBP2FxIFbcx97ZZVZcMuLdprnA5EQR2LfeG0uDflTNpr24oOS4xpYnOA NpMjh38bJb0aNG//+3LXha6kS5H3LoyH4Gm9PGACs2C3nGlBh+K68qL2G5phxUkJPe1WBq4vbk6 0X83gCCpWo1JYSZWlmEt4PHleWrtSRDUDvza5OQTsyupo9izR6InYiNINGdBoA1fKObuhMcaYAs 8/F61zt5/UisYj5O7QHRY5U6Rkdu6WKkJ3C7LDLRY601LrakY9JlLwL1dg3a+IH8mvgPVJvgUg7 gsdlOjFXb0YkfwXv4lJQPIqA7oMPXVOccBDU9iFoorQjboWnGdQx1K0CtmVmmz7LVVfOpGfrX8m YF7oeOr9X/y8WA5URZ83DrGmyHKEVn4TCGPMCeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtwcipXRZMawu5a5XvBUru6kEtJLs9rWW9/f0lFVz5KSJwxxkR8eEZ9g==
Archived-At: <>
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Jan 2015 20:59:03 -0000


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
> different entities where possible. This is fine for label vs. wavelength as
> 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
> fields.
> Link Set has directionality and identifier format while Label Set does not
> 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".

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.

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

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

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


> In addition, RB identifier is a resource
> block ID Which is different from wavelength identifier. I am sure how a
> 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?

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

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

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.

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

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

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?

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

Or perhaps an Enterprise Number

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?

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