Re: [CCAMP] Poll on ODUFlex-related encoding

Fatai Zhang <zhangfatai@huawei.com> Wed, 06 February 2013 01:52 UTC

Return-Path: <zhangfatai@huawei.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 D7AC321F89FD for <ccamp@ietfa.amsl.com>; Tue, 5 Feb 2013 17:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.176
X-Spam-Level:
X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, 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 nEMzuhqKEMW9 for <ccamp@ietfa.amsl.com>; Tue, 5 Feb 2013 17:52:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B842421F89F9 for <ccamp@ietf.org>; Tue, 5 Feb 2013 17:52:08 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APL80386; Wed, 06 Feb 2013 01:52:08 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 01:51:14 +0000
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 09:52:06 +0800
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.007; Wed, 6 Feb 2013 09:52:03 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>, John E Drake <jdrake@juniper.net>
Thread-Topic: [CCAMP] Poll on ODUFlex-related encoding
Thread-Index: AQHOAJZIlM0EpcpCsEW1cJUYjOCmwZhlxtjggANpjYCAAbfq8IAANqWAgAAFLoCAADerAIAAt4GA
Date: Wed, 6 Feb 2013 01:52:02 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF83585B85E@SZXEML552-MBX.china.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>
In-Reply-To: <511189F0.8030709@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.72.159]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-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 01:52:10 -0000

Hi Lou,

You said:

>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 an earlier amendment).

[Fatai] I think you mixed ODUflex and ODUj(j=0,1,2,3,4) together, so I would like to clarify a little more. 

For ODUj, the tolerance is fixed and it is 20ppm as in table 7-2 (In the draft, for the text to explain "Tolerance" field, it says "For other signal types (ie., non-ODUflex(CBR)), this field is not necessary and MUST be set to 0"). However, we are talking about ODUflex(CBR), whoes tolerance is also fixed and it is always 100ppm as in table 7-2. (Note that for ODU2e, its tolerance is fixed and is 100ppm as well).



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