Re: [ippm] WGLC for IOAM Direct Exports

Greg Mirsky <> Tue, 07 September 2021 22:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A16A73A1AE1 for <>; Tue, 7 Sep 2021 15:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oAMy_ZK-Dbsj for <>; Tue, 7 Sep 2021 15:00:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 784B73A1ADC for <>; Tue, 7 Sep 2021 15:00:28 -0700 (PDT)
Received: by with SMTP id g21so11227edw.4 for <>; Tue, 07 Sep 2021 15:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Tue, 07 Sep 2021 15:00:15 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: "IETF IPPM WG (" <>
Content-Type: multipart/alternative; boundary="0000000000009bc57b05cb6ee4f3"
Archived-At: <>
Subject: Re: [ippm] WGLC for IOAM Direct Exports
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
   <>. 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.


On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly=> 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
> In-situ OAM Direct Exporting
> 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