Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

Lou Berger <lberger@labn.net> Fri, 18 January 2013 12:53 UTC

Return-Path: <lberger@labn.net>
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 0726021F88A8 for <ccamp@ietfa.amsl.com>; Fri, 18 Jan 2013 04:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.165
X-Spam-Level:
X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 XjfJVql9ywJX for <ccamp@ietfa.amsl.com>; Fri, 18 Jan 2013 04:53:19 -0800 (PST)
Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 6E22121F85B2 for <ccamp@ietf.org>; Fri, 18 Jan 2013 04:53:18 -0800 (PST)
Received: (qmail 30978 invoked by uid 0); 17 Jan 2013 17:42:36 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 17 Jan 2013 17:42:36 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=B30N5TgfkFhQLq9DqXRLaLL3BwPFWxnMz2iMnXktPJo=; b=gOVoa3+XObMgneRGXVDaUiVAUdNBMyt/lM+nVbeHyvBSU3++xZZLboqLLZWC/gVZ3I0mXxztMsSiNX98kf7iYBbcKJtLSZCNnCO00bYhD54Y347MLuEVpnJQ794SIGzz;
Received: from box313.bluehost.com ([69.89.31.113]:56537 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1TvtU4-0001w5-1n; Thu, 17 Jan 2013 10:42:36 -0700
Message-ID: <50F837FB.2010806@labn.net>
Date: Thu, 17 Jan 2013 12:42:19 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Fatai Zhang <zhangfatai@huawei.com>
References: <50733BED.8090304@labn.net> <5084A8C0.1010607@labn.net> <F82A4B6D50F9464B8EBA55651F541CF83583E820@SZXEML552-MBX.china.huawei.com> <50D31CB7.9000704@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835842D0F@SZXEML552-MBX.china.huawei.com> <50E5FD4A.1080207@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835855DB5@SZXEML552-MBX.china.huawei.com> <50F58A35.7040806@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835856301@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835856301@SZXEML552-MBX.china.huawei.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04
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, 18 Jan 2013 12:53:20 -0000

On 1/15/2013 10:16 PM, Fatai Zhang wrote:
> Hi Lou,
>
> To avoid misunderstanding, I would like to clarify more on the
> following point.
>
>
>>>>> It is better to have consistent format and the same meaning of one
field for both ODUflex(CBR) and GFP. This is why we have section 5.1
&5.2 to describe the complex stuff.
>>>> I actually wasn't suggesting that N be carried in the bit rate field.
>>>> The bit rate field can either be set as described or to zero (i.e.,
>>>> ignored).  At the time, I was thinking about carrying N in the reserved
>>>> field. But perhaps the right place is MT, if my understanding is right
>>>> (would always be 1 otherwise). I'm open to either...
>>>>
>>> [Fatai] Why not just use “bit rate”field to carry “N”because “N”
>>> implies bit rate?  I am OK if you like to use a new filed (like “TS
>>> Number”) to occupy the reserved field even though that I prefer the
>>> original approach (ie., use “bit rate”field to carry “N”).
>>
>> Are you proposing dropping carrying bit rates represented as an IEEE
>> floating point and just carrying N for ODUflex? This seems workable to
>> me, but we should ensure that there are no significant objections.
>
> [Fatai] There are two usages for " Bit_Rate " field as described in the
> lines 287-310.
>
> (1)    For ODUflex(CBR), the Bit_Rate field indicates the nominal bit
> rate of ODUflex(CBR) expressed in bytes per second, encoded as a 32-bit
> IEEE single precision floating-point number. For this case, we MUST use
> 32-bit IEEE floating point instead of “N”(Please see more in section 5.1).

I guess you really still need (to be based on) the client signal rate at
the edges.

>
> (2)    For ODUflex(GFP), we can change the text (the lines from 305 to
> 310) based on your suggestion, ie., the Bit_Rate field is used to carry
> “N”to indicate the nominal bit rate of the
> ODUflex(GFP).

but you're says encoded as (N*Nominal Rate) right?  Wat's the value of
this vs just carrying N?


>
> Therefore, I am proposing using one single filed ("Bit_Rate ") for these
> two cases, in this way, we can leave the "Reserved" bits for future.

bits in the control plane are generally cheap, IMO it's better to have
simpler encoding than to optimize every bit (or 8 in this case).

Lou

>
> Hope we are now at the same page.
>
>
> Best Regards
>
> Fatai