Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 17 May 2020 17:58 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A103A0A9A; Sun, 17 May 2020 10:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 1wMnac_VZOqK; Sun, 17 May 2020 10:58:42 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780D73A0A96; Sun, 17 May 2020 10:58:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49Q8yp2LG1z6GHbQ; Sun, 17 May 2020 10:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1589738322; bh=u8nMSUIftAOplTqkyygDNidhJlRrEEFu0tmlixpqJoE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bVUiGoMWSWtDUKgjJdShNz8YMdTPmgNQe9o8TsR1HuRCfzE1Pbg2l9q7gBE3dD1Mf t6a1CJALvKHgv4FLclb6NAOJo+sigYmIZlWb9xtJXxCFIUq1UJt4Rzc1PkFk3ZbMfj ZWUFbAvPIT04UDDFQHT9BhCxoJcRpK4jW61K3gUg=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 49Q8ym5m37z6GD8r; Sun, 17 May 2020 10:58:40 -0700 (PDT)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "Nagendra Kumar Nainar (naikumar)" <naikumar=40cisco.com@dmarc.ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-sfc-oam-framework@ietf.org" <draft-ietf-sfc-oam-framework@ietf.org>, James N Guichard <james.n.guichard@huawei.com>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>, "sfc@ietf.org" <sfc@ietf.org>
References: <158885879619.21045.4121183716505139454@ietfa.amsl.com> <E44E9C8C-3ABA-4723-91F8-4F51E2EF7672@cisco.com> <9f34e226-9edf-0801-4d22-56d85e970d2a@joelhalpern.com> <fbdc127b-8666-e205-c2c7-1e78f3278a72@joelhalpern.com> <CAL0qLwY0tKCTG8N56RQNE7wJzb=WtxEjwXEvj-r2mMMbHJuo_g@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <b9a9de95-225f-4c34-a0c9-aa40cf3cb7dd@joelhalpern.com>
Date: Sun, 17 May 2020 13:58:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwY0tKCTG8N56RQNE7wJzb=WtxEjwXEvj-r2mMMbHJuo_g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/QlZKr42XbDImA3HxlEXhxDBv6gU>
Subject: Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-oam-framework-13: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 May 2020 17:58:44 -0000

The reason it (monitoring of SF functioning) is out of scope is that 
properly monitoring applications (which is fundamentally what service 
functions are) is a complex activity (art, from what I know of it).  It 
can not be done simply with data plane packets flowing through the 
service function path.  In fact, many of the most obvious techniques 
produce misleading and incorrect results.  I expect you know better than 
I what the current state of the art is for systems that monitor the 
liveness and correct operation of applications (including packet 
handling applications).

I fear that even trying to put text explaining this in the document 
could be confusing.

What I was reacting to specifically was the proposed text that seemed to 
imply that SFC would undertake work in this area.  That is not in our 
charter, and I do not want to mislead readers into believing that we 
will solve this problem for them.  As far as I know there is no IETF 
working group tackling this, or I would be happy to point at that work.

Yours,
Joel

On 5/17/2020 1:47 PM, Murray S. Kucherawy wrote:
> On Sun, May 17, 2020 at 9:07 AM Joel Halpern <jmh@joelhalpern.com 
> <mailto:jmh@joelhalpern.com>> wrote:
> 
>     Alvaro, Murray no longer has a Discuss.  So I am not sure what your
>     stance is.
> 
> 
> I cleared my DISCUSS because the discussion I wanted to have took 
> place.  As my comment now shows, I'm still left with the feeling that 
> this is a weak point in the document, but I'm not sufficiently concerned 
> as to obstruct its progress.
> 
> However, I think it's significant that two other Area Directors also 
> remarked about it, one expressly referencing my DISCUSS.
> 
> I suggest that if this aspect of the work is truly out of scope, the 
> document could perhaps explain why that is, because it certainly feels 
> like it needs more attention.
> 
> -MSK