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

Lou Berger <lberger@labn.net> Wed, 06 February 2013 12:53 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979A121F854B for <ccamp@ietfa.amsl.com>; Wed, 6 Feb 2013 04:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.267
X-Spam-Level:
X-Spam-Status: No, score=-102.267 tagged_above=-999 required=5 tests=[AWL=1.332, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApDlLe6DTE8T for <ccamp@ietfa.amsl.com>; Wed, 6 Feb 2013 04:53:45 -0800 (PST)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 5E97321F8445 for <ccamp@ietf.org>; Wed, 6 Feb 2013 04:53:45 -0800 (PST)
Received: (qmail 1919 invoked by uid 0); 6 Feb 2013 12:53:18 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 6 Feb 2013 12:53:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=V09oePc+KMqwELhmCB+UOVyR//JKxoCXfHWtNMrSA+k=; b=Ez6f5b1+VCC6bOSk8ckDNhZh+nj1iIL9NhMkXw03fXq50mnfcwXQmHL5mW1JCUrCo644TKBMF/p5VF1kVzdLStqsyfsx4hxdfBlmzJqOW32qaK3pi00ELYcMC3mFG3ek;
Received: from box313.bluehost.com ([69.89.31.113]:44874 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1U34V4-0004FP-5F; Wed, 06 Feb 2013 05:53:18 -0700
Message-ID: <5112523D.9060202@labn.net>
Date: Wed, 06 Feb 2013 07:53:17 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "BELOTTI, SERGIO (SERGIO)" <sergio.belotti@alcatel-lucent.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Fatai Zhang <zhangfatai@huawei.com>
References: <F82A4B6D50F9464B8EBA55651F541CF83585B3CE@SZXEML552-MBX.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D3B3CCD0@xmb-rcd-x14.cisco.com> <0182DEA5604B3A44A2EE61F3EE3ED69E145055F2@BL2PRD0510MB349.namprd05.prod.outlook.com> <511189F0.8030709@labn.net> <F82A4B6D50F9464B8EBA55651F541CF83585B7E4@SZXEML552-MBX.china.huawei.com> <5111BA4D.8050900@labn.net> <F82A4B6D50F9464B8EBA55651F541CF83585B8A6@SZXEML552-MBX.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE4807A90D@ESESSMB301.ericsson.se> <B9FEE68CE3A78C41A2B3C67549A96F48AA32@FR711WXCHMBA05.zeu.alcatel-lucent.com>
In-Reply-To: <B9FEE68CE3A78C41A2B3C67549A96F48AA32@FR711WXCHMBA05.zeu.alcatel-lucent.com>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] R: Poll on ODUFlex-related encoding
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2013 12:53:46 -0000

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:daniele.ceccarelli@ericsson.com] 
> Inviato: mercoledì 6 febbraio 2013 10.43
> A: Fatai Zhang; Lou Berger
> Cc: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
> 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: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 
>> On Behalf Of Fatai Zhang
>> Sent: mercoledì 6 febbraio 2013 3.07
>> To: Lou Berger
>> Cc: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; 
>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>> 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:lberger@labn.net]
>> Sent: Wednesday, February 06, 2013 10:05 AM
>> To: Fatai Zhang
>> Cc: John E Drake; Zafar Ali (zali); CCAMP; 
>> draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org; 
>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>> 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:lberger@labn.net]
>>> Sent: Wednesday, February 06, 2013 6:39 AM
>>> To: John E Drake
>>> Cc: Zafar Ali (zali); Fatai Zhang; CCAMP; 
>>> draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org;
>>> draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
>>> 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
>>>
>>>>> CCAMP@ietf.org
>>>
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>>>>
>>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
> 
> 
> 
>