Re: [CCAMP] Poll on ODUFlex-related encoding

Fatai Zhang <zhangfatai@huawei.com> Wed, 06 February 2013 01:24 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 DB08B21F89AA for <ccamp@ietfa.amsl.com>; Tue, 5 Feb 2013 17:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.049
X-Spam-Level:
X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DanJCHx1If7s for <ccamp@ietfa.amsl.com>; Tue, 5 Feb 2013 17:24:30 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C4E2E21F89A6 for <ccamp@ietf.org>; Tue, 5 Feb 2013 17:24:29 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOE81605; Wed, 06 Feb 2013 01:24:29 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) 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:23:35 +0000
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 6 Feb 2013 01:24:28 +0000
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.16]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.007; Wed, 6 Feb 2013 09:24:20 +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: AQHOAJZIlM0EpcpCsEW1cJUYjOCmwZhlxtjggANpjYCAAbfq8IAANqWAgAAFLoCAADerAIAAr0Ow
Date: Wed, 6 Feb 2013 01:24:19 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF83585B7E4@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: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF83585B7E4SZXEML552MBXchi_"
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:24:32 -0000

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

>

>

>

>

>

>