Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt

Greg Bernstein <gregb@grotto-networking.com> Mon, 21 July 2008 16:35 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 679483A6831 for <ietfarch-ccamp-archive@core3.amsl.com>; Mon, 21 Jul 2008 09:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.418
X-Spam-Level:
X-Spam-Status: No, score=0.418 tagged_above=-999 required=5 tests=[AWL=0.912, 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 BbaJg-nfZeED for <ietfarch-ccamp-archive@core3.amsl.com>; Mon, 21 Jul 2008 09:35:39 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D99513A6AB5 for <ccamp-archive@ietf.org>; Mon, 21 Jul 2008 09:35:38 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KKyET-0008oV-HZ for ccamp-data@psg.com; Mon, 21 Jul 2008 16:27:29 +0000
Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <gregb@grotto-networking.com>) id 1KKyEP-0008l1-7o for ccamp@ops.ietf.org; Mon, 21 Jul 2008 16:27:27 +0000
Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id m6LGRGdL022817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2008 09:27:23 -0700 (PDT) (envelope-from gregb@grotto-networking.com)
Message-ID: <4884B8E7.8020602@grotto-networking.com>
Date: Mon, 21 Jul 2008 09:27:19 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
CC: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
References: <A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local>
In-Reply-To: <A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local>
Content-Type: multipart/alternative; boundary="------------040406070905000408070004"
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

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).
>
> 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. 
>
> 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...
>
> Thanks,
> Snigdho
>

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