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

["Zafar Ali (zali)" <[e-mail]>]

All-

This impacts existing implementations based on draft versions (and hence
interop with these implementations moving forward). IMO this is a bigger
change for us to assume at the last call stage. Furthermore we have been
using IEEE floating point format for Unreserved Bandwidth/ Max LSP BW in
IEEE floating point format for other technologies. Overall, I think this
change suffers from the "law of diminishing returns".

Thanks

Regards Š Zafar


On 1/27/13 10:28 AM, "Gruman, Fred" <[e-mail]> wrote:

>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: [e-mail] [mailto:[e-mail]] On Behalf Of
>Lou Berger
>Sent: Wednesday, January 23, 2013 9:08 AM
>To: Fatai Zhang
>Cc: CCAMP; [e-mail]
>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:[e-mail]]
>> Sent: Wednesday, January 23, 2013 2:11 AM
>> To: Fatai Zhang
>> Cc: CCAMP; [e-mail]
>> 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:[e-mail]]
>>> Sent: Friday, January 18, 2013 1:42 AM
>>> To: Fatai Zhang
>>> Cc: CCAMP; [e-mail]
>>> 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp