Subject: [CCAMP] Regarding comments on draft-zhang-ccamp-rsvpte-ber-measure-00 in IETF88

From: Lizhenbin <[email-masked]>
Date: Fri, 28 Mar 2014 06:39:50 +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)