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

Lou Berger <lberger@labn.net> Wed, 23 January 2013 15:08 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 2050621F869A for <ccamp@ietfa.amsl.com>; Wed, 23 Jan 2013 07:08:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.981
X-Spam-Level:
X-Spam-Status: No, score=-100.981 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, 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 o2q-+cHjx75V for <ccamp@ietfa.amsl.com>; Wed, 23 Jan 2013 07:08:23 -0800 (PST)
Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 457AF21F869F for <ccamp@ietf.org>; Wed, 23 Jan 2013 07:08:23 -0800 (PST)
Received: (qmail 7908 invoked by uid 0); 23 Jan 2013 15:07:59 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 23 Jan 2013 15:07:59 -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=Hr6tJ0vrMIXm0hqzQMg5tFEHbcHloz+VBVjjCCCLSbo=; b=Sv1Gw9b3BvqDOoCE7HQQ2waeN2s+e5vVWNwUIyJ+NbyTkV9s66ZAGL21J73i16veGt7dw44sU/8NXDH01uD5xbBYMV86MJpWp6hvKIWDEacMiImIq31wQ8Ak+U5+6oaB;
Received: from box313.bluehost.com ([69.89.31.113]:37340 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1Ty1vi-00059B-QJ; Wed, 23 Jan 2013 08:07:59 -0700
Message-ID: <50FFFCD6.5010004@labn.net>
Date: Wed, 23 Jan 2013 10:08:06 -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> <50F837FB.2010806@labn.net> <F82A4B6D50F9464B8EBA55651F541CF8358571AD@SZXEML552-MBX.china.huawei.com> <50FED643.6020708@labn.net> <F82A4B6D50F9464B8EBA55651F541CF835857D6A@SZXEML552-MBX.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF835857D6A@SZXEML552-MBX.china.huawei.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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: Wed, 23 Jan 2013 15:08:24 -0000

Fatai,

On 1/23/2013 6:49 AM, Fatai Zhang wrote:
> Hi Lou,
> 
> For ODUflex(CBR), the formula is from [G.709-2012] and it has been
> discussed before, so please trust that there is no opportunity for
> misinterpretation. (Note that there are two cases, one is
> ODUflex(CBR) and another one is ODUflex(GFP)).
> 
> In addtion, ODUflex cannot be concatenated by [G.709-2012].

Thanks for confirming my understanding.  This raises the question of if
the new traffic should just apply to ODUFlex?  Correct me if I'm wrong,
but I believe the [RFC4328] is sufficient in all other cases.  This may
also make it easier for early implementations of the draft as then they
can limit code changes from the (-03) rev to only ODUflex LSPs.

Just to be clear, I'm really just *asking* about this.  As I said
before, I'm open on specifics...

Any thoughts/comments? Authors?  Implementors?

Thanks,
Lou


> I will issue a new version tomorrow to capture all your comments.
> 
> 
> Best Regards
> 
> Fatai
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Wednesday, January 23, 2013 2:11 AM
> To: Fatai Zhang
> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04
> 
> Fatai,
> 
> On 1/20/2013 9:43 PM, Fatai Zhang wrote:
>> Hi Lou,
>>
>> You said:
>>> but you're says encoded as (N*Nominal Rate) right? Wat's the value of this vs just carrying N?
>>
>> [Fatai] The original way (in version 04&05) is putting (N* Nominal
>> Rate) in "Bit_Rate" field for ODUflex(GFP), the value is that we can
>> generalize to just use one single "Bit_Rate" field to carry IEEE
>> float number for both cases, it seems that you don't agree on this
>> value, :-)
> 
> I've seen differences in calculated floating point values from different
> implementations, so I just want to ensure that such cases are avoided.
> I'm open to specific solutions and certainly will deffer on the
> specifics assuming there is no opportunity for misinterpretation/interop
> issues. I don't think the original passed this threshold, i.e.,:
> 
>          N = Ceiling of
> 
>    ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
>    ---------------------------------------------------------------------
>        ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
> 
>> . Therefore, I (was) am saying that I am going to accept
>> your suggestion to carry N for ODUflex(GFP). We are discussing where
>> to put N for ODUflex(GFP).
>>
> 
>> You said:
>>> 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).
>>
>> [Fatai] OK, I will add a new field (to occupy the reserved bits) to carry N.
> 
> As you see fit.
> 
> Just to clarify my understanding, ODUflex and Virtual concatenation can
> never be combined for the same signal type/level, right? (Although an
> ODUflex client signal could be carried over a virtual concatenated
> ODUk).  Is this correct or did I miss something in G709?
> 
> Thanks,
> Lou
> 
>>
>>
>>
>> Best Regards
>>
>> Fatai
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net] 
>> Sent: Friday, January 18, 2013 1:42 AM
>> To: Fatai Zhang
>> Cc: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04
>>
>>
>>
>> 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
>>
>>
>>
>>
> 
> 
> 
>