Re: [CCAMP] TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt

[Greg Bernstein <[e-mail]>]

 From the Prague meeting notes, the purpose of this work was to look 
into a possible inefficiency in the encoding used in the WSON drafts. 
Not an arbitrary rewrite of the WSON Info, WSON encoding, General 
Constraints Encoding, WSON specifc OSPF extensions, and General 
Constraint extensions for OSPF.  Any change needs to be justified with 
clear evidence showing that
(1) There is a problem -- including
     (a) The problem is realistic
     (b) The problem cannot be address by mechanisms within the current 
WG drafts and standard practices such as OSPF instances for separating 
dynamic and static information.
(2) An analysis that shows precisely where in the current scheme 
facilities are lacking
(3) A proposed solution that makes minimal changes to the existing 
documents.

The Peloso draft-03 fails on all these accounts by starting with a long 
list of proposed changes that do not appear tied to solving a particular 
encoding problem. The "example node" is insufficiently documented to 
ascertain either 1(a) or 1(b) above.  Item 2 is inadequately addressed, 
example sub-TLVs are not given, etc... If there is an problem encoding a 
particular type of optical system we can fix it as soon as we know what 
it is.  However, general changes to the current WG drafts are out of 
scope of this particular effort.

Greg

On 6/17/2011 2:06 AM, PELOSO, PIERRE (PIERRE) wrote:
> Hi Fatai,
> When having an info model, there are two things, the first as you 
> mention consists in describing which information are to be considered 
> for a CP, the second consists in descibing how this information is 
> modelized (meaning how it is organized otherwise that is not a model) 
> and that is what was already done - e.g. draft-ietf-ccamp-rwa-info 
> relies on RBNFs to describe the model.
> Here, the main impact is on the second point, the way the information 
> is organized, more than on which information is to be described.
> Hence, in order to address your concern of a summary of differences 
> between the info model, I would suggest interested parties to read the 
> section 5.1 of draft-peloso-ccamp-wson-ospf-oeo-03.
> http://tools.ietf.org/html/draft-peloso-ccamp-wson-ospf-oeo-03#section-5.1
> Regards,
> Pierre
>
>     ------------------------------------------------------------------------
>     *De :* Fatai Zhang [mailto:[e-mail]]
>     *Envoyé :* vendredi 17 juin 2011 10:46
>     *À :* PELOSO, PIERRE (PIERRE); 'Greg Bernstein'
>     *Cc :* [e-mail]
>     *Objet :* RE: [CCAMP] TR: New Version Notification
>     fordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
>     Hi Pierre,
>
>     We know that it follows the logic (WSON Framework->WSON Info
>     model->WSON Encoding->OSPF/RSVP-TE extensions) for WSON work.
>
>     Let’s focus on WSON Info model first. We know that [Info Model]
>     only describe what information should be considered for CP in WSON
>     network.
>
>     You said “it has significant impact on the info model, the
>     encodings and the LSA layout (hence OSPF-TE)”.
>
>     Could you tell the WG what is the significant impact on info model
>     first? What information is missed or what information is redundant
>     in [ietf-ccamp-rwa-info]?
>
>     Thanks
>
>     Fatai
>
>     *From:*[e-mail] [mailto:[e-mail]] *On
>     Behalf Of *PELOSO, PIERRE (PIERRE)
>     *Sent:* 2011年6月17日5:43
>     *To:* Greg Bernstein
>     *Cc:* [e-mail]
>     *Subject:* Re: [CCAMP] TR: New Version Notification
>     fordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
>     Hi Greg, Ccamper's
>
>     First of all thanks for your comments, we'll make sure to
>     integrate them properly in the revision to come of draft-peloso-.
>
>     We understand the impression given by the length of the draft,
>     this comes actually from two facts: first the request by the WG
>     and its chairs indications to gather in a single document the
>     changes from info down to OSPF-TE and second that the 5
>     drafts with which we are drawing a parallel are lengthy themselves
>     once concatenated, which we cannot avoid ourselves.
>
>     To ease anyone's reading, we'll see how to arrange things in the
>     next revision, though ccamper's shall not expect a big reduction
>     of pages as the deltas between the solutions proposed are more
>     important than you summarized to the WG. This changes
>     permitted to reach the gain in LSA size that we obtained
>     especially concering the updates (read section 5). From a
>     high-level view, most of the modifications target the WSON part,
>     it has significant impact on the info model, the encodings and the
>     LSA layout (hence OSPF-TE).
>
>     We've noticed you were concerned by the way we conducted the size
>     study. First, we have determined and described a given set of
>     nodes we wanted to work on in a futur proof though reasonnable
>     perspective. Second, we have used the drafts contents nammely
>     recommendations of the info models and the encodings in order to
>     derive the encodings then summed them to determine the size of
>     each LSA, for each of the solutions.We thought anyone familiar
>     with the drafts to proceed similarly, hence would have the
>     capability to doublecheck. Reading your past emails, I have not
>     noticed yet any doubt express there relative to our misusing the
>     previous draft that reveals itself accurate, then I keep trusting
>     the accuracy of section 5.
>
>     To help the discussion move forward, we'll detail more the node
>     models we've taken. In the meanwhile, feel free to explicit the
>     one you want to consider, if you wish to do a study.
>
>     Finally, you mention the optional feature of OSPF-TE named
>     multi-LSA instance, that you seem to advocate as the solution to
>     limit update sizes, and I am sorry to point that we have
>     indeed provided such results inside section 5 of draft-peloso- not
>     at the advantage of multi-instance. Though, the lack inside
>     currrent drafts on how to proceed, forced us to best-guess. We
>     would be glad (as I bet the WG would) to be told in which instance
>     shall be which TLVs.
>
>     Pierre
>
>     ------------------------------------------------------------------------
>
>     *De :*[e-mail] [mailto:[e-mail]] *De
>     la part de* Greg Bernstein
>     *Envoyé :* jeudi 16 juin 2011 20:02
>     *À :* Margaria, Cyril (NSN - DE/Munich)
>     *Cc :* [e-mail]
>     *Objet :* Re: [CCAMP] TR: New Version Notification
>     fordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
>         Hi Cyril, can you furnish diagrams of the optical nodes, and
>         the encodings chosen when using the current WG documents. From
>         the Peloso draft there is insufficient information to see
>         where the encoding numbers quoted came from.  The current
>         draft-ietf-ccamp-rwa-wson-encode-11.txt makes it relatively
>         efficient to deal with lots of different regenerator types. In
>         section 4.1 "Resource Block Information Sub-TLV" is defined as:
>
>             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
>                                       |
>            :                                                          
>             :
>           
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |I|E|                        Reserved     
>                              |
>           
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |           Input Modulation Type List Sub-Sub-TLV 
>         (opt)       |
>           
>         :                                                               :
>           
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |           Input FEC Type List Sub-Sub-TLV   
>         (opt)            |
>            :                                                          
>             :
>           
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |         Input Client Signal Type Sub-Sub-TLV     
>         (opt)       |
>            :               
>                                                        :
>           
>         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |        More resource description                     
>                 |
>           
>         :                                                               :
>
>         The RB set field in this sub-TLV allows you to specify once
>         all the properties of a class of regenerators and apply it to
>         a set of resource blocks. Hence this scales as the number of
>         regenerator types not as the number of resource blocks.  Hence
>         the existing WSON encoding should solve your problem of many
>         types of regenerators within an optical node.
>
>         Without further information I can't see how the Peloso draft
>         gets the numbers it quotes for the size of the information to
>         be distributed. In addition it doesn't appear that the Peloso
>         draft uses the OSPF group's recommended practice of multiple
>         LSA instances. But once again insufficient information is
>         given to justify the numbers. If there is a problem with
>         encoding for a particular switch case I'm sure we can quickly
>         find a solution that has a minimal impact on the existing WSON
>         related WG drafts, but first we really need to understand the
>         optical node and the cause (if any) the the encoding expansion.
>
>         Greg B.
>
>
>         On 6/15/2011 12:35 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
>
>         Hi Greg, CCAMPers,
>
>         Regarding point (2), using one regen type per OTUk (k in
>         [[1..4]]), and 2 type of laser module per reach makes already
>         8 type of oeo properties. Adding slightly different hw types
>         (i.e old board with old modulation and a more recent with
>         DP-QPSK) makes an easy 10 types for a big node.
>
>         Without going into product families this sounded reasonable
>         (for instance a typical product would indicate supports for 10
>         and 40g with different modulation, so lets say 2 sub-board
>         type, which makes 6 regen type); The introduction of OTU4 and
>         later OTU5 will increase the types of regenerator supported.
>
>         The size expansion is indeed related to the number of
>         regenerator type, resource blocks contain connectivity,
>         oeo-feature and how the blocks are grouped.
>
>         The other point would indeed clarify the document, the setup
>         of resource pools/blocks is shown in Figure 1, a resource pool
>         aggregating  the connectivity for several resource blocks.
>
>         Best regards.
>
>         *From:*[e-mail] <mailto:[e-mail]>
>         [mailto:[e-mail]] *On Behalf Of *ext Greg Bernstein
>         *Sent:* Monday, June 13, 2011 8:20 PM
>         *To:* [e-mail] <mailto:[e-mail]>
>         *Subject:* Re: [CCAMP] TR: New Version Notification
>         fordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
>         Hi Pierre and draft authors, can you provide:
>         (1) Diagrams of the example switches particularly with respect
>         to the structure of the resource pools/blocks.
>         (2) Explanation of why so many different types (not number) of
>         regenerators in an optical node. You site 5 different types
>         for a small node and 10 for a large node. Can you point to a
>         product family?  I would think 0-1 types of regenerators for a
>         small node and at maybe 2 for a large node or nodes that deal
>         with long haul and metro types modulations.
>         (3) Can you provide the example encodings such as done in the
>         appendix of the encoding document so we can understand where
>         the expansion is taking place.
>
>         It seems that the size expansions is directly related to the
>         number of regenerator types, but hard to tell from this
>         document.  Are there any other WSON interested parties that
>         have a need for so many regenerator types?
>
>         Cheers
>
>         Greg B.
>
>         --snip --
>
>         -- 
>
>         ===================================================
>
>         Dr Greg Bernstein, Grotto Networking [phone]
>
>           
>


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