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

Greg Mirsky <gregimirsky@gmail.com> Thu, 01 August 2019 18:54 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 975281200E5; Thu, 1 Aug 2019 11:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 G7JRFEoPZHjG; Thu, 1 Aug 2019 11:54:26 -0700 (PDT)
Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 7FC231201CC; Thu, 1 Aug 2019 11:54:13 -0700 (PDT)
Received: by mail-lj1-x241.google.com with SMTP id v24so70559497ljg.13; Thu, 01 Aug 2019 11:54:13 -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=czF9oIey3fev0D7rfy5V86twmpFSkkRVsrBi2dimCd0=; b=G8ffrX5viA4wiR1B+ofN0KCSx5vaG/cd4mVjvOExUJg18aBw9+asMKqbSYZnSYHsjp sA/Iob/J34qNQ3aC1+tP9XnwGOibLj09VV6F1FOLnFCxHqqpZ+4ITRgYk9A+w+qYbSjD 1PJNWTM/B0uHJjvyKllolZhIVwyiAz9DZdb/mSlCssTVVk6qTGdc3ITmAAOF0GKotOxy wXelMOZQ0EftAAeKNOIZvmyHMIb+m4cA9b2z6bRxuaFk4Fma4kVN+/mQu0PutyEnTXsb JM5FwG2KkJQeON6SsJOQgXub9SfUJmny4Uc6LksGjvXtODb3GWN3XZgWu1GHxwgkMZp0 Caiw==
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=czF9oIey3fev0D7rfy5V86twmpFSkkRVsrBi2dimCd0=; b=dmwdpLUFl1yzoUb8UeCUkl8civqzrIi7c+1DFaQzn/d00YNc66zaYaWyUHYjUzsY8H gInSvGju25ct1+fymB2s9Sg7M3+618HwK6f8MzhoCvtKiS7dm7EqizbD+4nsQWdEqYWE QsZBgZMdZ79LPwNvhmZwzBGGZvZ92TaraKp8uiTlT7wQr3w4WfVF19VXIu5q06PbwUxm VG8mxh4r45n/Hsy5x11dV29Lu5qG/1syg2kGZXQtPN0gT4HuFw8xIN/sFolMlzffAd1g jw5NXyYwCBddKk9bci6ldQTiuYijJfWEwn3YzfhlQ1+Adr5HLGeFE1BW4uJCvpuYAdfh Yphw==
X-Gm-Message-State: APjAAAV7g1uTzEueJyCrCPXk83b8TRytuhs1HUzqvbk2l1rGCfNRB+XP 1xCizZwTGwKcNq4LthX2XEJTuBtZTXy1kbqYeHQ=
X-Google-Smtp-Source: APXvYqzVQcKLigvxvAenTz1YLfTA2AUnviH64KQWWxPQRSnfTFS3+5x4nH69sylJjy+VFosDOnUYuYyZgqXZK4Avmr0=
X-Received: by 2002:a2e:b047:: with SMTP id d7mr29063649ljl.8.1564685651568; Thu, 01 Aug 2019 11:54:11 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmVnkMFEQv=Hr3y9OD09+_vocHRgnGQnLwEVO=yuTcptEQ@mail.gmail.com> <EAB5C70D-A160-423E-84FE-3CE7AC079168@trammell.ch> <CA+RyBmWxh+FRxnrFH9ZbQ_F0V42UTm8aE0yOpd2N7vXb-Eqaiw@mail.gmail.com> <CAPDqMeoS8ZatMF9SXNYi0bPDdRN7T0gj-snxrLNL+1arGv5RTw@mail.gmail.com> <BYAPR11MB258458D075E929C9C0CF4901DADE0@BYAPR11MB2584.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB258458D075E929C9C0CF4901DADE0@BYAPR11MB2584.namprd11.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 1 Aug 2019 14:54:01 -0400
Message-ID: <CA+RyBmXzZvi7GBC6OJ_+RcRFp_xQMmfnGAwhxUdh9YQ-4fBw3A@mail.gmail.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
Cc: Tom Herbert <tom@quantonium.net>, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000726d1c058f12c463"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/vOdfSADvvYQcVqmUQF2R8OhRwr8>
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: Thu, 01 Aug 2019 18:54:30 -0000

Hi Frank,
thank you for your expedient response and the clarification, much
appreciated. I have some follow-up questions but your response, in
my opinion, supports my original evaluation of the draft that it is not
ready for WG adoption. I don't agree that the presumed benefits of the
proposed Loopback flag outweigh risks that were called out during the
meeting and were pointed by Tom and me.
Also, thank you for informing everyone that a design team is forming to
define the use of the Immediate flag. I think that that flag should be
introduced along with the clear and firm specification of its utilization.
And I'm still not clear about how the Active flag can be used. You suggest
that it is intended as complementary to "an operator who uses his own
probing". What such "own probing" could be? Why would the operator use
well-known standard-based active OAM for fault management and performance
monitoring?
And, going back to the scenario in DC. I wonder why the well-known
Traceroute is not sufficient?

Regards,
Greg

On Thu, Aug 1, 2019 at 12:32 PM Frank Brockners (fbrockne) <
fbrockne@cisco.com> wrote:

>
> Some additional notes on the different flags - restating and expanding the
> discussion we had at the WG meeting in Montreal:
>
> Loopback flag:
> The loopback flag was inspired by a specific use case, which could be
> summarized as "rapid identification of a failed link/node in a DC": In a DC
> (read: controlled/specific domain), one runs UDP probes
> (draft-lapukhov-dataplane-probe-01) over a v6 fabric. In case a UDP probe
> detects a failure, one adds the IOAM trace option and enables loopback mode
> - i.e. every node sends a copy back to the source in addition to forwarding
> the packet. Correlating the information from both ends allows one to
> pinpoint the failed node/link rapidly and gives one a view of the overall
> forwarding topology. This use-case was implemented in FD.io/VPP roughly 2
> years ago and was also showcased at IETF bits-n-bites. There is a rough
> outline of the open source implementation available here:
> https://jira.fd.io/browse/VPP-471 .
> In more generic words: Loopback mode is like all IOAM, a domain specific
> feature. Loopback mode is to enrich an existing (here the dataplane-probe)
> active OAM mechanism.
> Reading through the comments below, it proves that the current draft is
> indeed a good basis for the discussion and it also clearly shows that we
> need to add a section to the document that expands on how loopback mode is
> expected to be used.
>
> Immediate export flag:
> Per the WG discussion in Montreal - and the follow up breakout meeting (
> https://mailarchive.ietf.org/arch/msg/ippm/Do9kJ9ED_grmTqwcZHSdpy3CmRk):
> The plan is to consolidate the IOAM-related content for a new "immediate
> export option" from draft-song-ippm-postcard-based-telemetry-04 and the
> description of the immediate export flag in draft-mizrahi-ippm-ioam-flags
> into a new draft.
>
> Active flag:
> The active flag is not to replace any existing active OAM mechanisms - but
> rather allow an operator who uses his own probing along with IOAM to flag a
> packet as a probe packet.
>
> Security considerations for flags in the context of PNF vs. VNF:
> Thanks for raising the point. It would be great to see specifics/details
> discussed here on the list, so that those could be incorporated into the
> security section.
>
> Thanks, Frank
>
> > -----Original Message-----
> > From: ippm <ippm-bounces@ietf.org> On Behalf Of Tom Herbert
> > Sent: Donnerstag, 1. August 2019 00:41
> > To: Greg Mirsky <gregimirsky@gmail.com>
> > Cc: IPPM Chairs <ippm-chairs@ietf.org>rg>; IETF IPPM WG <ippm@ietf.org>
> > Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re:
> > Regarding draft-mizrahi-ippm-ioam-flags
> >
> > On Wed, Jul 31, 2019 at 11:53 AM Greg Mirsky <gregimirsky@gmail.com>
> > wrote:
> > >
> > > 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?
> >
> > This is unclear to me also. Additionally, I am concerned that protocol
> blindly
> > reflects the packet back to the source without any regard to what else
> the
> > packet contains. For instance, if a TCP packet is reflected by ten
> intermediate
> > nodes this is nonsensical. The possibility of an amplification attack is
> obvious
> > and in fact mentioned in the security section, however I'm skeptical
> that the
> > proposed mitigation of rate limiting is sufficient.
> >
> > Minimally, it seems like the reflected packets should be wrapped in ICMP
> to
> > mitigate spoofing attacks. Also, I wonder if traceroute methodology
> could be
> > used for tracing, i.e. one sent packet results in at most one return
> packet (ICMP),
> > to mitigate the amplification problem.
> >
> > Tom
> >
> > > 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 (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
> > >>
> > > _______________________________________________
> > > ippm mailing list
> > > ippm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ippm
> >
> > _______________________________________________
> > ippm mailing list
> > ippm@ietf.org
> > https://www.ietf.org/mailman/listinfo/ippm
>