Subject: [CCAMP] TR: New Version Notification for draft-peloso-ccamp-wson-ospf-oeo-03.txt

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 10 Jun 2011 16:19:46 +0200

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

Subject: New Version Notification for draft-peloso-ccamp-wson-ospf-oeo-03.txt
From: "[email-masked]" <[email-masked]>
To: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "PELOSO, PIERRE (PIERRE)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 10 Jun 2011 15:30:08 +0200

A new version of I-D, draft-peloso-ccamp-wson-ospf-oeo-03.txt has been successfully submitted by Pierre Peloso and posted to the IETF repository.

Filename:	 draft-peloso-ccamp-wson-ospf-oeo
Revision:	 03
Title:		 OSPF-TE Extensions for WSON-specific Network Element Constraints
Creation date:	 2011-06-10
WG ID:		 Individual Submission
Number of pages: 41

Abstract:
   The original content of this internet draft was to propose some
   extentions to OSPF encoding in the context of Wavelength Switched
   Optical Networks, especially for internal constraints of optical
   network elements.  General description can be found in the framework
   document.

   This update of the document still aims at specifying the detailled
   structure of OSPF LSAs for WSONs.  Nevertheless, the proposed LSA
   layout slightly differs from the current content of the information
   model and encodings drafts.  As a result, the following sections
   hilglight the differences between both approaches and summarize why
   the authors think these CCAMP&#39;s drafts would benefit from an update
   according to the proposed description.

The IETF Secretariat

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 13 Jun 2011 11:19:50 -0700

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:
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 14 Jun 2011 08:21:30 -0700

Hi CCAMPers interested in WSON, the recently published 
"draft-peloso-ccamp-wson-ospf-oeo-03.txt" is extremely long (41 pages) 
so I'm not sure who will be reading it in its entirety other than 
myself. Below I'll try to summarize the document from my perspective and 
to aid the work group in trying to figure out where to go next.

An important thing to note is that there are many essentially equivalent 
ways of formulating the WSON information model, its encoding, and its 
packing into OSPF LSAs. The current CCAMP WG drafts 
[draft-ietf-ccamp-rwa-info-11 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-info/>, 
draft-ietf-ccamp-general-constraint-encode-05 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode/>, 
draft-ietf-ccamp-rwa-wson-encode-11 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode/>, 
draft-ietf-ccamp-wson-signal-compatibility-ospf-04 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/>, 
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00 
<http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-general-constraints-ospf-te/> 
] present one formulation. At the Prague IETF Pierre indicated that 
additional encoding efficiencies might be possible. The straight forward 
way to illustrate this would be to show an example optical node, show 
the most efficient encoding using the current WG drafts, then show via a 
minimal set of changes to the current WG drafts how much space savings 
could be realized. Unfortunately the document 
"draft-peloso-ccamp-wson-ospf-oeo-03.txt" does not do this.

(1) "draft-peloso-ccamp-wson-ospf-oeo-03.txt" starts with over 31 pages 
of text predominantly taken from the five current CCAMP working group 
drafts mentioned above. Most of these are very small conceptual changes, 
i.e., moving some information from some containers (TLVs, sub-TLVs, 
etc...) to others and hence not resulting any significant encoding space 
savings.
(2) In the first 31 pages there is one new indirection mechanism added 
for identifiers for resource pools which could be helpful in what seems 
an unusual optical node.
(3) Section 5 is a "Solution(s) Evaluation". It begins with a "RBNFs 
Comparison", then proceeds with "5.2 Depiction of the considered cases 
for evaluation". This is a key section but does not include any diagrams 
of the optical nodes so readers can determine whether these are 
important examples of practical optical nodes or example constructions 
that would tend to not be used in practice.
(4)  Section 5.3 "Comparing evaluation of the solutions" should be the 
longest section of the document but instead is only a page long. It 
cites numbers for the "cases for evaluation", but provides no basis for 
the numbers or an analysis of why for these cases the encoding presented 
is better than that in the current WG drafts.

*My recommendations based on this draft:*
Hidden deep in the text of section "5.2 Depiction of the considered 
cases for evaluation"  we see the text
  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.

**Here is where the encoding differences seem to take place. For the 
constructed examples (that are not explicitly given) it seems that 
they've randomly assigned (or worse than random) different regenerator 
types to blocks to obtain none of the coding advantages of the current 
WG draft scheme.

Hence the only encoding problem that is pointed out in this draft can be 
solved with their proposed indirection mechanism (resource pool/block 
ID) but none of the other changes proposed in this document to Info 
model, encoding, or OSPF drafts are necessary. If the authors can 
rewrite this draft in reverse order (problem, analysis, solution) where 
the solution involves minimal changes to the existing CCAMP WSON related 
WG drafts then the WG should have a sound basis to make a decision and 
it should be easy for the editors of the existing CCAMP WSON drafts to 
incorporate any changes if desired by the WG.

Cheers
Greg B.

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 15 Jun 2011 09:35:38 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Greg Bernstein
Sent: Monday, June 13, 2011 8:20 PM
To: [email-masked]
Subject: Re: [CCAMP] TR: New Version Notification
fordraft-peloso-ccamp-wson-ospf-oeo-03.txt

Cheers

Greg B.

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

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

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 15 Jun 2011 09:25:08 -0700

Hi Cyril, yes there are a lot of optical modulation types out there.  So 
this sounds plausible.  However the essence of the solution to the issue 
of a large number of regenerator types in 
draft-peloso-ccamp-wson-ospf-oeo-03.txt seems to only require a slight 
change to the WSON specific encoding draft and not changes to all five 
current working group documents.  Hence, if the authors can rewrite the 
encoding solution in a form that makes minimal changes to the existing 
WSON specific encoding drafts and no unnecessary changes to other drafts 
then I would be happy to incorporate the resulting encoding enhancement.

Cheers

Greg B.

On 6/15/2011 12:35 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
>
> 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.
>
> 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:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext Greg Bernstein
> *Sent:* Monday, June 13, 2011 8:20 PM
> *To:* [email-masked]
> *Subject:* Re: [CCAMP] TR: New Version Notification 
> 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.
> [email-masked]  <mailto:[email-masked]>

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 16 Jun 2011 11:02:27 -0700

Hi Cyril, can you furnish diagrams of the optical nodes, and the 
encodings chosen when using the current WG documents. From the Peloso 
draft there is insufficient information to see where the encoding 
numbers quoted came from.  The current 
draft-ietf-ccamp-rwa-wson-encode-11.txt makes it relatively efficient to 
deal with lots of different regenerator types. In section 4.1 "Resource 
Block Information Sub-TLV" is defined as:

0123
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RB Set Field |
::
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|E| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input Modulation Type List Sub-Sub-TLV(opt)|
::
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input FEC Type List Sub-Sub-TLV(opt)|
::
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Input Client Signal Type Sub-Sub-TLV(opt)|
::
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        More resource description |
::

The RB set field in this sub-TLV allows you to specify once all the 
properties of a class of regenerators and apply it to a set of resource 
blocks. Hence this scales as the number of regenerator types not as the 
number of resource blocks.  Hence the existing WSON encoding should 
solve your problem of many types of regenerators within an optical node.

Without further information I can't see how the Peloso draft gets the 
numbers it quotes for the size of the information to be distributed. In 
addition it doesn't appear that the Peloso draft uses the OSPF group's 
recommended practice of multiple LSA instances. But once again 
insufficient information is given to justify the numbers. If there is a 
problem with encoding for a particular switch case I'm sure we can 
quickly find a solution that has a minimal impact on the existing WSON 
related WG drafts, but first we really need to understand the optical 
node and the cause (if any) the the encoding expansion.

Greg B.

> other WSON interested parties that have a need for so many regenerator 
--snip --

---

From: Leeyoung <[email-masked]>
Date: Thu, 16 Jun 2011 20:46:40 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (NSN - DE/Munich)
Sent: Wednesday, June 15, 2011 2:36 AM
To: ext Greg Bernstein; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Greg Bernstein
Sent: Monday, June 13, 2011 8:20 PM
To: [email-masked]
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.

Hi Ccampers,

Regards,

- Pierre

CCAMP mailing list

[email-masked]<mailto:[email-masked]>

--

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Thu, 16 Jun 2011 23:43:01 +0200

Hi Greg, Ccamper's

First of all thanks for your comments, we'll make sure to integrate them properly in the revision to come of draft-peloso-.

We understand the impression given by the length of the draft, this comes actually from two facts: first the request by the WG and its chairs indications to gather in a single document the changes from info down to OSPF-TE and second that the 5 drafts with which we are drawing a parallel are lengthy themselves once concatenated, which we cannot avoid ourselves.

To ease anyone's reading, we'll see how to arrange things in the next revision, though ccamper's shall not expect a big reduction of pages as the deltas between the solutions proposed are more important than you summarized to the WG. This changes permitted to reach the gain in LSA size that we obtained especially concering the updates (read section 5). From a high-level view, most of the modifications target the WSON part, it has significant impact on the info model, the encodings and the LSA layout (hence OSPF-TE).

We've noticed you were concerned by the way we conducted the size study. First, we have determined and described a given set of nodes we wanted to work on in a futur proof though reasonnable perspective. Second, we have used the drafts contents nammely recommendations of the info models and the encodings in order to derive the encodings then summed them to determine the size of each LSA, for each of the solutions.We thought anyone familiar with the drafts to proceed similarly, hence would have the capability to doublecheck. Reading your past emails, I have not noticed yet any doubt express there relative to our misusing the previous draft that reveals itself accurate, then I keep trusting the accuracy of section 5.

To help the discussion move forward, we'll detail more the node models we've taken. In the meanwhile, feel free to explicit the one you want to consider, if you wish to do a study.

Finally, you mention the optional feature of OSPF-TE named multi-LSA instance, that you seem to advocate as the solution to limit update sizes, and I am sorry to point that we have indeed provided such results inside section 5 of draft-peloso- not at the advantage of multi-instance. Though, the lack inside currrent drafts on how to proceed, forced us to best-guess. We would be glad (as I bet the WG would) to be told in which instance shall be which TLVs.

Pierre
________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Greg Bernstein
Envoyé : jeudi 16 juin 2011 20:02
À : Margaria, Cyril (NSN - DE/Munich)
Cc : [email-masked]
Objet : Re: [CCAMP] TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt

Hi Cyril, can you furnish diagrams of the optical nodes, and the encodings chosen when using the current WG documents. From the Peloso draft there is insufficient information to see where the encoding numbers quoted came from.  The current draft-ietf-ccamp-rwa-wson-encode-11.txt makes it relatively efficient to deal with lots of different regenerator types. In section 4.1 "Resource Block Information Sub-TLV" is defined as:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    RB Set Field                               |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|E|                        Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Input Modulation Type List Sub-Sub-TLV  (opt)       |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Input FEC Type List Sub-Sub-TLV    (opt)            |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Input Client Signal Type Sub-Sub-TLV      (opt)       |
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        More resource description                              |
   :                                                               :

The RB set field in this sub-TLV allows you to specify once all the properties of a class of regenerators and apply it to a set of resource blocks. Hence this scales as the number of regenerator types not as the number of resource blocks.  Hence the existing WSON encoding should solve your problem of many types of regenerators within an optical node.

Without further information I can't see how the Peloso draft gets the numbers it quotes for the size of the information to be distributed. In addition it doesn't appear that the Peloso draft uses the OSPF group's recommended practice of multiple LSA instances. But once again insufficient information is given to justify the numbers. If there is a problem with encoding for a particular switch case I'm sure we can quickly find a solution that has a minimal impact on the existing WSON related WG drafts, but first we really need to understand the optical node and the cause (if any) the the encoding expansion.

Greg B.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Greg Bernstein
To: [email-masked]<mailto:[email-masked]>

Cheers

Greg B.
--snip --

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 17 Jun 2011 10:26:07 +0200

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:[email-masked]] 
Sent: Thursday, June 16, 2011 10:47 PM
To: Margaria, Cyril (NSN - DE/Munich); ext Greg Bernstein;
[email-masked]
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

Of Margaria, Cyril (NSN - DE/Munich)

Hi Greg, CCAMPers, 

Best regards.

Cheers

Greg B.

Hi Ccampers,

 
 
Regards,
 
- Pierre

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 17 Jun 2011 16:45:37 +0800

Hi Pierre,

We know that it follows the logic (WSON Framework->WSON Info model->WSON Encoding->OSPF/RSVP-TE extensions) for WSON work.

Let’s focus on WSON Info model first. We know that [Info Model] only describe what information should be considered for CP in WSON network.

You said “it has significant impact on the info model, the encodings and the LSA layout (hence OSPF-TE)” .

Could you tell the WG what is the significant impact on info model first? What information is missed or what information is redundant in [ietf-ccamp-rwa-info]?

 

Thanks
 
Fatai

From: [email-masked] [mailto:[email-masked]] On Behalf Of PELOSO, PIERRE (PIERRE)
Sent: 2011年6月17日 5:43
To: Greg Bernstein
Cc: [email-masked]
Subject: Re: [CCAMP] TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt

Hi Greg, Ccamper's

To ease anyone's reading, we'll see how to arrange things in the next revision, though ccamper's shall not expect a big reduction of pages as the deltas between the solutions proposed are more important than you summarized to the WG. This changes permitted to reach the gain in LSA size that we obtained especially concering the updates (read section 5). >From a high-level view, most of the modifications target the WSON part, it has significant impact on the info model, the encodings and the LSA layout (hence OSPF-TE).

Pierre

  _____  

    0                   1                   2                   3 

Greg B.

Hi Greg, CCAMPers, 

Best regards.

Cheers

Greg B.

--snip --

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Fri, 17 Jun 2011 11:06:23 +0200

Hi Fatai,

When having an info model, there are two things, the first as you mention consists in describing which information are to be considered for a CP, the second consists in descibing how this information is modelized (meaning how it is organized otherwise that is not a model) and that is what was already done - e.g. draft-ietf-ccamp-rwa-info relies on RBNFs to describe the model.

Here, the main impact is on the second point, the way the information is organized, more than on which information is to be described.

Hence, in order to address your concern of a summary of differences between the info model, I would suggest interested parties to read the section 5.1 of draft-peloso-ccamp-wson-ospf-oeo-03.
http://tools.ietf.org/html/draft-peloso-ccamp-wson-ospf-oeo-03#section-5.1

Regards,

Pierre

________________________________
De : Fatai Zhang [mailto:[email-masked]]
Envoyé : vendredi 17 juin 2011 10:46
À : PELOSO, PIERRE (PIERRE); 'Greg Bernstein'
Cc : [email-masked]
Objet : RE: [CCAMP] TR: New Version Notification fordraft-peloso-ccamp-wson-ospf-oeo-03.txt

Hi Pierre,

Thanks

Fatai

Hi Greg, Ccamper's

Pierre

    0                   1                   2                   3

Greg B.

Cheers

Greg B.
--snip --

--

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 17 Jun 2011 08:19:17 -0700

From the Prague meeting notes, the purpose of this work was to look 
into a possible inefficiency in the encoding used in the WSON drafts. 
Not an arbitrary rewrite of the WSON Info, WSON encoding, General 
Constraints Encoding, WSON specifc OSPF extensions, and General 
Constraint extensions for OSPF.  Any change needs to be justified with 
clear evidence showing that
(1) There is a problem -- including
     (a) The problem is realistic
     (b) The problem cannot be address by mechanisms within the current 
WG drafts and standard practices such as OSPF instances for separating 
dynamic and static information.
(2) An analysis that shows precisely where in the current scheme 
facilities are lacking
(3) A proposed solution that makes minimal changes to the existing 
documents.

The Peloso draft-03 fails on all these accounts by starting with a long 
list of proposed changes that do not appear tied to solving a particular 
encoding problem. The "example node" is insufficiently documented to 
ascertain either 1(a) or 1(b) above.  Item 2 is inadequately addressed, 
example sub-TLVs are not given, etc... If there is an problem encoding a 
particular type of optical system we can fix it as soon as we know what 
it is.  However, general changes to the current WG drafts are out of 
scope of this particular effort.

Greg

On 6/17/2011 2:06 AM, PELOSO, PIERRE (PIERRE) wrote:
> Hi Fatai,
> When having an info model, there are two things, the first as you 
> mention consists in describing which information are to be considered 
> for a CP, the second consists in descibing how this information is 
> modelized (meaning how it is organized otherwise that is not a model) 
> and that is what was already done - e.g. draft-ietf-ccamp-rwa-info 
> relies on RBNFs to describe the model.
> Here, the main impact is on the second point, the way the information 
> is organized, more than on which information is to be described.
> Hence, in order to address your concern of a summary of differences 
> between the info model, I would suggest interested parties to read the 
> section 5.1 of draft-peloso-ccamp-wson-ospf-oeo-03.
>     ------------------------------------------------------------------------
>     *De :* Fatai Zhang [mailto:[email-masked]]
>     *Envoyé :* vendredi 17 juin 2011 10:46
>     *À :* PELOSO, PIERRE (PIERRE); 'Greg Bernstein'
>     *Cc :* [email-masked]
>     *Objet :* RE: [CCAMP] TR: New Version Notification
>     We know that it follows the logic (WSON Framework->WSON Info
>     model->WSON Encoding->OSPF/RSVP-TE extensions) for WSON work.
>
>     Let’s focus on WSON Info model first. We know that [Info Model]
>     only describe what information should be considered for CP in WSON
>     network.
>
>     You said “it has significant impact on the info model, the
>     encodings and the LSA layout (hence OSPF-TE)”.
>
>     Could you tell the WG what is the significant impact on info model
>     first? What information is missed or what information is redundant
>     in [ietf-ccamp-rwa-info]?
>
>     Thanks
>
>     Fatai
>
>     Behalf Of *PELOSO, PIERRE (PIERRE)
>     *Sent:* 2011年6月17日5:43
>     *To:* Greg Bernstein
>     *Cc:* [email-masked]
>     First of all thanks for your comments, we'll make sure to
>     integrate them properly in the revision to come of draft-peloso-.
>
>     We understand the impression given by the length of the draft,
>     this comes actually from two facts: first the request by the WG
>     and its chairs indications to gather in a single document the
>     changes from info down to OSPF-TE and second that the 5
>     drafts with which we are drawing a parallel are lengthy themselves
>     once concatenated, which we cannot avoid ourselves.
>
>     To ease anyone's reading, we'll see how to arrange things in the
>     next revision, though ccamper's shall not expect a big reduction
>     of pages as the deltas between the solutions proposed are more
>     important than you summarized to the WG. This changes
>     permitted to reach the gain in LSA size that we obtained
>     especially concering the updates (read section 5). From a
>     high-level view, most of the modifications target the WSON part,
>     it has significant impact on the info model, the encodings and the
>     LSA layout (hence OSPF-TE).
>
>     We've noticed you were concerned by the way we conducted the size
>     study. First, we have determined and described a given set of
>     nodes we wanted to work on in a futur proof though reasonnable
>     perspective. Second, we have used the drafts contents nammely
>     recommendations of the info models and the encodings in order to
>     derive the encodings then summed them to determine the size of
>     each LSA, for each of the solutions.We thought anyone familiar
>     with the drafts to proceed similarly, hence would have the
>     capability to doublecheck. Reading your past emails, I have not
>     noticed yet any doubt express there relative to our misusing the
>     previous draft that reveals itself accurate, then I keep trusting
>     the accuracy of section 5.
>
>     To help the discussion move forward, we'll detail more the node
>     models we've taken. In the meanwhile, feel free to explicit the
>     one you want to consider, if you wish to do a study.
>
>     Finally, you mention the optional feature of OSPF-TE named
>     multi-LSA instance, that you seem to advocate as the solution to
>     limit update sizes, and I am sorry to point that we have
>     indeed provided such results inside section 5 of draft-peloso- not
>     at the advantage of multi-instance. Though, the lack inside
>     currrent drafts on how to proceed, forced us to best-guess. We
>     would be glad (as I bet the WG would) to be told in which instance
>     shall be which TLVs.
>
>     Pierre
>
>     ------------------------------------------------------------------------
>
>     *De :[email-masked] [mailto:[email-masked]] *De
>     la part de* Greg Bernstein
>     *Envoyé :* jeudi 16 juin 2011 20:02
>     *À :* Margaria, Cyril (NSN - DE/Munich)
>     *Cc :* [email-masked]
>     *Objet :* Re: [CCAMP] TR: New Version Notification
>         Hi Cyril, can you furnish diagrams of the optical nodes, and
>         the encodings chosen when using the current WG documents. From
>         the Peloso draft there is insufficient information to see
>         where the encoding numbers quoted came from.  The current
>         draft-ietf-ccamp-rwa-wson-encode-11.txt makes it relatively
>         efficient to deal with lots of different regenerator types. In
>         section 4.1 "Resource Block Information Sub-TLV" is defined as:
>
>             0                   1                   2                   3
>            |                    RB Set Field
>                                       |
>            :                                                          
>             :
>            |I|E|                        Reserved     
>                              |
>            :                                                          
>             :
>            :               
>                                                        :
>         The RB set field in this sub-TLV allows you to specify once
>         all the properties of a class of regenerators and apply it to
>         a set of resource blocks. Hence this scales as the number of
>         regenerator types not as the number of resource blocks.  Hence
>         the existing WSON encoding should solve your problem of many
>         types of regenerators within an optical node.
>
>         Without further information I can't see how the Peloso draft
>         gets the numbers it quotes for the size of the information to
>         be distributed. In addition it doesn't appear that the Peloso
>         draft uses the OSPF group's recommended practice of multiple
>         LSA instances. But once again insufficient information is
>         given to justify the numbers. If there is a problem with
>         encoding for a particular switch case I'm sure we can quickly
>         find a solution that has a minimal impact on the existing WSON
>         related WG drafts, but first we really need to understand the
>         optical node and the cause (if any) the the encoding expansion.
>
>         Greg B.
>
>
>         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
>         *From:[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]] *On Behalf Of *ext Greg Bernstein
>         *To:* [email-masked] <mailto:[email-masked]>
>         (1) Diagrams of the example switches particularly with respect
>         to the structure of the resource pools/blocks.
>         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.
>
>         --snip --
>
>         -- 
>

---

From: Leeyoung <[email-masked]>
Date: Fri, 17 Jun 2011 15:55:14 +0000

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:[email-masked]]
Sent: Friday, June 17, 2011 3:26 AM
To: Leeyoung; ext Greg Bernstein; [email-masked]
Subject: RE: [CCAMP] TR: New Version Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt

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

Hi Cyril,

Best Regards,
Young

Hi Greg, CCAMPers,

Best regards.

Cheers

Greg B.

Hi Ccampers,

Regards,

- Pierre

CCAMP mailing list

--

---

From: Julien Meuric <[email-masked]>
Date: Fri, 17 Jun 2011 18:20:39 +0200

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.
>
>
>
>  -------------------------
>
>  *From:*Margaria, Cyril (NSN - DE/Munich)
>  [mailto:[email-masked]] **
>
>
>
>  Hi Young Lee, Ccamper’s,
>
>
>
>  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.
>
>
>
>  networks having multi-rate (2) support with different electrical
>  module may be less common but should still be supported.
>
>  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.
>
>
>
>  *From:*ext Leeyoung [mailto:[email-masked]] **
>
>
>
>  Hi Cyril,
>
>
>
>  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.
>
>
>
>  different regenerators at the same time. I haven’t seen such one
>  myself yet.
>
>
>
>  configuration, which we don’t have “regen” element.
>
>
>
>  Best Regards,
>
>  Young
>
>
>
>
>
>
>
>  -------------------------
>
>  Behalf Of *Margaria, Cyril (NSN - DE/Munich) **
>
>  Hi Greg, CCAMPers,
>
>
>
>  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.
>
>
>
>  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.
>
>
>
>  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.
>
>  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 -
>  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
>  -- =================================================== Dr Greg
>  Bernstein, Grotto Networking (510) 573-2237
>
>
>
>  _______________________________________________ CCAMP mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/ccamp

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 17 Jun 2011 10:52:59 -0700

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:
> 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.
>

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Wed, 22 Jun 2011 15:26:14 +0200

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 : [email-masked] [mailto:[email-masked]] De la part de Greg Bernstein
Envoyé : vendredi 17 juin 2011 19:53
À : [email-masked]
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:
>> minimize the use of Regen's due to its high cost.
>>
>>
>>
>>  *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. *
>>
>>
>>
>> WSON, we don't simply mix up all possible kinds of regenerators per
>> does not mean we have all "10 types" at the same time in a node
>>  As far as my understanding of node design, we don't have such thing
>>  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.
>>
>>
>>
>> different regenerators at the same time. I haven't seen such one
>> myself yet.
>>
>>
>>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 27 Jun 2011 08:54:32 -0700

Hi Pierre and co-authors, see below.
GB
>    - 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 spec…
The WSON information model and encoding drafts are concerned with the 
switching behavior of a node and accessibility to node resources. In the 
WSON framework, and encoding documents we show diagrams that convey the 
essence of different architectures on these properties. These diagrams 
are fairly far removed from an actual schematic diagram but show how the 
nodes internal structure influences both switching behavior and resource 
accessibility.

A key aspect of WSON work is to model the internal structure of the 
nodes in a suitably summarized fashion. Hence, the importance of 
furnishing a diagram of the nodes that you use in your examples.  You do 
not need to draw all the details, but rather something on the level of 
Figures 4 and 5 of the WSON Framework (RFC6163).
Please furnish a diagram of your lowest node degree case if you still 
think that there is a problem with the current working group drafts.
>    - 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 determin…
In the WSON encoding draft (draft-ietf-ccamp-rwa-encoding-11.txt) 
Appendix A, and in the General Constraint encoding draft 
(draft-ietf-ccamp-general-constraint-encode-05.txt) Appendix A we 
furnish high level block diagrams representing the internal structure of 
nodes that influence both switching capability and resource 
accessibility, then give examples of efficient use of the encodings and 
show them explicitly.

It is not true that there "there is no much degree of freedom  in the 
way of encoding a given structure" in GMPLS standards. Many times there 
are multiple ways to achieve the same thing, with some much less 
efficient than others. For example GMPLS signaling there are multiple 
ways to encode a Label Set, which can result in huge variations in the 
amount of space consumed. Without seeing the encodings that go with the 
node architecture (also not furnished) it is impossible to say whether 
the methods defined in the current working group drafts have been used 
as intended.

Please furnish the encodings that you used for your examples if you 
still think there is an issue with the current WG drafts. There is no 
way for us to figure out how you arrived at your numbers or figure out 
whether there is an actual problem to be solved. A level of detail on 
the order of that given in the appendices of the current working group 
drafts is sufficient.

---

From: Leeyoung <[email-masked]>
Date: Mon, 27 Jun 2011 20:32:24 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of PELOSO, PIERRE (PIERRE)
Sent: Wednesday, June 22, 2011 8:26 AM
To: Greg Bernstein; [email-masked]
Subject: Re: [CCAMP] TR: New Version Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt

Hi Greg,

                          Node Types and designs

                        #Device            #ResProp

Regards,

Pierre

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

Greg

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Jun 2011 10:57:19 -0400

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
>
Of PELOSO, PIERRE (PIERRE)
> Subject: Re: [CCAMP] TR: New Version
>   - 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 ?
> Objet : Re: [CCAMP] TR: New Version
>
> 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.
> 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.