Re: [ippm] WGLC for IOAM Direct Exports
Greg Mirsky <gregimirsky@gmail.com> Tue, 07 September 2021 22:00 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 A16A73A1AE1 for <ippm@ietfa.amsl.com>; Tue, 7 Sep 2021 15:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 oAMy_ZK-Dbsj for <ippm@ietfa.amsl.com>; Tue, 7 Sep 2021 15:00:28 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 784B73A1ADC for <ippm@ietf.org>; Tue, 7 Sep 2021 15:00:28 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id g21so11227edw.4 for <ippm@ietf.org>; Tue, 07 Sep 2021 15:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ZGYh/lM3fQOqxDPpUuiT5wLwjRviU4yZ4p5j5DZH4A=; b=hZPD8XFTBgDjzKTz7yIYauqQocbWAd9fbDRH91WP3GGT+PHEG2japyj3qyFF1xVx6D VDNwVPcRDRHd12E8u5W17L4dZ42qAC+JfEpfrbyzaL9+eIkLWOZpXV9x6mLaAIcfx7ci 6yth/Vr8lGVseAH5ktVk2AJhbs2S8ko1nqNiioGHjryll7/DvnUmL5kburJRvbmOS34b RZfIXV9cl3mmwIj5T5vVoRdbSbhnUwFNxbzVTBeNHMQU3JGnJ5lwX8MF1hr/MGLUa2E1 PXosdBViLLI9syS2fUIh0A4TXT0+asBbPgwxksZDq2uUL5s0Tw7cKNtl2QzNl7Zp6Ehh s5jw==
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=0ZGYh/lM3fQOqxDPpUuiT5wLwjRviU4yZ4p5j5DZH4A=; b=FjuAJlXLJBQPLiuwaMStNCZQELkreeluqeVXnkbt6QP6wkl58JQZeWUzcriBwMJ216 D/M8G6bBvEakWEt9mY/f9X5YOmGpqmOCZo84gRMlXHJ6CO6xvdKldblyzMCvNEWNluOd qjbFcxZQM3PtlAqskq7Mefc5FrfrWlYIq17UwqEpDiaUwNCq6Wr6kJchkmYxHyLa9iv3 z5M3Q7p4n1TnYTIysXj28oLHYakMfNVv1nPciewkctplqJDuXmZbRTms+u4TkEdhHwkc sO6DRtsZpGfEFkw0mF91d2h7NHr5brUZ9hhSMChpIYB6TXsPbdCzT/JZbJOA+VJCFjM0 exfQ==
X-Gm-Message-State: AOAM5308ta/8IzI6SYBET4ShtyebndDGP3RVMOVLoupr/FLmX1g41cVp 0/7J8r3bUNNW3ClWQi9+Ack0ExRg6ZaOQ4cqVoDrh2yhQiU=
X-Google-Smtp-Source: ABdhPJwKRBNvLGqRrU382DVwv2u4CGisMwaZe0qh7DhIq16qP5Gx5kyO+Kzo7C9F4giNF/4nOfjXJ/KdGK1RNc0PyPs=
X-Received: by 2002:aa7:c6c8:: with SMTP id b8mr394603eds.295.1631052025806; Tue, 07 Sep 2021 15:00:25 -0700 (PDT)
MIME-Version: 1.0
References: <A4F59F82-7F47-452B-9E63-0FDFBB812CEC@apple.com>
In-Reply-To: <A4F59F82-7F47-452B-9E63-0FDFBB812CEC@apple.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 07 Sep 2021 15:00:15 -0700
Message-ID: <CA+RyBmW3nKqMftmEZ+e=7OcZ_jukc71BHBt0BgVCxB8S9QvCRQ@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009bc57b05cb6ee4f3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/IraSV1padbsGv8lbQrODiLKwNGs>
Subject: Re: [ippm] WGLC for IOAM Direct Exports
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: Tue, 07 Sep 2021 22:00:34 -0000
Dear Authors, WG Chairs, and All, I've read the latest version of the draft and have several comments and questions to share with you. None of these are blocking, I support progressing this draft to publication. Please consider the notes below as an invitation to a discussion: - It seems that the characterization of the Direct Export IOAM option in the following is not entirely accurate: The DEX option is used as a trigger to collect and/or export IOAM data. I propose re-wording: The DEX option is used as a trigger to collect and export or only collect locally the IOAM data. Using "exporting and/or collecting" reflects the use of the Direct Export option type technically accurate but the order of actions is backward. What are your thoughts? - I find references to RFC 5475 and 7014 very appropriate and helpful. But I don't see these RFCs being referenced in draft-ietf-ippm-ioam-data <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/>. I think that excessive use of not only the Direct Export IAOM option but the IOAM method, in general, may adversely affect a network and the recommendations listed in RFC 5475 and 7014 are equally applicable. - Similarly, the good and helpful discussion of how to practically control the use of the Direct Export option is, in my opinion, equally applicable to other IOAM trace options and should be in the Security Considerations section of draft-ietf-ippm-ioam-data. - The second paragraph in Section 3.1.2 is re-phrasing if not repeating what is already expressed in the last paragraph of the previous sub-section (though the limit is applied to exporting telemetry information). I think that it can be removed without any loss to the document. - I think that it will be helpful to provide some recommendations, i.e., SHOULD do this, how an implementation handles the excess of packets to export. Drop silently, drop and log notification, or try to shape that flow? - I was really puzzled by this requirement in Section 3.1.2 Exported packets SHOULD NOT be exported over a path or a tunnel that is subject to IOAM direct exporting. I hope you can clarify it for me. - This requirement Furthermore, IOAM encapsulating nodes that can identify a packet as an IOAM exported packet MUST NOT push a DEX option into such a packet. brings up questions: - How can a node identify a packet as the IOAM exported packet? - What should be done if the IOAM exported packet contains the IOAM header with the DEX option? - What is special about the decapsulating node that is not DEX-capable? A decapsulating node that does not support the DEX option MUST remove it, along with any other IOAM options carried in the packet if such exist. Shouldn't that be a general behavior of a decapsulating IOAM node? - The format of the first four-octet word in Figure 2 is different from the format defined in draft-ietf-ippm-ioam-data: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID |NodeLen | Flags | RemainingLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Is this intentional? If it is, how does an implementation know which format to use? - It is stated in the draft that: The length of the DEX option is at least 8 octets. But the figure 2 in the draft does not include any field that reflects the length of the IOAM option. Is that because the figure is out of sync? If not, how can an implementation verify the length? Also, what is the behavior if the length is less than 8 octets? - RE: PerformanceConsiderations I agree with you that a DEX-encapsulating node and DEX-transit nodes must have rate-limiting controls (as noted earlier, the behavior of the transit node needs more detailed specification). But I think that the document should also note that exported packets could be sent over the network out-of-band, relative to the monitored flow. As a result, the impact of packets carrying telemetry information might be not direct and harmful to the data flow. I see that as one of the important benefits of the Direct Export method transporting on-path telemetry information. Regards, Greg On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly= 40apple.com@dmarc.ietf.org> wrote: > Hello IPPM, > > This email starts a Working Group Last Call on two related IOAM > documents, draft-ietf-ippm-ioam-flags > and draft-ietf-ippm-ioam-direct-export. > > In-situ OAM Loopback and Active Flags > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06 > > In-situ OAM Direct Exporting > https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/ > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06 > > Please provide feedback by replying to this email with your reviews and if > you think these documents are ready to progress, by *Wednesday, September > 15*. > > Best, > Tommy & Ian > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >
- [ippm] WGLC for IOAM Flags and Direct Exports Tommy Pauly
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Tal Mizrahi
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Frank Brockners (fbrockne)
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Haoyu Song
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Ramesh Sivakolundu (sramesh)
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Srihari Raghavan (srihari)
- Re: [ippm] WGLC for IOAM Flags and Direct Exports xiao.min2
- Re: [ippm] WGLC for IOAM Flags Greg Mirsky
- Re: [ippm] WGLC for IOAM Direct Exports Greg Mirsky
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Tommy Pauly
- Re: [ippm] WGLC for IOAM Direct Exports Tal Mizrahi
- Re: [ippm] WGLC for IOAM Flags Tal Mizrahi
- Re: [ippm] WGLC for IOAM Direct Exports Greg Mirsky
- Re: [ippm] WGLC for IOAM Flags and Direct Exports Jeff Tantsura
- Re: [ippm] WGLC for IOAM Direct Exports Tal Mizrahi
- Re: [ippm] WGLC for IOAM Flags Greg Mirsky
- Re: [ippm] WGLC for IOAM Direct Exports Greg Mirsky
- Re: [ippm] WGLC for IOAM Direct Exports Tal Mizrahi
- Re: [ippm] WGLC for IOAM Flags Tal Mizrahi
- Re: [ippm] WGLC for IOAM Flags Tal Mizrahi
- Re: [ippm] WGLC for IOAM Flags Greg Mirsky
- Re: [ippm] WGLC for IOAM Direct Exports Greg Mirsky