Re: [CCAMP] TR: New Version Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt
Leeyoung <leeyoung@huawei.com> Fri, 17 June 2011 15:55 UTC
Return-Path: <leeyoung@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2431411E8084 for <ccamp@ietfa.amsl.com>; Fri, 17 Jun 2011 08:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuvZOSll4M5S for <ccamp@ietfa.amsl.com>; Fri, 17 Jun 2011 08:55:24 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9E83711E81CF for <ccamp@ietf.org>; Fri, 17 Jun 2011 08:55:18 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMX002X5YW53C@usaga04-in.huawei.com> for ccamp@ietf.org; Fri, 17 Jun 2011 10:55:18 -0500 (CDT)
Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMX00MGKYW3FF@usaga04-in.huawei.com> for ccamp@ietf.org; Fri, 17 Jun 2011 10:55:17 -0500 (CDT)
Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 17 Jun 2011 08:55:17 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 17 Jun 2011 08:55:14 -0700
Date: Fri, 17 Jun 2011 15:55:14 +0000
From: Leeyoung <leeyoung@huawei.com>
In-reply-to: <D5EABC6FDAFDAA47BC803114C68AABF202806DEE@DEMUEXC012.nsn-intra.net>
X-Originating-IP: [10.192.11.62]
To: "Margaria, Cyril (NSN - DE/Munich)" <cyril.margaria@nsn.com>, ext Greg Bernstein <gregb@grotto-networking.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Message-id: <7AEB3D6833318045B4AE71C2C87E8E170C62FA55@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_m6x13q8mzXoWUenWBN1rEA)"
Content-language: en-US
Accept-Language: en-US
Thread-topic: [CCAMP] TR: New Version Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt
Thread-index: AQHMLMhCzlp3VH3iDkiHwqWAxd88IZTBsDEg
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <CCBFBB7025DF984494DEC3285C058152129673243E@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <4DF654C6.3070304@grotto-networking.com> <D5EABC6FDAFDAA47BC803114C68AABF2027CAC27@DEMUEXC012.nsn-intra.net> A <7AEB3D6833318045B4AE71C2C87E8E170C62F931@DFWEML501-MBX.china.huawei.com> <D5EABC6FDAFDAA47BC803114C68AABF202806DEE@DEMUEXC012.nsn-intra.net>
Subject: Re: [CCAMP] TR: New Version Notificationfordraft-peloso-ccamp-wson-ospf-oeo-03.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 15:55:29 -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:cyril.margaria@nsn.com] Sent: Friday, June 17, 2011 3:26 AM To: Leeyoung; ext Greg Bernstein; ccamp@ietf.org 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:leeyoung@huawei.com] Sent: Thursday, June 16, 2011 10:47 PM To: Margaria, Cyril (NSN - DE/Munich); ext Greg Bernstein; ccamp@ietf.org 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Margaria, Cyril (NSN - DE/Munich) Sent: Wednesday, June 15, 2011 2:36 AM To: ext Greg Bernstein; ccamp@ietf.org 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of ext Greg Bernstein Sent: Monday, June 13, 2011 8:20 PM To: ccamp@ietf.org 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 CCAMP@ietf.org<mailto:CCAMP@ietf.org> https://www.ietf.org/mailman/listinfo/ccamp -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
- [CCAMP] TR: New Version Notification for draft-pe… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] TR: New Version Notification for draf… Greg Bernstein
- [CCAMP] Review of draft-peloso-ccamp-wson-ospf-oe… Greg Bernstein
- Re: [CCAMP] TR: New Version Notification fordraft… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] TR: New Version Notification fordraft… Greg Bernstein
- Re: [CCAMP] TR: New Version Notification fordraft… Greg Bernstein
- Re: [CCAMP] TR: New Version Notification fordraft… Leeyoung
- Re: [CCAMP] TR: New Version Notification fordraft… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] TR: New Version Notificationfordraft-… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] TR: New Version Notification fordraft… Fatai Zhang
- Re: [CCAMP] TR: New Version Notification fordraft… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] TR: New Version Notification fordraft… Greg Bernstein
- Re: [CCAMP] TR: New Version Notificationfordraft-… Leeyoung
- Re: [CCAMP] TR: New Version Notificationfordraft-… Julien Meuric
- Re: [CCAMP] TR: New Version Notificationfordraft-… Greg Bernstein
- Re: [CCAMP] TR: New Version Notificationfordraft-… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] TR: New Version Notificationfordraft-… Greg Bernstein
- Re: [CCAMP] TR: New Version Notificationfordraft-… Leeyoung
- [CCAMP] Moving the WSON discussion forward (Was R… Lou Berger
- Re: [CCAMP] Moving the WSON discussion forward (W… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] Moving the WSON discussion forward (W… Greg Bernstein
- Re: [CCAMP] Moving the WSON discussion forward (W… Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Moving the WSON discussion forward (W… Greg Bernstein
- [CCAMP] Change 1: Introduction of resource pool e… PELOSO, PIERRE (PIERRE)
- [CCAMP] Change 2: Use of connectivity matrix to d… PELOSO, PIERRE (PIERRE)
- [CCAMP] Change 3: Reduction of the scope of Resou… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] Change 1: Introduction of resource po… Leeyoung
- Re: [CCAMP] Change 2: Use of connectivity matrix … Greg Bernstein
- Re: [CCAMP] Change 3: Reduction of the scope of R… Greg Bernstein
- Re: [CCAMP] Change 1: Introduction of resource po… Greg Bernstein
- Re: [CCAMP] Change 2: Use of connectivity matrix … Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Change 2: Use of connectivity matrix … Greg Bernstein
- Re: [CCAMP] Change 2: Use of connectivity matrix … Margaria, Cyril (NSN - DE/Munich)
- Re: [CCAMP] Change 2: Use of connectivity matrix … Greg Bernstein
- Re: [CCAMP] Change 2: Use of connectivity matrix … Julien Meuric
- Re: [CCAMP] Change 2: Use of connectivity matrix … Greg Bernstein
- Re: [CCAMP] Change 2: Use of connectivity matrix … Lou Berger
- Re: [CCAMP] Change 1: Introduction of resource po… PELOSO, PIERRE (PIERRE)
- Re: [CCAMP] Change 1: Introduction of resource po… Greg Bernstein
- Re: [CCAMP] Change 1: Introduction of resource po… t.petch
- Re: [CCAMP] Change 1: Introduction of resource po… Greg Bernstein