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

["Margaria, Cyril (NSN - DE/Munich)" <[e-mail]>]

Hi all, 

I prefer option 2) for the same reason of Zafar and Daniele.


Best regards / Mit freundlichen Grüßen
Cyril Margaria

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of ext Zafar Ali (zali)
> Sent: Tuesday, January 29, 2013 5:41 PM
> 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; draft-ietf-ccamp-gmpls-signaling-
> [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