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

Tom Taylor <tom.taylor.stds@gmail.com> Sat, 21 March 2015 11:32 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: lime-oam-model@ietfa.amsl.com
Delivered-To: lime-oam-model@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FCD1A923D for <lime-oam-model@ietfa.amsl.com>; Sat, 21 Mar 2015 04:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LodvLmcqL77g for <lime-oam-model@ietfa.amsl.com>; Sat, 21 Mar 2015 04:32:28 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BD81A923C for <lime-oam-model@ietf.org>; Sat, 21 Mar 2015 04:32:28 -0700 (PDT)
Received: by igcqo1 with SMTP id qo1so7295673igc.0 for <lime-oam-model@ietf.org>; Sat, 21 Mar 2015 04:32:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ezEWjeOPZhMgCxlyKcVh/S20SuVoneE9Y4pP07r1UKM=; b=Cs7Na3ubc9TqHFNbqHwUi3oNxtVFlZydcdhhq6IvjbuV06PUhKoissMlkr5wqQoSqb NfuQnPyAwjW6l3bN81UZlaWe+wwYBtRmXRvllJZU2HkcETK4s2Z0etFV0Ystu/hMthVO ivqCV2GigcevwqR5EsTtQV5AX6A1EDaah+BR8skBJeCyeqKSpR+LM5FaBljxqkEXIBEv gkd4b4+v5yoSzQtnMUrhyIsFzrpIv4AybN9Lt5tHJL99F+5edavuZt4xumDYZL9GYVtj YaIoT9vh5DThxBfGCzwPVBsySRu3OqRIrfDq73IUm9uZCSmowlWx5mvQCVL0AI1zfu41 erLg==
X-Received: by 10.50.124.133 with SMTP id mi5mr2748508igb.13.1426937547553; Sat, 21 Mar 2015 04:32:27 -0700 (PDT)
Received: from [192.168.1.135] (dsl-173-206-173-170.tor.primus.ca. [173.206.173.170]) by mx.google.com with ESMTPSA id m89sm5119371ioi.20.2015.03.21.04.32.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Mar 2015 04:32:26 -0700 (PDT)
Message-ID: <550D56C9.1030406@gmail.com>
Date: Sat, 21 Mar 2015 07:32:25 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: adrian@olddog.co.uk, 'Qin Wu' <bill.wu@huawei.com>, 'Gregory Mirsky' <gregory.mirsky@ericsson.com>, 'Ronald Bonica' <rbonica@juniper.net>, lime-oam-model@ietf.org
References: <CO1PR05MB4422C6491A3B7179F229574AE130@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B92F482@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA84702B17@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B92F643@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA84704C4C@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B92FA5F@eusaamb103.ericsson.se> <B8F9A780D330094D99AF023C5877DABA847066E3@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B930603@eusaamb103.ericsson.se> <BLUPR05MB433DD2E1CBEDF363CB13884AE010@BLUPR05MB433.namprd05.prod.outlook.com> <B8F9A780D330094D99AF023C5877DABA8470BE79@nkgeml501-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B9349F2@eusaamb103.ericsson.se> <550B2FEF.1030402@gmail.com> <B8F9A780D330094D99AF023C5877DABA8470D37B@nkgeml501-mbs.china.huawei.com> <550C13BD.60209@! gmail.com> <015f01d063b9$46c0bb80$d4423280$@olddog.co.uk>
In-Reply-To: <015f01d063b9$46c0bb80$d4423280$@olddog.co.uk>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/lime-oam-model/cBL17VbqcHklihSfcMH1-4sFgaU>
Cc: "'Deepak Kumar (dekumar)'" <dekumar@cisco.com>
Subject: Re: [Lime-oam-model] Design Team report
X-BeenThere: lime-oam-model@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LIME WG OAM Model Design Team <lime-oam-model.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime-oam-model>, <mailto:lime-oam-model-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lime-oam-model/>
List-Post: <mailto:lime-oam-model@ietf.org>
List-Help: <mailto:lime-oam-model-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime-oam-model>, <mailto:lime-oam-model-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2015 11:32:30 -0000

I do not ask that CC be redefined, though I suggested that it could be. 
The main point I wanted to get across is that IP-level defects are in 
the form of delay and loss, not just unreachability. You need the 
appropriate tools to detect each. Ping can do it all at a gross level. 
OWAMP and TWAMP become necessary when you are trying to get more exact, 
as when you want to verify that you are meeting an SLA.

I'm trying to understand Greg's concerns, so I'm poking a bit. Part of 
the problem, I think, is that RFC 7276 has named two tools and said that 
was the IP OAM toolset. But, focussing on LIME's intentions, if a defect 
is detected on a layer running above an IP transport segment, and the 
problem is at the IP layer, there needs to be a means to detect the 
corresponding IP-layer defect so it can be correlated with the one at 
the higher layer.

Bottom line: I'm saying that the generic LIME model should be able to 
trigger performance monitoring regardless of the layer under examination.

Tom

On 21/03/2015 5:27 AM, Adrian Farrel wrote:
> Hi Tom, all,
>
> Tom said
>
>> I guess RFC7276 is wrong, then.
>
> And i find that a little bit unhelpful.
> Since he was replying to Qin:
>
>>> 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.
>
> ...I assume that Tom asserts that at least one of these items captured from 7276
> is wrong.
>
> Let's look at them one at a time:
>
> "IP OAM is not primarily used for performance measurement"
> This statement is not found in section 4.1 (on IP ping) but may be deduced from
> that section.
> Furthermore the development of OWAMP and TWAMP lead one to deduce that IP ping
> was not suitable or performance monitoring.
>
> "RFC7276 Table 4 summarizes the OAM functions that are supported in each of the
> OAM toolsets."
> I think that fact is beyond dispute.
>
> "Toolset support one or several of these OAM functions including CC, CV, path
> discovery, performance measurement, other function."
> I think the definition of "toolset" speaks for itself.
>
> "Take IP OAM as example, CC can be supported by IP Ping Toolset using Echo
> request/reply messages"
> Section 4.1 has:
>     As defined in [NetTerms], it is a program
>     used to test reachability of destinations by sending them an ICMP
>     Echo request and waiting for a reply.
> I'm not asserting that RFC1208 is the only document that can describe IP ping,
> but it has been unquestioned for a while.
> Section 4.1 goes on:
>     The ICMP Echo request/reply exchange in Ping is used as a Continuity
>     Check function for the Internet Protocol.  The originator transmits
>     an ICMP Echo request packet, and the receiver replies with an Echo
>     reply.  ICMP Ping is defined in two variants: [ICMPv4] is used for
>     IPv4, and [ICMPv6] is used for IPv6.
> 2.7 defines CC as:
>        Continuity Checks are used to verify that a destination is
>        reachable, and are typically sent proactively, though they can be
>        invoked on-demand as well.
> So the statement looks good.
>
> "and path discovery can be supported by IP Traceroute toolset using Traceroute."
> I think that is self-evident!
>
>
> So what is the issue?
>
> Going back a bit I see Tom said:
>
>>>> 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.
>
> I wonder whether there is confusion about CC and LM.
> CC means "is the destination reachable?" It is binary over a relatively short
> period.
> LM means "how many of my packets get through?" It is qualitative over a longer
> period.
>
> So perhaps the debate is about the definition of CC, not about what tools can be
> applied to CC or whether 7276 is right in its description of the tools.
>
> I do not think that it will be helpful to debate the definition of some pretty
> well established terms related to OAM. If you want to define your own terms,
> that will be fine (then others can map them to the existing terms), but trying
> to change the meaning of terms that are in use will cause indigestion.
>
> Thanks,
> Adrian
>
>