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

[Daniele Ceccarelli <[e-mail]>]

Lou, 

it was really just a joke, no hidden meanings. 
If we find a reasonable solution for signaling that implies modifications to the routing we will modify the routing too (here I agree with Fred that alignment between signaling and routing is a SHOULD, if not a MUST).

Indepndently from changes to the routing i still believe that option 2 is the most reasonable. The fact that it is one of the options that does not imply changes to the routing is just a coincidence.

Thanks,
Daniele

>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]] 
>Sent: martedì 29 gennaio 2013 19.54
>To: Daniele Ceccarelli
>Cc: CCAMP
>Subject: Re: [CCAMP] Poll on ODUFlex-related encoding (was: WG 
>Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04)
>
>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
>>>
>> 
>