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

[Greg Bernstein <[e-mail]>]

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]