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

[Leeyoung <[e-mail]>]

Hi Adrian,

Thanks. Please see inline for my response. 

Young

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

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

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

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

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

- Who actually knows what it refers to (in the physical space)?

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.

- Does anyone outside the node itself need to know anything other than
   "A resource block exists, with these properties, and this is its ID"?

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. 

- Shouldn't all of the discussion and explanation of terms and concepts 
  be in the Information Model document?

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

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

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

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

YOUNG>> Yes, thanks. 

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

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. 

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

YOUNG>> OK. 

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


YOUNG>> Thanks, will change as such.

Adrian