Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags

Greg Mirsky <gregimirsky@gmail.com> Wed, 31 July 2019 18:53 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1DC12006D; Wed, 31 Jul 2019 11:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 6hgUA4gR71q2; Wed, 31 Jul 2019 11:53:49 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 18C6C12004F; Wed, 31 Jul 2019 11:53:49 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id y17so42120017ljk.10; Wed, 31 Jul 2019 11:53:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gZzZogq5KiNnoltkarA3nn+bfPyZiZk5bWp/I/bJjbM=; b=WEsviOzwuj4Wyp5oTt6d2AktK8eP2Ur8RScuDhF6OygKoqVt94T+EppQJvSvDSwOfl ikTMmfjmrf+v+DeDeWaIA2HXEWkXe3PyhuXMzOwIfMQ+o4UAotz836Ajz6Q5D7lNU3Y3 CI6ZnCOO76cdvh/nOlsJPQIFq2StxpK3i+h+2RYX45Ot9FWI9I5+Ue6ts9W/QHH9QqBF bZtsHp8vSOVxJr3QbadMGdVBwDC9pZpudOnxK+VnwyqaM7CqtddZuBZg9GfCjq861XWy nNKcYiQAxIev3bVCUwAsnM0NOSYdEQV4TUQqpTHn8AbMNeNuOv60T1QQxx75G9ax3rgd K1jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gZzZogq5KiNnoltkarA3nn+bfPyZiZk5bWp/I/bJjbM=; b=jA6mVTG65cci0W2wUL0HAVFD/s1+hhZItruEhmqYrrvJ+bbH37cAORNMUuK5y5+Spb Iv2wirM+ZA/PsKM7JX5Y/Yc3dCFnGr7vA2soDGsFJ9Ub90U04jGnhEnQc5e0U4W9kzbz NqCh/I4tbKVP8RZTiJrtR84lq1YZ70bSx9SZj58NY3jDmUkH21teNiVQlhlW9HgGcLS3 R5BRywp2usW3N/OXo0y+cL49znW9fq8/5fs/Gn74kzOHwfQyogDjUXz4Ry4wy4SXPHIf mHW9moJLDS/AtDoY7S84IzhgvCCTXHfVnk3SKtPKQ64ThvS3LySP36UDq8ttaWCwKa/u WbwA==
X-Gm-Message-State: APjAAAWTDzKgTDvXqI/HPwzANO11SET52PuAbIsr/q6eBuu97+QZwN5t M9MlOUdhTILUWiJSJZ9yvcJdRDRjP22ht+bfzdA=
X-Google-Smtp-Source: APXvYqxFOxriGueyqjeMMOoDUGmhwUCsDbKcuPj4+XvFkQ+UYCZuke4fKoOwe7EROHF2o3WFMpRvlIy61ydiyT0UA9o=
X-Received: by 2002:a2e:7d0c:: with SMTP id y12mr15622493ljc.36.1564599227225; Wed, 31 Jul 2019 11:53:47 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmVnkMFEQv=Hr3y9OD09+_vocHRgnGQnLwEVO=yuTcptEQ@mail.gmail.com> <EAB5C70D-A160-423E-84FE-3CE7AC079168@trammell.ch>
In-Reply-To: <EAB5C70D-A160-423E-84FE-3CE7AC079168@trammell.ch>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 31 Jul 2019 14:53:36 -0400
Message-ID: <CA+RyBmWxh+FRxnrFH9ZbQ_F0V42UTm8aE0yOpd2N7vXb-Eqaiw@mail.gmail.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000027a6a8058efea519"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/AvLeg9AGttb1yzSUIEK3UHpJbmA>
Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 18:53:53 -0000

Dear Authors,
thank you for bringing this proposal for the discussion. When considering
WG AP, I use the following criteria:

   - is the document reasonably well-written;
   - does it addresses a practical problem;
   - is the proposed solution viable?

On the first point, I commend you - the draft is easy to read.
On the second point, I have several questions:

   - What is the benefit of using Loopback flag in the Trace mode?
   - Why is it important to limit the applicability of Loopback to only
   Trace mode?
   - What is the benefit of collecting the same, as I understand the
   description, data on the return path to the source?
   - What is the benefit of using Active flag comparing to existing active
   OAM protocols?
   - What is the benefit of using Immediate flag comparing to Postcard-Based
   Telemetry
   <https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-04>
   (PBT) proposal?

On the third point, I'd appreciate your clarification on these points:

   - In which transports (I find that iOAM encapsulation has been proposed
   for all known transports) you've envisioned to use Loopback flag?
   - The third bullet in Section 5 refers to a replica of the data packet
   that follows the same path as the original packet. What controls that
   replication?
   - The last paragraph in the Security Consideration section relies on
   "restricted administrative domain" to mitigate the threat of malicious
   attacks using a combination of iOAM extensions. That might be the case when
   operating in a PNF environment, but it is much more challenging to maintain
   such a trusted domain in VNF environment. How can these new security risks
   be mitigated in a VNF environment?

Appreciate your consideration and clarifications to my questions.

Regards,
Greg

On Thu, Jul 25, 2019 at 2:07 PM Brian Trammell (IETF) <ietf@trammell.ch>
wrote:

> hi Greg,
>
> Thanks for the feedback; absolutely, we can do this the normal way.
> Authors: let's do a normal two-week adoption call for this document before
> publishing the update.
>
> This adoption call starts now.
>
> IPPM, please respond to this message with an indication to the mailing
> list of your support for adopting draft-mizrahi-ippm-ioam-flags as a
> working group document, in partial fulfillment of our charter milestone
> "submit a Standards Track draft on inband OAM based measurement
> methodologies to the IESG" (obviously, depending on how many documents we
> end up sending to the IESG, we may have to change the plurality of this
> milestone). If you do not support this, please send a message to the list
> explaining why.
>
> Thanks, cheers,
>
> Brian (as IPPM co-chair)
>
>
> > On 25 Jul 2019, at 13:15, Greg Mirsky <gregimirsky@gmail.com> wrote:
> >
> > Dear Chairs, et al.,
> > I appreciate that editors of draft-ietf-ippm-ioam-data followed on the
> decision of the WG reached at the meeting in Prague to extract material not
> directly related to the definition of iOAM data elements from the document.
> The new draft was presented earlier this week and generated many comments.
> I feel that it would be right to discuss the draft and its relevance to the
> charter of the IPPM WG before starting WG adoption poll.
> >
> > Regards,
> > Greg
>
>