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

["Gruman, Fred" <[e-mail]>]

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'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