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

[Lou Berger <[e-mail]>]

Daniele,
	Joking aside, I think it may add value to the discussion to highlight
your rational for not wanting to change routing.  (You are after all the
editor of the routing draft.)

Is it:
- Just avoiding work for the editor (i.e., your joke...)?
- Minimizing a change at this late date?
- Minimizing impact on an early implementation?
- Something completely different?

If you don't mind sharing...

Thanks,
Lou

On 1/29/2013 1:31 PM, Daniele Ceccarelli wrote:
> 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
>>
>