[CCAMP] Moving the WSON discussion forward (Was Re: TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt)

[Lou Berger <[e-mail]>]

Young,
	I think we have a substantive document that satisfies my request for "a
document that can serve as the foundation for discussion" on their proposal.

All,
	Perhaps it would be worthwhile to focus the discussion on the specific
proposed changes and understanding the motivation for each.  I propose
that we first focus on the Information model changes.


Authors of draft-peloso-ccamp-wson-ospf-oeo,

	Can you please list any major change made in Section 2 and
explain/justify each proposed change? For example, discuss/justify your
proposal to have multiple resource pools vs the single pool model in
ccamp-rwa-info. (Note the BNF for multiple pools is missing, but is
implied by Figure 1.)

Once we have closure on major changes, we can move on to the more minor
changes in the section as well as changes in encoding (your section 3.)

My hope is to resolve the open issues on the list prior to Quebec, but
suspect we'll need the WG session to help close the issues.

Lou

On 6/27/2011 4:32 PM, Leeyoung wrote:
> Hi Pierre,
> 
> Please recall the WG chair's request to you in the last IETF meeting
> that the information you are to provide has to be comprehensive and
> complete so that others can understand the points you are making.
> 
> Having reviewed your document, I think you need to provide the
> diagram of the node configuration you used as the basis of your
> analysis in the similar fashion to the current encoding draft.
> 
> You mentioned that "For the small nodes, 5 different type of
> regenerators are considered, for the Middle and Large ones 10
> different type of regenerators are considered." -- Please provide
> your node diagrams for these cases so that we can provide our
> analysis. Until you provide the exact node configuration with these
> many OEO elements, it is not possible for us to proceed with the
> meaning comparisons.
> 
> Regards, Young
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of PELOSO, PIERRE (PIERRE)
> Sent: Wednesday, June 22, 2011 8:26 AM
> To: Greg Bernstein; [e-mail]
> Subject: Re: [CCAMP] TR: New Version
Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt
>
> 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
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>