[CCAMP] Change 3: Reduction of the scope of Resource Block Information (was Re: Moving the WSON discussion forward)

["PELOSO, PIERRE (PIERRE)" <[e-mail]>]

Hi Greg and CCAMPer's,

As in the preceding mail which summarized the 3 main changes proposed by draft-peloso-ccamp-wson-ospf-oeo, become too big to be easily read through,
I've been splitting the 3 points in 3 different threads, this one deals with change 3:  
Reduction of the scope of Resource Block Information, to keep only resource/device description (moved the number of devices away).
MOTIVATION: a/ to share resource description for all the (same devices) blocks (of a node), then decreasing the total size of information. b/ to create an independent flooding entity holding all the resource descriptions (which are static), the decreasing the size of updated information.

Best Regards,

Pierre

[SNIP] 
>>>       3. Reduction of the scope of Resource Block Information, to 
>>> keep only resource/device description (moved the number of devices away).
>>> MOTIVATION: a/ to share resource description for all the (same
>>> devices) blocks (of a node), then decreasing the total size of 
>>> information. b/ to create an independent flooding entity holding all 
>>> the resource descriptions (which are static), the decreasing the 
>>> size of updated information.
>> -->  This change (a) does not result in any size savings, and (b) is 
>> --> not
>> necessary to "to create an independent flooding entity holding all 
>> the resource descriptions".  Resource block information is already a 
>> separate sub-TLV and the current resource block set mechanism 
>> provides a highly efficient method to indicate which resources blocks 
>> are associated with a particular type of resource.
>>
> I consider the contradiction to your statement is in the example 
> you've been providing in the email: "Current WSON encodings...".
> In this example there are 200 wavelength converters of 10 different 
> types, spread over 4 physical pools/WC group.
> Following the Resource Block definition, that gives 40 of those each 
> having a priori different number of wavelength converters.
> So, a priori 40 different Resource Block Informations TLVs are needed, 
> which change significantly the size of the LSA.
--> Hmm, this is where we seem to differ. The example shows that we have
one information encoding for each type of resource which gives 10 and not 40.  The Resource Block Info sub-TLV begins with an RB Set Field which specifies in compact form all the resource blocks that are of this particular type. This was changed in the transition from the 09 to the 10 (published 3/14/2011). Hence I guess the Peloso-03 analysis was based on the old version and is no longer applicable.

-->Pierre:
Thanks, for your answer Greg, but I am worried you answered without reading the whole point provided by Cyril.
At the stage, you've been answering, Cyril was stating what the logics of the draft-ietf-ccamp-rwa-info induces the reader to do, namely, use the resource blocks to achieve efficient encodings, I'm quoting the draft below (section 5):
"For modeling purposes and encoding efficiency identical processing resources such as regenerators or wavelength converters with identical limitations, and processing and accessibility properties are grouped into "blocks". Such blocks can consist of a single resource, though grouping resources into blocks leads to more efficient encodings."
And in the part of the email, below Cyril (and ourselves as well) is challenging the fact that for efficient encoding you end-up using a single resource per block, enforcing a proper resource block ID (then equivalent to resource ID) that allows efficient encoding as you can then luckily encode resource block sets with ID ranges. This is a very specific case, that effectively enables efficient encoding, but at which cost?
Then some questions were raised at the end of the email, like: 
   - Is this analysis correct, is it the reason why the max-number of resources was not included in your example or is there another reason?

--> only need one of these per type of resource:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     RB Set Field                              |
    :         List of resource WC IDs that are of this type         |
    |         Length in words = 1 + ceil{(Num WC total)/(2*NT)}     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|0|                      Reserved                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Input Modulation Type List Sub-Sub-TLV              |
    :        (The receivers can only process NRZ)                   :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Input FEC Type List Sub-Sub-TLV                     |
    :           (Only Standard SDH and G.709 FECs)                  :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Input Client Signal Type Sub-TLV                      |
    :              (GPIDs for SDH and G.709)                        :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Input Bit Rate Range List  Sub-Sub-TLV                |
    :                          (2.5Gbps, 10Gbps)                    :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Processing Capabilities List Sub-Sub-TLV              |
    :                    Fixed (non optional) 3R regeneration       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Output Modulation Type List Sub-Sub-TLV               |
    :                          NRZ                                  :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Output FEC Type List Sub-Sub-TLV                      |
    :                 Standard SDH, G.709 FECs                      :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> By  giving-up the definition of Resource Block with the max-number, it 
> creates then 200 of those (one per wavelength converter).
> This results in associating each individual wavelength converter to a 
> one of the 10 different Resource Block Information TLV created.
> Applying our solution, demands to determine 40 Resource Block IDs, 
> then to define 10 different Resource Description TLV, associated each with 4 of the preceding Resource Block IDs.
>
> Is this analysis correct, is it the reason why the max-number of 
> resources was not included in your example or is there another reason?