[CCAMP] R: Poll on ODUFlex-related encoding

["BELOTTI, SERGIO (SERGIO)" <[e-mail]>]

Ciao Daniele,

Your understanding is correct : the only reference is G.709 2012 that reports fixed value of tolerance for ODUflex (CBR) dependent of the management of maintenance signal.
The update of G.874.1 is a consequence of that. We can decide to write a "confirmation" to ITU along these lines.

BR

Sergio

Belotti Sergio - System Architect
ALCATEL-LUCENT  Optics Division

-----Messaggio originale-----
Da: Daniele Ceccarelli [mailto:[e-mail]] 
Inviato: mercoledì 6 febbraio 2013 10.43
A: Fatai Zhang; Lou Berger
Cc: CCAMP; [e-mail]; [e-mail]
Oggetto: RE: [CCAMP] Poll on ODUFlex-related encoding

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
>