Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-signaling-g709v3-04

[John E Drake <[e-mail]>]

Good catch.

Irrespectively Yours,

John


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Gruman, Fred
> Sent: Sunday, January 27, 2013 7:28 AM
> To: Lou Berger; Fatai Zhang; Daniele Ceccarelli
> Cc: CCAMP; [e-mail]
> Subject: Re: [CCAMP] WG Last Call comments on draft-ietf-ccamp-gmpls-
> signaling-g709v3-04
> 
> 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