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

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

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]