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

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

Hi Greg,

I clearly get your will of understanding how the evaluation in section 5 was conducted, and
I've noticed you were concerned by 2 points:
  - 1 the node model and node diagram. The way we have conducted the study, we refered to generic types of nodes (independant of the node internal structure), as we wanted the study not to be specific to a given product or architecture. Basically we have taken values for the items that are modeled by the information model. Though, for each case, we can provide multiple architectures (then diagrams) which would provide the same hypothesis. Our text in section 5.2 is certainly perfectible, hence if when reading it some points are either unclear or lacking to help the reader understand, please let us know which ones. Section 5.2 is quoted below.
  - 2 the encodings as used for current drafts. I have to say I fail in understanding what you mean there. The encodings are provided in the drafts, we have used the drafts indications to determine those, as you are the editor of this draft, I would guess you would know how to determine those. Apart from tiny details, there is no much degree of freedom  in the way of encoding a given structure (which is to be hoped for in the frame of standardized protocol extensions). Can you help me then understand your point ?

   o  Node Degree Connectivity: 4, 8 and 16.

   o  WDM capacity: 100 wavelengths.

   o  Switching capacity.  Defines the total node switching capability
      and is calculated as Node Degree Connectivity x 100 wavelengths.

   o  Regeneration Capability.  We assume a value of 5% of the total
      switching capacity.

   o  Add/Drop Capability.  We assume a typical value of 25% of the
      switching capability.  So in the average up to 30 wavelengths per
      incoming fiber can be added/dropped within the optical node.

   o  Resource pool setup and capabilities.  A physical resource pool
      contains a mix of Add/Drop and Regeneration capabilities.  This
      has the effect of increasing the number of resource pool
      advertized.  Resource pool can be fully flexible (connected to any
      port), partial (only to some port) or Fixed (can only be connected
      to one direction).  This parameter influences the complexity of
      the connectivity matrix.

   o  Number of Regenerator types.  For a given node the number of OEO
      capabilities is limited, it is typically decided by the type of
      electrical equipment and optical modules (emitting laser and
      optical receiver).

   o  Blocking Ratio.  The Spatial/Spectral blocking ratio indicates how
      much port-based/wavelength based blocking a node is experiencing.

   For example considering the typical design it results in the
   following static layout:

   o  3 OEO pools each having 3 Resource Block inside.

   o  Connectivity Matrix: (8+30+30) 64x64 if considering one
      connectivity matrix.  Ingress=64x3, Egress=3x64 (considering the
      OEO access with a multiple-wavelength link).

   The following types of nodes and node designs were considered in this
   evaluation:

                          Node Types and designs

                 Node Type       Nodal Degree Pool Type Blocking
            Small(S), Flexible         4       Partial    None
           Small(S), Fixed(port)       4        Fixed     Port
          Small(S), Fixed(label)       4       Partial   Lambda
            Middle(M), Flexible        8       Flexible   None
            Large(L), Flexible        16       Flexible   None

   For the small nodes, 5 different type of regenerators are considered,
   for the Middle and Large ones 10 different type of regenerators are
   considered.  Based on those designs we derived the following
   important figures:

   o  Number of resourcePool : depends on the pool type and
      connectivity, which depend on the port blocking and number of Add/
      Drop and Regenerator capacity.

   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.

   o  Number of connectivity matrix/number of pairs/link per pairs.  The
      number of sub-matrix increase depending on the port blocking
      ratio, the number of pair in one connectivity matrix depends on
      the wavelength restrictions.  Those two criteria do not depend on
      which information model is considered.  The number of link per set
      is increased by the number of resource pool in this draft.

   Those numbers for each node are shown in the following table
(corrected the number of pools)

                Details of information elements per node

        Node Type    Resource Pools Resource Blocks Matrix/Pair/Links
       S, Flexible          6            5 (30)       1/1/10 (1/1/1)
      S, Fixed(port)       12            5 (60)       4/4/4 (4/4/1)
     S, Fixed(label)        6            5 (30)       4/1/10 (4/1/1)
       M, Flexible          3           10 (30)       1/1/11 (1/1/1)
       L, Flexible          5           10 (50)       1/1/21 (1/1/1)

       Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
                                 brackets

 As the preceding table may be uneasy to read, here is an alternative one:

                 Details of information elements per node

                        #Device            #ResProp
   Node Type    #Pools   Type    #Blocks     TLV     Matrix/Pair/Links
  S, Flexible      6       5       30       5 (25)     1/1/10 (1/1/1)
 S, Fixed(port)   12       5       60       5 (45)     4/4/4  (4/4/1)
S, Fixed(label)    6       5       30       5 (25)     4/1/10 (4/1/1)
  M, Flexible      3      10       30      10 (30)     1/1/11 (1/1/1)
  L, Flexible      5      10       50      10 (40)     1/1/21 (1/1/1)

       Nota: Values for [I-D.ietf-ccamp-rwa-wson-encode] are between
                                 brackets

Regards,

Pierre

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Greg Bernstein
Envoyé : vendredi 17 juin 2011 19:53
À : [e-mail]
Objet : Re: [CCAMP] TR: New Version Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt

This issue can be readily resolved if the  diagrams and current WG draft sub-TLV encoding use in sections 5.2 and 5.3 of peloso-3 is given.
There are four authors of this document, hence somebody must have a diagram of the switch and sub-TLV encodings that generated the numbers used in the evaluation. If you can furnish that then I will show either
(a) That the system of interest can be efficiently encoded with the current WG drafts and current GMPLS/OSPF mechanisms.
or
(b) That a minimalistic extension to the WSON encoding draft along with current GMPLS/OSPF extensions can be used to efficiently encode this system.

Note that the purpose of this exercise is to solve a potential problem with the WSON WG drafts and if enough folks are concerned about a potential problem we can figure out how to solve it.  The purpose is not a general re-write of these drafts. Note that during the development of the WSON WG drafts we shared all our test cases freely via my website, informal presentations at previous IETF meetings, and in papers published in journals. I don't seen any reason for the authors of
peloso-3 to keep their test cases secret when asking for changes to CCAMP WG drafts to accommodate it.

Greg

On 6/17/2011 9:20 AM, Julien Meuric wrote:
> Hi Young.
>
> You are right on one thing: operators try to minimize costs. This is
> exactly why ROADMs are first deployed with 10 Gb/s wavelengths, 40
> Gb/s when transponders become cost-efficient enough, and then 100
> Gb/s, which will likely become cost-efficient later... Obviously,
> minimizing cost mean deploying over existing things, not replacing;
> therefore we end up with many types of regenerators, due to the
> various bit-rates and modulation format existing out there.
>
> I personally believe that a few-year-old long haul network will end up
> beyond Cyril's "reasonable figures" quite easily.
>
> Regards,
>
> Julien
>
>
> Le 17/06/2011 17:55, Leeyoung a écrit :
>>
>>  Cyril,
>>
>>
>>
>>  I think your example is a corner case, which is not typical case. We
>> should not base this kind of highly theoretical corner case as the
>> base case for your analysis. We are dealing with WSON switching
>> enabled ROADM networks, not necessarily dealing with legacy DWDM
>> system. Please also note that the typical WSON switching nodes are
>> transparent nodes. Only some of the nodes may have Regen elements
>> ---as I mentioned in the previous email, the operators try to
>> minimize the use of Regen's due to its high cost.
>>
>>
>>
>>  Please see my other comment in-line.
>>
>>
>>
>>  Thanks.
>>
>>  Young
>>
>>
>>
>>
>>
>>  -------------------------
>>
>>  *From:*Margaria, Cyril (NSN - DE/Munich)
>> [mailto:[e-mail]] **
>>
>>
>>
>>  Hi Young Lee, Ccamper's,
>>
>>
>>
>>  Reducing the type of regenerator makes sense but mixing regenerator
>> type makes also sense, as you would try to avoid having only
>> 40G-capable 3R when you can go for a cheaper 10G regenerator,
>> depending on your demands.
>>
>>
>>
>>  In Greenfield deployments single rate makes sense, in an existing
>> networks having multi-rate (2) support with different electrical
>> module may be less common but should still be supported.
>>
>>  This kind of network would need 6 description for the processing
>> capability alone. The total number of resource description need to
>> be higher, as in the info model the description of a regenerator
>> include the number of resource. Each time the connectivity imply a
>> different number of regenerator are grouped together a separate
>> ResourceBlockInfo should be used (Separating connectivity and
>> regenerator setup would help here).
>>
>>
>>
>>  *YOUNG>> Your point on "separating connectivity and regenerator
>> setup  would help here" is exactly the encoding principles of the
>> current WG  adopted encoding drafts. Then I don't clearly understand
>> what the  Pierre's draft are trying to do. *
>>
>>
>>
>>  Best case would see indeed 0-2 type of regenerator, intermediate
>> actual deployments can see 6 types of regenerator, we also considered
>> looking at possible evolutions, 10 being in our opinion a reasonable
>> number.
>>
>>
>>
>>  I hope it could help you understand better what is considered in the
>> draft. Those consideration will be more detailed in the next revision
>> of the draft.
>>
>>
>>
>>  Best Regards
>>
>>
>>
>>
>>
>>
>>
>>  *From:*ext Leeyoung [mailto:[e-mail]] **
>>
>>
>>
>>  Hi Cyril,
>>
>>
>>
>>  I think your analysis below is very theoretical and a bit out of
>> reality in WSON node configuration.
>>
>>
>>
>>  We are dealing with wavelength level so that OTUk level is
>> transparent to WSON. In typical optical switch node configuration in
>> WSON, we don't simply mix up all possible kinds of regenerators per
>> each modulation type. It is true that we have many modulation types
>> for each rate and the model should support all possibility. But this
>> does not mean we have all "10 types" at the same time in a node
>> design. As you know, regenerator is one of the most expensive WSON
>> elements and having many types in a node is not economical and not
>> realistic.
>>
>>
>>
>>  As far as my understanding of node design, we don't have such thing
>> as you said in your email to support 10+ different types of
>> regenerators in a node. In a typical commercially deployed WSON
>> switching node, we have one rate (e.g., 10G or 40G, or possibly
>>  others) and one regenerator type for each rate. If we have
>> multi-rate  support, we may have two rates and thus two regenerators
>> in a typical  WSON switching node.
>>
>>
>>
>>  I would be interested in the node design diagram that supports 10+
>> different regenerators at the same time. I haven't seen such one
>> myself yet.
>>
>>
>>
>>  Please also note that the WSON model has to support transparent node
>> configuration, which we don't have "regen" element.
>>
>>
>>
>>  Best Regards,
>>
>>  Young
>>
>>
>>
>>
>>
>>
>>
>>  -------------------------
>>
>>  *From:*[e-mail] [mailto:[e-mail]] *On
>> Behalf Of *Margaria, Cyril (NSN - DE/Munich) **
>>
>>  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]] *On
>> Behalf Of *ext Greg Bernstein **
>>
>>
>>
>>  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.
>>
>>  On 6/10/2011 7:19 AM, PELOSO, PIERRE (PIERRE) wrote:
>>
>>  Hi Ccampers,
>>
>>  During Prague meeting I was asked to provide a draft detailing the
>> solution we were presenting then concerning OSPF-TE extensions for
>> Wavelength Switched Optical Networks (see point 10 of ccamp
>> minutes). Julien, Giovanni, Cyril and I have tackled this work of
>> providing a complete description of the solution with commonalities
>> and deltas from the existing solution held in the following drafts: -
>>  draft-ietf-ccamp-rwa-info-11 -
>>  draft-ietf-ccamp-general-constraint-encode-04 -
>> draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00 -
>>  draft-ietf-ccamp-rwa-wson-encode-11 -
>>  draft-ietf-ccamp-wson-signal-compatibility-ospf-04
>>
>>  Feedback from the working group is welcome.
>>
>>  To trigger this feedback, this draft holds inside section 5 a
>> numerical study on the amount of static and dynamic information to be
>> flooded. This study was conducted on various typical WSON nodes and
>> compares the size of the LSAs between the two solutions.
>>
>>  Regards,
>>
>>  - Pierre
>>
>>
>>  _______________________________________________ CCAMP mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>  -- =================================================== Dr Greg
>> Bernstein, Grotto Networking [phone]
>>
>>
>>
>>  _______________________________________________ CCAMP mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>


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


_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp