Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)

[Lou Berger <[e-mail]>]

Fred,
	Thanks for the input.

On 1/29/2013 12:54 PM, Gruman, Fred wrote:
> Hi Lou,
> 
> I am not clear on option 2 as when I look into draft-ietf-ccamp-gmpls-signaling-g709v3-05, the IANA section shows the c-type for the GENERALIZE_LABEL defined in RFC 3473, not a new c-type.
> 
> OTN-TDM Generalized Label Object: 
> 
>        o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see 
>          Section 5.1) 
>

I didn't notice that inconsistency.  Per
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-05#section-5:
 The traffic parameters for OTN-TDM capable Switching Type are carried
 in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have
 the following class and type:

    -  OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA)
    -  OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA)

Lou

> I'm open to either carrying ODUflex(GFP) bandwidth as floating-point or integer N, but would like to see consistency between routing and signaling documents.
> 
> 
> Regards,
> Fred
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Zafar Ali (zali)
> Sent: Tuesday, January 29, 2013 10:41 AM
> To: Lou Berger; CCAMP
> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
> 
> Hi Lou, C-campers: 
> 
> I would pick Option 2; it's cleaner and  addresses the issue related to
> overloading the same c-type.
> 
> Thanks
> 
> Regards…Zafar
> 
> 
> -----Original Message-----
> From: "[e-mail]" <[e-mail]>
> Date: Monday, January 28, 2013 3:25 PM
> To: "[e-mail]" <[e-mail]>
> Subject: [CCAMP] Poll on ODUFlex-related encoding (was: WG Last Call
> comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
> 
>> All,
>> 	We would like to try to close the discussion on the G.709
>> drafts so that we can move rapidly towards publication request.  The
>> discussion of (one of my) LC comments has resulted in several options
>> for the signaling ODU-related traffic parameters, and the point has
>> been raised that realigning routing with signaling should be discussed.
>>
>> Please keep in mind that the objective of any PS is interoperability,
>> and that there may be early implementations that match g709v3-04.
>>
>> The basic question is one of if N, the number of time slots needed to
>> support a ODUflex(GFP) signal, should be carried as a calculated IEEE
>> floating point number or directly.   Options 1 and 2 below reflect the
>> former, options 3 and 4 match the latter.  It is worth noting that only
>> options 1 and 2 are proposed for ODUflex(GFP), i.e., N must be
>> calculated for ODUflex(CBR) signal types with all options.
>>
>> Please state your support for one the options and, if you wish, the
>> justification for your position:
>>
>> 1) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-04
>>   i.e., redefine [RFC4328] Traffic Parameters c-type when used with
>>   OTN-TDM labels. ODUflex(GFP) number of tributary slots (N) is
>>   encoded as:
>>
>>   ... the Bit_Rate field for ODUflex(GFP) MUST
>>   equal to one of the 80 values listed below:
>>
>>       1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
>>       9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
>>       33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.
>>
>> 2) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-05
>>   i.e., use a new C-type for OTN-TDM labels.  Encoding details
>>   unchanged from g709v3-04.
>>   (This option addresses the issue of the same c-type needing to
>>    be parsed based on label/switching type.)
>>
>> 3) Follow draft-ietf-ccamp-gmpls-signaling-g709v3-06
>>   i.e.,  use a new C-type for OTN-TDM labels. N is directly carried
>>   for ODUflex(GFP) only.
>>
>> 4) Discussed, but not in any draft
>>   Use draft-ietf-ccamp-gmpls-signaling-g709v3-04 encoding for all
>>   but ODUflex(GFP), and define new ODUflex(GFP) specific Traffic
>>   Parameters based on g709v3-06, presumably with unused fields
>>   removed.
>>   (This also addresses the issue of the same c-type needing to be
>>    parsed based on label type, but means there are different types
>>    based on signal type.)
>>
>> Option 1 and 2 do not imply any changes to routing, while options 3 and
>> 4 may.  Routing implications will be discussed based on the results of
>> this poll, and only if there is consensus to support positions 3 or 4.
>>
>> We hope to make a consensus call by the end of the week, but will
>> continue the discussion as needed.
>>
>> Much thanks,
>> Lou (and Deborah)
>>
>> On 1/28/2013 5:08 AM, Daniele Ceccarelli wrote:
>>>  All,
>>>
>>> I think the changes proposed are meaningful and would support them in
>>> an individual or early WG draft, but they don't seem to provide
>>> significative advantages to risk interworking issues with early
>>> implementations.
>>> Moreover the changes don't allow us getting totally rid of of the
>>> bit_rate field as it is still needed for ODUflex (CBR).
>>>
>>> My 2c
>>> Daniele
>>>
>>>
>>>> -----Original Message-----
>>>> From: Zafar Ali (zali) [mailto:[e-mail]]
>>>> Sent: lunedì 28 gennaio 2013 4.47
>>>> To: Lou Berger
>>>> Cc: Gruman, Fred; Fatai Zhang; Daniele Ceccarelli; CCAMP;
>>>> [e-mail]
>>>> Subject: Re: [CCAMP] WG Last Call comments on
>>>> draft-ietf-ccamp-gmpls-signaling-g709v3-04
>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>