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

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

Hi Lou- 

Please see in-line.

Thanks

Regards...Zafar

On 1/27/13 9:46 PM, "Lou Berger" <[e-mail]> wrote:

>Zafar,
>	Is your comment with respect to just routing or both signaling and
>routing?

Both, including consistency between signaling and routing attributes.

>
>Also, when you say "implementations based on draft versions", do these
>implementations include support for ODUflex?  (Which has really been the
>focus of the discussion.)

Yes, I was referring to ODUFlex. As you know, fixed ODU is signaled via
level (0 BW) so its not an issue.

>
>BTW I took Fred's comments as related to just the new OTN-specific ISCD
>definitions (section 4.1.2 of ospf-g709v3-05, in particular).  Note that
>section 4.1.1 already carries N (number of ODUs) not IEEE floating point
>representations of available bandwidth.

What I meant is Unreserved Bandwidth at priority x and Max LSP Bandwidth
at priority x. 

>
>Much thanks,
>Lou
>
>On 1/27/2013 7:46 PM, Zafar Ali (zali) wrote:
>> 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
>> 
>> 
>> 
>> 
>>