Re: [CCAMP] Poll on ODUFlex-related encoding

[Daniele Ceccarelli <[e-mail]>]

Just to summarize since different editors will update the FWK, info model and encoding docs.

We are going to reference only G.709 2012 (which has the updated text allowing only +/-100 ppm for ODUFlex) and not G.874.1 which needs to be updated accordingly.

Should this be formalized via a Liaison?

BR
Daniele  

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Fatai Zhang
>Sent: mercoledì 6 febbraio 2013 3.07
>To: Lou Berger
>Cc: CCAMP; [e-mail]; 
>[e-mail]
>Subject: Re: [CCAMP] Poll on ODUFlex-related encoding
>
>Hi Lou,
>
>Yes, we all agree that FWK and Info should be updated accordingly. 
>
>
>
>
>
>Best Regards
>
>Fatai
>
>
>-----Original Message-----
>From: Lou Berger [mailto:[e-mail]]
>Sent: Wednesday, February 06, 2013 10:05 AM
>To: Fatai Zhang
>Cc: John E Drake; Zafar Ali (zali); CCAMP; 
>[e-mail]; 
>[e-mail]
>Subject: Re: [CCAMP] Poll on ODUFlex-related encoding
>
>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
>> 
>>> 
>> 
>>> 
>> 
>>> 
>> 
>>> 
>> 
>>> 
>> 
>>> 
>> 
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp
>