RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Young Lee <ylee@huawei.com> Mon, 21 July 2008 19:03 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C55F3A69F1 for <ietfarch-ccamp-archive@core3.amsl.com>; Mon, 21 Jul 2008 12:03:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdi+WD6VzM-E for <ietfarch-ccamp-archive@core3.amsl.com>; Mon, 21 Jul 2008 12:03:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 811663A6782 for <ccamp-archive@ietf.org>; Mon, 21 Jul 2008 12:03:46 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KL0Zu-000DqR-J8 for ccamp-data@psg.com; Mon, 21 Jul 2008 18:57:46 +0000
Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <ylee@huawei.com>) id 1KL0Zi-000Dm1-Gq for ccamp@ops.ietf.org; Mon, 21 Jul 2008 18:57:39 +0000
Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4D00HR9DZV0P@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Mon, 21 Jul 2008 13:57:31 -0500 (CDT)
Received: from L73682 ([10.124.12.97]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4D00BLQDZR64@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Mon, 21 Jul 2008 13:57:31 -0500 (CDT)
Date: Mon, 21 Jul 2008 13:57:27 -0500
From: Young Lee <ylee@huawei.com>
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
In-reply-to: <A278CCD6FF152E478C3CF84E4C3BC79D03A201DA@rchemx01.fnc.net.local>
To: "'Bardalai, Snigdho'" <Snigdho.Bardalai@us.fujitsu.com>, 'Greg Bernstein' <gregb@grotto-networking.com>
Cc: "'Ccamp (E-mail)'" <ccamp@ops.ietf.org>
Message-id: <005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)"
Thread-index: AcjrTzwgcGa+/c06Q++eyq5LkljokwAAusOQAAPa8sA=
References: <4884B8E7.8020602@grotto-networking.com> <A278CCD6FF152E478C3CF84E4C3BC79D03A201DA@rchemx01.fnc.net.local>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Hi Snigdho, See my response in-line. Thanks. Young _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Bardalai, Snigdho Sent: Monday, July 21, 2008 12:23 PM To: Greg Bernstein Cc: Ccamp (E-mail) Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt Hi Greg, Please see my responses. Thanks, Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of Greg Bernstein Sent: Monday, July 21, 2008 11:27 AM To: Bardalai, Snigdho Cc: Ccamp (E-mail) Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt Hi Snigdho! I've got some questions on your comments and I'll take a stab at some answers... Regards Greg Bardalai, Snigdho wrote: Hi Greg et al, I have a few comments on this draft proposal. 1. I believe basic WSON signaling extensions should be separated from signaling based RWA solutions. The reason is the scope of each problem is different. There are three basic requirements in the signaling draft (a) characterization of WSON signals, (b) bi-directional distributed wavelength assignment for WSON signals, and (c) an option for specifying the distributed wavelength assignment method to be used at each node. Items (a) and (c) were from Young and my original draft and (b) was from Sugang, Hiroki and Dan King's draft which the chairs mentioned we should merge with ours. Is item (c) bothering you? Or the combination of (a) with (b) and (c). We wanted the WG's opinion on item (c). [Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below you mention a "wireless" application, what application is this, what std. is it based on? It seems we are assuming something about the data-plane here. If that is not clearly defined how can we discuss about characterization? On the other hand I can completely understand what (b) and (c) is refering to. Hence, I believe the scope of (a) is different from (b) and (c). (b) and (c) are addressing some specific issues of distributed (signaling based) RWA. [Young] (b) actually does not deal with "distributed" wavelength assignment." Perhaps, we have to clarify some of the wordings used in the current draft to avoid misunderstanding. The main focus of (b) is how to permit simultaneous bi-directional wavelength assignment. It defines a signalling mechanism for same wavelength bidirectional lightpath to reduce setup times and lowers blocking probability. The exact wavelength to use hop-by-hop can be assigned by the PCE or by the NE. As for (c), we are asking the WG as Greg said before if we should retain it or not --- This is an optional feature for sure. The other concern is compliance to such a document. Typically there will be a choice between distributed (signaling based) or centralized (PCE/routing based) RWA, but (a) would be required to be supported for both RWA approaches. Hence I would consider (a) to be a basic requirement. I believe that we are mixing too many things here. 2. I believe we have not yet established what level of client layer characterization should be included in an OCH layer LSP. For that matter the definition of "Lightpath" is not yet completed and agreed. --> In the e-mail I sent concerning the WSON Framework document I brought up the issue of "lightpath" definition. In a more detailed reading of G.709 and G.872 I got the impression that OCh is a bit too restrictive. In G.709 it is defined from 3R to 3R. Now we want to include wavelength converters even if we are not currently dealing with impairments and most wavelength converters are regenerators (2R or 3R) with tunable lasers. G.872 doesn't consider the wavelength of the optical signal part of its characteristic information hence an OCh can go through a wavelength converter and they give an example in Appendix I. [Bardalai, Snigdho] Thanks for the clarification. 3. Basic WSON signaling should be in alignment with G.872 and G.709 concepts. Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. For signals not in the G.709 digital hierarchy the concepts and terminology of G.709/G.872 still apply (with some caveats): the OCh (optical channel), OMS (optical multiplex section), OTS (optical transmission section), and Physical Media Layer (the optical fiber itself). It seems that G.709 and G.872 have slightly different notions of what an OCh is (G.709 seeming more restrictive). Now from the practical side of things there are standards at the ITU-T that actually talk about characterizing the signals like G.696.1. To determine receiver compatibility we can run into trouble with a higher layer signal designation such as STM-256 since different modulation (RZ, NRZ) maybe used. Hence the ITU-T started defining signal classes by (a) modulation, (b) modulation parameters (if any), (c) bit rate, and (d) FEC. 4. If optical impairments is not in the current scope why do we need to encode "analog bit rate", will the client layer signal type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your purposes? --> Do you mean "analog bandwidth"? Although G.872 are aimed at transport of digital signals, I recall a request from someone to include some minimum ability to deal with "analog signals" for an application where wireless signals were put over the fiber without much processing. If you meant "bit rate" for a digital signal compatibility with the receiver and any OEO based wavelength converters... [Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and FEC is sufficient for OEO based digital signal compatibility, which means information such as encoding type, signal type etc. is necessary. Given that I cannot understand why we need to include the "analog bit rate", because based on signal type information it is possible to derive the bit-rate. Also, without completely understanding the wireless application it is not possible to say if we do require the analog bandwidth, so I will defer my comment on that till I understand what you are refering to. Thanks, Snigdho -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237
- Comments on draft-bernstein-ccamp-wson-signaling-… Bardalai, Snigdho
- Re: Comments on draft-bernstein-ccamp-wson-signal… Greg Bernstein
- RE: Comments on draft-bernstein-ccamp-wson-signal… Bardalai, Snigdho
- RE: Comments on draft-bernstein-ccamp-wson-signal… Young Lee
- Re: Comments on draft-bernstein-ccamp-wson-signal… Greg Bernstein
- RE: Comments on draft-bernstein-ccamp-wson-signal… Bardalai, Snigdho
- Re: Comments on draft-bernstein-ccamp-wson-signal… Greg Bernstein
- RE: Comments on draft-bernstein-ccamp-wson-signal… Bardalai, Snigdho
- Re: Comments on draft-bernstein-ccamp-wson-signal… Greg Bernstein