Re: [CCAMP] Poll on ODUFlex-related encoding

[Lou Berger <[e-mail]>]

Fatai/Sergio,

G.709 has been stable for quite some time now.  I guess the discussion
on tolerance should have occurred once it was stable (1-2 years ago) or
whenever the change occurred the obviated your original motivation for
including tolerance in the first place.

Note that the framework still says:

      Therefore, bit rate and bit rate tolerance should
      also be carried in the Traffic Parameter in the signaling of
      connection setup request.

      For other ODU signal types, the bit rates and tolerances of them
      are fixed and can be deduced from the signal types.

and the info draft says:

   6. Bit rate and tolerance

   In the current traffic parameters signaling, bit rate and tolerance
   are implicitly defined by the signal type.  ODUflex CBR and Packet
   can have variable bit rates and tolerances (please refer to [OTN-FWK]
   table 2); it is thus needed to upgrade the signaling traffic
   parameters so to specify requested bit rates and tolerance values
   during LSP setup.

This text will be updated independent of the signaling format.

Lou

On 2/5/2013 8:24 PM, Fatai Zhang wrote:
> Hi Lou and all,
> 
>  
> 
> I think Serge and I have pointed out very clearly that Table 7-2 in
> G.709 is sufficient (No need to reference to G.874.1, in which it is
> wrong to say that “Allowable values of this attribute are 20 and
> 100.there is an error that should be corrected”, this error will & MUST
> be corrected in the next version of G.874.1).
> 
>  
> 
> Please have a look at Table 2 in G.709 (02/2012) and the Note 2. It says:
> 
>  
> 
> Note 2 –The bit rate tolerance for ODUflex(CBR) signals is specified as
> 100 ppm. This value may be larger than the tolerance for the client
> signal itself (e.g. 20 ppm). For such case, the tolerance is determined
> by the ODUflex(CBR) maintenance signals, which have a tolerance of 100 ppm.
> 
>  
> 
> I hope my mail can clarify your concern.
> 
>  
> 
> Note that I checked with the editor of G.709 before I said that G.709 is
> sufficent in the CCAMP list.
> 
>  
> 
>  
> 
> Best Regards
> 
>  
> 
> Fatai
> 
>  
> 
>  
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, February 06, 2013 6:39 AM
> To: John E Drake
> Cc: Zafar Ali (zali); Fatai Zhang; CCAMP;
> [e-mail];
> [e-mail]
> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding
> 
>  
> 
>  
> 
> John,
> 
>  
> 
> See question in-line below.
> 
>  
> 
> On 2/5/2013 2:19 PM, John E Drake wrote:
> 
>> Snipped, comment inline
> 
>> 
> 
>> Irrespectively Yours,
> 
>> 
> 
>> John
> 
>> 
> 
>>>>    0             1             2             3
> 
>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>>>  |  Signal Type  |       N       |        Reserved       |
> 
>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>>>  |              NVC           |      Multiplier (MT)     |
> 
>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>>>  |                      Bit_Rate                       |
> 
>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>> 
> 
>>> I just wonder are we not better off keeping Tolerance field in
> 
>>> signaling and adding a statement in v7 that this field is hardcoded to
> 
>>> 100ppm.
> 
>>> 
> 
>>> This has advantage of interworking with earlier draft implementations
> 
>>> and is also flexible for various (future/ unknown) client signal types.
> 
>>> I.e., we use the same encoding as defined thus far in the document
> 
>>> (copying from
> 
>>> v6):
> 
>>> 
> 
>>>       0                   1                   2                   3
> 
>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> 
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>>      |  Signal Type  |       N       |           Tolerance           |
> 
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>>      |              NVC              |        Multiplier (MT)        |
> 
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>>      |                            Bit_Rate                           |
> 
>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>>> 
> 
>>> And state that Tolerance MUST be set to 100 ppm.
> 
>> 
> 
>> 
> 
>> JD: This is a very good idea.  
> 
>  
> 
> Great.  Thanks for being clear on which option you support.
> 
>  
> 
>> 'Per [G.874.1/2011] (or whatever is
> 
>> the correct reference) Tolerance MUST be set to 100 ppm.'
> 
>> 
> 
>  
> 
> Is this correct (always 100ppm)?  Fatai/Sergio referred to table 7-2 in
> 
> G709 which has 20ppm for most signal types and 100ppm for others.  And
> 
> it seems there is some text that got dropped in the latest rev of
> 
> G.874.1 (from and earlier amendment).
> 
>  
> 
> In your role as ITU-T SG15 liaison manager, can you either figure out
> 
> what the right text & reference should be or propose a liaison that we
> 
> can send asking the ITU-T for whatever information we need to close this
> 
> issue/document?
> 
>  
> 
> Thanks,
> 
> Lou
> 
>  
> 
>>  
> 
>>> 
> 
>>> 
> 
>>> Thanks
> 
>>> 
> 
>>> Regards...Zafar
> 
>>> 
> 
>>>> <snip>
> 
>>> 
> 
>>> _______________________________________________
> 
>>> CCAMP mailing list
> 
>>> [e-mail]
> 
>>> https://www.ietf.org/mailman/listinfo/ccamp
> 
>> 
> 
>> 
> 
>> 
> 
>> 
> 
>> 
> 
>> 
>