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

Tom Taylor <> Thu, 19 March 2015 20:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 933CA1A905A for <>; Thu, 19 Mar 2015 13:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eChjzECEMulb for <>; Thu, 19 Mar 2015 13:22:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 056D11A9053 for <>; Thu, 19 Mar 2015 13:22:10 -0700 (PDT)
Received: by igcqo1 with SMTP id qo1so716927igc.0 for <>; Thu, 19 Mar 2015 13:22:09 -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=McX9Qtgdv5rl8v4Aw7UQfImqq2e///TgtksGxBy4z3Q=; b=Zgp8qDeGKVsAxddJtV1gXog78EcQbwMUj/b2BZ3ZTJFrC6+yBPkxQGpUhuXrXOw5qG JI58XcRI2DRZHwXZcKiQdIQI+u7/RroerUN6fW4SYrH4dINKkI3sEnFQc6rWD8X4bgda 9qRcw+/sTanyYy5ozmdak5wNuqAl/zFXF7FeTrYkhAvz5azYdUIPVy5Z5A3hlUvsYAfi OGHfAqNBeOkmZXBZfoBt0te0fRbnpqEiPeXcR9cCQ5obpMrqccw7hx+uZmaiB36OG/hZ QU7xIXNBxREnBWQF4glWpaLcqIWUg/l6l1NRSMdvLjmqmpyo3TIkV5g92k3CaeRhyUts JSoA==
X-Received: by with SMTP id m1mr20026537icy.10.1426796529504; Thu, 19 Mar 2015 13:22:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id k2sm1611684iok.11.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 13:22:08 -0700 (PDT)
Message-ID: <>
Date: Thu, 19 Mar 2015 16:22:07 -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: Gregory Mirsky <>, Qin Wu <>, Ronald Bonica <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; 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: Thu, 19 Mar 2015 20:22:11 -0000

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 

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