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

["Margaria, Cyril (NSN - DE/Munich)" <[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).

 

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]] 
Sent: Thursday, June 16, 2011 10:47 PM
To: Margaria, Cyril (NSN - DE/Munich); ext Greg Bernstein;
[e-mail]
Subject: RE: [CCAMP] TR: New Version
Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt

 

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)
Sent: Wednesday, June 15, 2011 2:36 AM
To: ext Greg Bernstein; [e-mail]
Subject: Re: [CCAMP] TR: New Version Notification
fordraft-peloso-ccamp-wson-ospf-oeo-03.txt

 

 


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
Sent: Monday, June 13, 2011 8:20 PM
To: [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.

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]
https://www.ietf.org/mailman/listinfo/ccamp

 

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