Re: [CCAMP] R: Poll on ODUFlex-related encoding

[Lou Berger <[e-mail]>]

Sergio/Daniele/Fatai,

I think we all now clearly understand that the line/network/ODUk side of
ODUflex (CBR) needs to be allocated at 100ppm for AIS and other
maintenance signals to operate properly.  (Per note note 2 of table
7-2.) And that this means that nodes must allocate TSes based on the
tolerance implied by the signal type, per table 7-2.

But what about the client signal?  G.709 allows for lower/different
tolerance values per the same note and multiple other statements (search
for 'up to ±').

- Is the client signal still selectable by the equipment, or is it now
fixed?  If the latter, where is this change/restriction to G.709
documented? (Remember we/ccamp/ietf can't modify or limit the G.709 data
plane.)

- Is it okay for two nodes to run their client adaptation at different
tolerance values?

- Is it the client or line/ODUk signal tolerance that you are proposing
signaling?

On 2/6/2013 4:59 AM, BELOTTI, SERGIO (SERGIO) wrote:
> 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.
> 

If you mean, ask for confirmation of our understanding, this may be a
good idea.

Thanks,
Lou

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