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

Tom Taylor <> Fri, 20 March 2015 12:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 354101B2CE8 for <>; Fri, 20 Mar 2015 05:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 38GCENz-mWM6 for <>; Fri, 20 Mar 2015 05:34:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BB101B2CE7 for <>; Fri, 20 Mar 2015 05:34:07 -0700 (PDT)
Received: by igcqo1 with SMTP id qo1so16400959igc.0 for <>; Fri, 20 Mar 2015 05:34:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YWxAz44TMaFetz0WxMZYNZSdES61Y5+sP1XXS9CaXaw=; b=O1AVxOev7c5gni4mKQxG40RAjBUQ9FqvH0QwFgcbjQGMbrwjT545I0lYs5+GLCOO7Q ew5DKln9+JIEkG74s8dtR5puhjfPYlSxFrHvXCuQ8NJobDTrOvDwieQ1+0FqALSnBGRL ZOxE5mNLEd6LxnHKKHrfQOhZHcpko2HvbXSfjZDDz4VRVSt5oeDIJwz3Da4hJck8cdqr oV6k+oqGhg/b5DYKU48PxuEluaqG85qTVwwHkGnUDnNSixis6+EZ0XMW25Ujz02UdcQS FGBv2QNyEDu8BG8dUgLEiXQsrr+KRjL5kRAGmSMpaIM40WWn7qgQwXAwn4BOftKUPVg2 rQaw==
X-Received: by with SMTP id d3mr7729966igx.0.1426854847128; Fri, 20 Mar 2015 05:34:07 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ir10sm3356248igb.2.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 05:34:06 -0700 (PDT)
Message-ID: <>
Date: Fri, 20 Mar 2015 08:34:05 -0400
From: Tom Taylor <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Qin Wu <>, Gregory Mirsky <>, Ronald Bonica <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=gbk; format=flowed
Content-Transfer-Encoding: 8bit
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 12:34:13 -0000

I guess RFC7276 is wrong, then.

On 19/03/2015 10:35 PM, Qin Wu wrote:
> 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.
> -Qin
> -----邮件原件-----
> 发件人: 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
> ...