[CCAMP] Regarding comments on draft-zhang-ccamp-rsvpte-ber-measure-00 in IETF88
Lizhenbin <lizhenbin@huawei.com> Fri, 28 March 2014 06:40 UTC
Return-Path: <lizhenbin@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE6B01A0468 for <ccamp@ietfa.amsl.com>; Thu, 27 Mar 2014 23:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brlsc0LfVfZg for <ccamp@ietfa.amsl.com>; Thu, 27 Mar 2014 23:40:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF41A0462 for <ccamp@ietf.org>; Thu, 27 Mar 2014 23:40:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCM78232; Fri, 28 Mar 2014 06:40:15 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 06:39:19 +0000
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 28 Mar 2014 06:39:57 +0000
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.224]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 28 Mar 2014 14:39:51 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: "dbrungard@att.com" <dbrungard@att.com>, "eric.osborne@notcom.com" <eric.osborne@notcom.com>, "Jonathan.Hardwick@metaswitch.com" <Jonathan.Hardwick@metaswitch.com>
Thread-Topic: [CCAMP] Regarding comments on draft-zhang-ccamp-rsvpte-ber-measure-00 in IETF88
Thread-Index: Ac9KUITP2YNgaqHSRJaYy//uZqRcpw==
Date: Fri, 28 Mar 2014 06:39:50 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D08201C67@nkgeml506-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.76.77]
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D08201C67nkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/gFuYJhtrrTkV1UI3x5p4aJ3hNH4
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [CCAMP] Regarding comments on draft-zhang-ccamp-rsvpte-ber-measure-00 in IETF88
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 28 Mar 2014 06:40:26 -0000
Hi Deborah, Eric & Jon, Since I am late for applying for the timeslot in IETF89 to explain our thought on your comments, I have to reply your comments in IETF 88 on our draft-zhang-ccamp-rsvpte-ber-measure-00 through mailing list. Your comments is as follows: Deborah Brungard: There is not BER defined. The monitor is for a BER but the trigger is a degrade. You need to get aligned with the data plane aspects. Eric Osborne: If this is temporary function, how does it work with RSVP refresh? If this is a functionality always running, why not using IGP instead of RSVP? Jon Hardwick: The error rate measurement is an OAM function. I wonder why you don't want to use already defined mechanisms of RSVP to turn on and off OAM functions and define a new one. Our explanation is as follows: 1. Regarding mechanism for BER It is true that in IP network, the traffic stream is based on data packet switch and it is not available to get the accurate BER value. Instead, CRC (Cyclic Redundancy Check) is commonly used to detect accidental changes to raw data. As well known, the network service like radio signalling or voice is sensitive with the BER value in a particular range, which can be approximately denoted by CRC. So, in the actual implementation, the BER can be identified by CRC. 2. Regarding why RSVP-TE for BER instead of IGP Since the service is beared by RSVP-TE LSP, when BER exceeds the threshold, it should be notified by the LSP which care about the BER instead of flooding the information to all nodes through IGP. In addition, the BER indication is notified through PathErr message. It is not necessary to use the RSVP refresh mechanism. 3. Regarding Jon Hardwick's comments The existing OAM function is always packet loss ratio and delay which is measured at the end points of LSP. BER should be measured at each links along the LSP. It is different from existing OAM functions. It is a long time from IETF 88. Hope you can remember your comments :-). Best Regards, Zhenbin(Robin)