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

[Daniele Ceccarelli <[e-mail]>]

Option 2 for me too.

Main reason? I don't have to change the routing ID! :-) ...obviously joking.

Other reasons? Agree with Fatai and Zafar. And prefer 2) to 1) because defines a new C-type.

BR
Daniele 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Zafar Ali (zali)
>Sent: martedì 29 gennaio 2013 17.41
>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
>