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

[Julien Meuric <[e-mail]>]

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