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

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 23 January 2015 18:34 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 839E21ACDD3 for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 10:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.378
X-Spam-Level:
X-Spam-Status: No, score=-99.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_SLUT=2.522, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no
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 G2GUE-Fk-Aph for <ccamp@ietfa.amsl.com>; Fri, 23 Jan 2015 10:34:25 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED011ACDCF for <ccamp@ietf.org>; Fri, 23 Jan 2015 10:34:24 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIYIOU003130; Fri, 23 Jan 2015 18:34:18 GMT
Received: from 950129200 (089144209017.atnat0018.highway.a1.net [89.144.209.17]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t0NIYBkn003043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 18:34:17 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Leeyoung'" <leeyoung@huawei.com>, <draft-ietf-ccamp-rwa-wson-encode.all@tools.ietf.org>
References: <00dd01d026c8$c3bd9280$4b38b780$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C71AC5@dfweml706-chm> <02f401d035bc$efc05ef0$cf411cd0$@olddog.co.uk> <7AEB3D6833318045B4AE71C2C87E8E1729C7DA1A@dfweml706-chm>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729C7DA1A@dfweml706-chm>
Date: Fri, 23 Jan 2015 18:34:11 -0000
Message-ID: <009801d0373b$32210f90$96632eb0$@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: AQGuBc8fgeeljdJ0ZqOUd7m3it/ADQJ3wIujAyk0V7MCCvPLSJzU0GSw
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--25.945-10.0-31-10
X-imss-scan-details: No--25.945-10.0-31-10
X-TMASE-MatchedRID: 8HTFlOrbAtHoItLliax8Q7Gj3LN0+Ey9H9w9ONeWwHKqvcIF1TcLYKmw 5s23nMRbg1Z+dMbI6xQ6c6vDFSAdOBikjLq23VARlTsGW3DmpUsxmbT6wQT2ayP8GBeiiqDDJz/ Fli73wMiS/tZ2a/cX4+DFtzSqSPhRfF2w37ROyLM5yOdvO+rz33nL427v8Q46mBadosOIaCE+xn rY8SIOUh+33+vWXrpPW1TaGz/XYhSBupdkaEeObs1GzI6JnJjKH181YDtIVaqL+72Niu/rKbt+i +Gg5iN89fAy5OzP/1Mlqegxl8Tt3mlaYefQTGcyMtFjrTUutqR+Mk6ACsw4Jh9W4auM/sn0zVfj PwElWIrfw0uruGlfw5kLx6fQB6+1QpfQxLB50m0gKw/iul4Zx35Lmbb/xUuaYgFKBJUH5aO0nj9 xfM4ElGUPU2xFnfcx/HUNnzD9of40nllLIxRZ5obBPrt55wnwKVrLOZD1BXTE3grQNcpLWL4OWM 8hMbOS1jTArul9RVP3CbhR1iOkb3XHdWrIeHKU2OSj4qJA9QYHSA1qABZYHsI9dI7bfY/vlVRTv f2hoTyMEUuvpm4xfCOqG1yPKER2ahqNaxEQeGh7k1ZHmKLF7Vt06oMfzUpKeNDQ2odiEiGBuLDz zkmS1/EdLUjZYlvwteD6gJDksuS26aZT+DLr1IvtmwtVGLEkMJebi1vXnNOp7t/yrVnxkBZaDvo iUT/M5oP7fDAckCqun8wjeYlO709iedN46vv1SEQN/D/3cG5Cs7hdHoFFA2M+uU0H6Ayr33pzMs MDyh/Bu0rxt7xJrbGjgTsA6f3+e4eN1GlxwYeeAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/8e_sI-gK1A4XZ4yU3_GqaxxVDE8>
Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-rwa-wson-encode
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:34:28 -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

> >> Section 2.1
> >>
> >>    The RB identifier represents the ID of the resource block which is a
> >>    32 bit integer.
[snip] 
> 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.

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?

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

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.

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

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.

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

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.

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

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

> >> 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"?
[snip]
Moved to a separate thread to try to get conclusion.

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

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