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

"Gruman, Fred" <fred.gruman@us.fujitsu.com> Sun, 27 January 2013 15:28 UTC

Return-Path: <fred.gruman@us.fujitsu.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 CB52621F868B for <ccamp@ietfa.amsl.com>; Sun, 27 Jan 2013 07:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.399
X-Spam-Level:
X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, 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 4Vx4fW7H2pWy for <ccamp@ietfa.amsl.com>; Sun, 27 Jan 2013 07:28:36 -0800 (PST)
Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 034C921F8684 for <ccamp@ietf.org>; Sun, 27 Jan 2013 07:28:34 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,547,1355119200"; d="scan'208";a="26869372"
Received: from rchexhcp2.fnc.net.local ([168.127.134.76]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 27 Jan 2013 09:28:31 -0600
Received: from RCHEXMBP1.fnc.net.local ([169.254.2.98]) by RCHEXHCP2.fnc.net.local ([168.127.134.76]) with mapi id 14.02.0298.004; Sun, 27 Jan 2013 09:28:30 -0600
From: "Gruman, Fred" <fred.gruman@us.fujitsu.com>
To: Lou Berger <lberger@labn.net>, Fatai Zhang <zhangfatai@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
Thread-Topic: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04
Thread-Index: AQHN+XvkAlR2ZdjCKkOjwHzPHcwFmphdUBNA
Date: Sun, 27 Jan 2013 15:28:29 +0000
Message-ID: <5DF87403A81B0C43AF3EB1626511B2923C32F253@RCHEXMBP1.fnc.net.local>
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> <50FFFCD6.5010004@labn.net>
In-Reply-To: <50FFFCD6.5010004@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [168.127.136.253]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19594.000
x-tm-as-result: No--49.183400-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Sun, 27 Jan 2013 15:28:36 -0000

Hi Lou, Fatai, Daniele,

I understand the latest change to the way bandwidth is signaled for ODUflex(GFP), i.e., signaling the number of tributary slots N instead of the bandwidth rate in bps.  I believe that this simplifies the signaling and interoperability so I'm in agreement with this change.

However, it seems we are now inconsistent between how we represent bandwidth in routing and signaling for ODUflex(GFP).  Routing advertises the bandwidth using a floating point representation of bandwidth, while signaling is using the number of tributary slots. It seems the same benefits would be obtained by advertising the max LSP bandwidth and unreserved bandwidth for ODUflex(GFP) in terms of the number of tributary slots.

Fred



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Wednesday, January 23, 2013 9:08 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/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
>>
>>
>>
>>
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp