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

Alvaro Retana <aretana.ietf@gmail.com> Mon, 18 May 2020 14:44 UTC

Return-Path: <aretana.ietf@gmail.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 3455B3A078F; Mon, 18 May 2020 07:44:23 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Ha95crthXgU9; Mon, 18 May 2020 07:44:22 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 D9FE73A076F; Mon, 18 May 2020 07:44:21 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id m12so9571226wmc.0; Mon, 18 May 2020 07:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=voQzHWfMgoiOxPqvmbBRxsNLfORTpuhsn06FTaP+eLQ=; b=YBpaSCbksUd14S66ziiRDPHY5SwPGzEIfmzRTITPTwq8Q8IEDWHIUVQpijFiXAx9gJ D2N3QPR8O2wA/MJZ6LIdIpUSkl8eYptgdFBZDCVnhuTFUf/Gh21pAPHoT93U+RcuB6qq 3AOEuXXUR19u6KzNcEB2LLZmt/Co/TnFH1SvhnSqaqFsBovyQmpCF7gLqcq6GN0DWmTV AVscQL47irQr3U6BozrBaCdPFknQADk0g25fOIxUmoAK337HbRqXgsck9sWrbwYSHCuq NhXIiwo3uJWRBx1MBpbUSQRcvHZ0an2cjZn7PXUqcJT5xvRtNzyoPs//3QfFWJd5QSEY v90A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=voQzHWfMgoiOxPqvmbBRxsNLfORTpuhsn06FTaP+eLQ=; b=eFoBj7jTtLqu75wGEG13HZ+TQ27GxFrWdnnsARby87ZrMrFQJexRjBGRYwUlp+Th53 QQSEQqcU/9Gs2TKxr+TFKFGR6c3aeELIEKBlxzRJy52glyNNvAgJYoedyiBrNfsOp8x+ 5XLyfdNdWnbNIpFZJChlu/srsslbd0gFi3hQ4JRlZ8UXX4FTneiV30qCyibWb5Oc9E3+ 1DGlC/uz25JnNMfamf83e/E3MhmItTXSNc2YFWb0oJCLD0OxnoOTrNZoNfmFeurBykOp +WetZD3mc4NEVfjXvvxi6q+tzcHF0PHKnHEAa/M81ue/bkxOc6bHH+zJeaHGLk1brxH0 k92g==
X-Gm-Message-State: AOAM532it1BpFsya5mmwSb40ZkzVQ3vR+/AQ4aKh8qU31vBlnlKvVEhM qlkahFRBmyvzuAe+6TjqrhO7YMUen039dFwStwM=
X-Google-Smtp-Source: ABdhPJwA/d1aMfU9CJwdAT+oc7oPAttigPCz73UJtENDOCTszWRGi0JnJWaDLGZCY+Kf22OWstSs+yiW8OMJf/DSgK0=
X-Received: by 2002:a05:600c:206:: with SMTP id 6mr19931263wmi.170.1589813060221; Mon, 18 May 2020 07:44:20 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 18 May 2020 10:44:19 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <fbdc127b-8666-e205-c2c7-1e78f3278a72@joelhalpern.com>
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>
MIME-Version: 1.0
Date: Mon, 18 May 2020 10:44:19 -0400
Message-ID: <CAMMESswJjTMmCEwb1k-Zaz_1fT4SWLXY75jmZOHW8Y_wwb0DMw@mail.gmail.com>
To: "Nagendra Kumar Nainar (naikumar)" <naikumar=40cisco.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>, Joel Halpern <jmh@joelhalpern.com>
Cc: "sfc@ietf.org" <sfc@ietf.org>, "draft-ietf-sfc-oam-framework@ietf.org" <draft-ietf-sfc-oam-framework@ietf.org>, "sfc-chairs@ietf.org" <sfc-chairs@ietf.org>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/NBSxZ5V73sCph698Pw-Lkxg8RSk>
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: Mon, 18 May 2020 14:44:23 -0000

On May 17, 2020 at 12:07:47 PM, Joel Halpern wrote:


Joel:

Hi!


> Alvaro, Murray no longer has a Discuss. So I am not sure what your
> stance is.

I've seen the proposed text and resolution to the DISCUSS.   I can
live with the resolution.


> And the particular change the authors have proposed seems to me to go
> too far, apparently promising that SFC OAM will validity SF
> functionality. That is out of scope for the document.
>
> Can you please clarify whether you feel there is still a discuss level
> issue here? And if you can live without this change?

In reading your other comments, I see your concern of setting
expectations beyond what the WG, or even the RTG Area, would have
expertise on.  Personally, I think there's a difference between what
an informational framework document may say and the expected product
of the WG.  IOW, a mention in the document shouldn't immediately
translate into a work item.


Because the document mentions the SF's ability to provide the service
as important, then I still think that not mentioning that as a gap
means that the document is incomplete.  I am not looking for a
solution in this document, and Murray's proposed text works for me --
maybe something could be added to it to explain why:

Current>
   The task of evaluating the true availability of a Service Function is a
   complex activity, currently having no simple, unified solution.  There is
   currently no standard means of doing so, and accordingly none is proposed
   here.

Add (Suggestion)>

   ...  Any such mechanism would be far from a typical OAM function, so it is
   not explored as part of the analysis in Sections 4 and 5.


Just a suggestion -- I am ok either way.


Thanks!!

Alvaro.