Re: [Lime-oam-model] Design Team report

Qin Wu <> Fri, 20 March 2015 02:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A524B1A92E5 for <>; Thu, 19 Mar 2015 19:36:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A6dPbxGhBWJx for <>; Thu, 19 Mar 2015 19:36:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6422B1A92E4 for <>; Thu, 19 Mar 2015 19:36:05 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BTW14731; Fri, 20 Mar 2015 02:36:04 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 20 Mar 2015 02:36:03 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Fri, 20 Mar 2015 10:35:56 +0800
From: Qin Wu <>
To: Tom Taylor <>, Gregory Mirsky <>, Ronald Bonica <>, "" <>
Thread-Topic: [Lime-oam-model] Design Team report
Thread-Index: AQHQYoJk3N7qFUQxyU+EYPD/wRsQwp0kpn3g
Date: Fri, 20 Mar 2015 02:35:56 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: "Deepak Kumar \(dekumar\)" <>
Subject: Re: [Lime-oam-model] Design Team report
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LIME WG OAM Model Design Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Mar 2015 02:36:07 -0000

Based on RFC7276,IP OAM is not primarily used for performance measurement.
RFC7276 Table 4 summarizes the OAM functions that are supported in each of
the OAM toolsets.
Toolset support one or several of these OAM functions including CC, CV, path discovery, performance measurement, other function.
Take IP OAM as example, CC can be supported by IP Ping Toolset using Echo request/reply messages and path discovery can be supported
By IP Traceroute toolset using Traceroute.

发件人: Tom Taylor [] 
发送时间: 2015年3月20日 4:22
收件人: Gregory Mirsky; Qin Wu; Ronald Bonica;
抄送: Deepak Kumar (dekumar)
主题: Re: [Lime-oam-model] Design Team report

The bottom line is this:
  -- what service does the IP layer provide? (Datagram service, of course, with no guarantees of ordering or delivery.)
  -- what are the observable defects in that service? I'd say loss, delay, and maybe jitter (or is that a transport-level (L4) defect?) beyond expected levels.
  -- what management tools do we need to detect these defects? To localize them? Do they fall into the alphabet soup of operations Qin is so keen on?

Obviously, ping and traceroute are the prime IP-level working tools. But I wouldn't call ping a matter of Connectivity Check except in the grossest sense. It's not normally a matter of 0% loss vs. 100% loss, but loss exceeding, say, 5%. You would have to redefine connectivity failure to mean "loss above expected level" to make ping fit into that framework. In the absence of such a definition, I would say that Connectivity Check has limited usefulness at the IP level. Connectivity Verification is, of course, totally irrelevant. One can think of some aspects of ICMP as Backward Defect Indication (e.g., Destination Unreachable).

Ping can certainly be seen as a performance measurement tool, for both delay and loss. And both ping and traceroute effectively use loopback.

Linktrace is a recurring issue, assuming it means tracing the exact path taken by packets. The ECMP problem was noted in the problem statement. 
IP OAM is missing a tool for that.

My conclusion is that IP OAM is implemented within limits. Performance measurement is the primary means to detect defects at the IP level. As a result, I don't quite agree with the entries in the IP column of Greg's table (in his message received at the IETF Tue,  3 Feb 2015 17:22:29
-0800 (PST)). Specifically, the Continuity Check items have to be qualified (Note 1), Connectivity Verification has to be a "No", there should be a qualified "Yes" for Backward Defect Indication (Note 2), and the Loss of Continuity Defect "Yes" should be qualified (Note 1 again).

Note 1: for IP OAM, "loss of continuity" is redefined to be an observed packet loss rate higher than the expected/engineered level for a duration of x seconds.

Note 2: some ICMP messages (e.g., Destination unreachable) can be interpreted as Backward Defect Indication.

Tom Taylor

On 19/03/2015 11:22 AM, Gregory Mirsky wrote:
> Hi Qin,
> I’m not aware of “IP for VPN” whether OAM or network. I believe 
> there’s IP regardless it is overlay or not. And the draft you’re 
> supporting so strongly does not apply to IP OAM.
>                  Regards,
>                                  Greg