[CCAMP] Review of draft-peloso-ccamp-wson-ospf-oeo-03.txt and Next Steps proposal...

[Greg Bernstein <[e-mail]>]

Hi CCAMPers interested in WSON, the recently published 
"draft-peloso-ccamp-wson-ospf-oeo-03.txt" is extremely long (41 pages) 
so I'm not sure who will be reading it in its entirety other than 
myself. Below I'll try to summarize the document from my perspective and 
to aid the work group in trying to figure out where to go next.

An important thing to note is that there are many essentially equivalent 
ways of formulating the WSON information model, its encoding, and its 
packing into OSPF LSAs. The current CCAMP WG drafts 
[draft-ietf-ccamp-rwa-info-11 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info/>, 
draft-ietf-ccamp-general-constraint-encode-05 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/>, 
draft-ietf-ccamp-rwa-wson-encode-11 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/>, 
draft-ietf-ccamp-wson-signal-compatibility-ospf-04 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/>, 
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-general-constraints-ospf-te/> 
] present one formulation. At the Prague IETF Pierre indicated that 
additional encoding efficiencies might be possible. The straight forward 
way to illustrate this would be to show an example optical node, show 
the most efficient encoding using the current WG drafts, then show via a 
minimal set of changes to the current WG drafts how much space savings 
could be realized. Unfortunately the document 
"draft-peloso-ccamp-wson-ospf-oeo-03.txt" does not do this.

(1) "draft-peloso-ccamp-wson-ospf-oeo-03.txt" starts with over 31 pages 
of text predominantly taken from the five current CCAMP working group 
drafts mentioned above. Most of these are very small conceptual changes, 
i.e., moving some information from some containers (TLVs, sub-TLVs, 
etc...) to others and hence not resulting any significant encoding space 
savings.
(2) In the first 31 pages there is one new indirection mechanism added 
for identifiers for resource pools which could be helpful in what seems 
an unusual optical node.
(3) Section 5 is a "Solution(s) Evaluation". It begins with a "RBNFs 
Comparison", then proceeds with "5.2 Depiction of the considered cases 
for evaluation". This is a key section but does not include any diagrams 
of the optical nodes so readers can determine whether these are 
important examples of practical optical nodes or example constructions 
that would tend to not be used in practice.
(4)  Section 5.3 "Comparing evaluation of the solutions" should be the 
longest section of the document but instead is only a page long. It 
cites numbers for the "cases for evaluation", but provides no basis for 
the numbers or an analysis of why for these cases the encoding presented 
is better than that in the current WG drafts.

*My recommendations based on this draft:*
Hidden deep in the text of section "5.2 Depiction of the considered 
cases for evaluation"  we see the text
  o  Number of resourceBlock.  There is two numbers to be considered
       here : the number of resourceBlock for a given resource pool (this
       document) and total number of resourceBlock
       ([I-D.ietf-ccamp-rwa-info]).  In this document the number of
       resource block within a resource pool is, worst case, the number
       of possible regenerator types, whereas in
**      [I-D.ietf-ccamp-rwa-info] the number of resource block depends on
**      the number of OEO types and on the connectivity.

**Here is where the encoding differences seem to take place. For the 
constructed examples (that are not explicitly given) it seems that 
they've randomly assigned (or worse than random) different regenerator 
types to blocks to obtain none of the coding advantages of the current 
WG draft scheme.

Hence the only encoding problem that is pointed out in this draft can be 
solved with their proposed indirection mechanism (resource pool/block 
ID) but none of the other changes proposed in this document to Info 
model, encoding, or OSPF drafts are necessary. If the authors can 
rewrite this draft in reverse order (problem, analysis, solution) where 
the solution involves minimal changes to the existing CCAMP WSON related 
WG drafts then the WG should have a sound basis to make a decision and 
it should be easy for the editors of the existing CCAMP WSON drafts to 
incorporate any changes if desired by the WG.

Cheers
Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]