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

[Fatai Zhang <[e-mail]>]

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).



(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).



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.



Hope we are now at the same page.





Best Regards



Fatai