Re: [CCAMP] Poll on ODUFlex-related encoding

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Wed, 06 February 2013 09:43 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
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 09AE621F8550 for <ccamp@ietfa.amsl.com>; Wed, 6 Feb 2013 01:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level:
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 WzOzOjjTOpJw for <ccamp@ietfa.amsl.com>; Wed, 6 Feb 2013 01:43:40 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 46AD421F850C for <ccamp@ietf.org>; Wed, 6 Feb 2013 01:43:29 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-3e-511225c0b59e
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.78.19728.0C522115; Wed, 6 Feb 2013 10:43:28 +0100 (CET)
Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Wed, 6 Feb 2013 10:43:28 +0100
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: Fatai Zhang <zhangfatai@huawei.com>, Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding
Thread-Index: AQHOAJZDpmzxLSM8uESZ9dw6IzqjVJhluDAAgAPtjoCAATW8AIAAuNOAgAAFLoCAADerAIAALkiAgAALX4CAAACugIAAjWUQ
Date: Wed, 6 Feb 2013 09:43:27 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE4807A90D@ESESSMB301.ericsson.se>
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>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF83585B8A6@SZXEML552-MBX.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvre4BVaFAg6XfbCyezLnBYvG34TWL xdbZ95ktOprfslj0NZ9ndWD1aDnyltVjyZKfTB4fNjWzeXy5/JktgCWKyyYlNSezLLVI3y6B K2P5lSeMBQ12FSfmHmNuYFyo38XIySEhYCLxu+0AI4QtJnHh3no2EFtI4BCjxMF97F2MXED2 IkaJ2eemAhVxcLAJWEk8OeQDUiMi4Cbx9sM8sBpmgX+MEpMPXgRrFhYwlfh9spsNoshMYt38 28wQdp7EvTlv2EFsFgEVia/njoHFeQW8Je4s7WaEWHaQWWJbz3uwZk6BMInpDR+YQGxGAVmJ CbsXgV3KLCAucevJfCaIqwUkluw5zwxhi0q8fPyPFeRQCQFFieX9chDlehI3pk5hg7C1JZYt fA21V1Di5MwnLBMYxWYhmToLScssJC2zkLQsYGRZxciem5iZk15utIkRGFUHt/xW3cF455zI IUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilgMH/gMPEiynkbMK2GTrpDXsO vPfpFpu/8qJnSu50sabrv8T1ly2+pFicIR7IfWj9lr8Tmabq1kQ/LRd7J/R67u5ZOdwTNj/5 uSI280rQg01qVaG1dyaWvXqzgecw07l1q/yD9rL8Vfki8TJB9zuH8NRPJw6mO1iUTzExjAvf HvI60eKYgHHO4WolluKMREMt5qLiRACD47ZOeAIAAA==
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org>, "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>
Subject: Re: [CCAMP] 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 09:43:41 -0000

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.orgorg; 
>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
>