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

[Lou Berger <[e-mail]>]

Agreed.   Just a heads-up to all, immediately following the conclusion
of the LC discussion on the signaling document.  Given the technical
changes, there will be a second last call conducted.

Lou

On 1/27/2013 12:47 PM, John E Drake wrote:
> Good catch.
> 
> Irrespectively Yours,
> 
> John
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Gruman, Fred
>> Sent: Sunday, January 27, 2013 7:28 AM
>> To: Lou Berger; Fatai Zhang; Daniele Ceccarelli
>> Cc: CCAMP; [e-mail]
>> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-
>> signaling-g709v3-04
>>
>> 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
> 
> 
> 
> 
> 
>