Re: [ippm] Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options

Greg Mirsky <> Thu, 19 September 2019 18:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 528D012080B; Thu, 19 Sep 2019 11:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Ze1q6IHjo1k; Thu, 19 Sep 2019 11:56:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38545120289; Thu, 19 Sep 2019 11:56:01 -0700 (PDT)
Received: by with SMTP id l21so4696395lje.4; Thu, 19 Sep 2019 11:56:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pbBbnvV82nG12RkD2so/6oQa2sHqmUhaUQWs0Pa5kP0=; b=cllmvxorb16pk0kAqEQ4NLuavzNndOyZytx8VSNtH2PyvXeEnytFvCo5NnHk1PUFDZ az50dvnJ0AFIiL4Wnxe7rivyeczhrirQEYn2AVGP6HkjbXf4gNNq2n+d9X1BVpXQPWlQ AUIIFePAzl3Cv43zOi29bLutZ03AiTov0Lz3m7kQovGudhuxxI2zomuxUf9tYNKRfnyp sIhSzfeWkbpmYd31beHyjhJuvPtUMgsN3E4IzBSwe29NfxafXUzG2D3b6puNhnLqBIFW qDirBxW+vI/2AE1Ipb5jL2oUpNjYZefIFtkQe/55FvgpUBFq7mzU42U3f2BQGe6KNNiD 0GBA==
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=pbBbnvV82nG12RkD2so/6oQa2sHqmUhaUQWs0Pa5kP0=; b=jEyawlmVqTXaemHvCb0fACEcxBSg0YCb1ysZg4fK+yOyaPYPYSPTa70pLojF0A2oAV HXFca2c5o32En9EoCk92iNI4dn9e3F352qy5WBVVN8ZI6Uys2jYOmFeUCGI9qO/LL5eG 9k85Zafa1KRzxkyMgV/bSn26js4kZmJODYVNpZbV/J2tPWsYytJoX9kEimRebkVPka63 atLOhrelohbXhKo7v0Eo5h13EnEUBvhGwDQ+C/+9GGMOdYnth78E8ESytNMb5DWE5BBP XLxZI0aui5wMe6hcZaYIxwJ48dRfoPxmSXDRa6GWIwNy1CNSi891xMHj9Uw+fssVj9Eq H8GQ==
X-Gm-Message-State: APjAAAXDsnFs+iN9xsCLaEYUjPsapFvvfYZ89Yv9lGrdLzTGb/xw4hlY QDv9pe4ylSD2E7UNyU6IQa1OxGeRcttz9wxK6rkQ9nso
X-Google-Smtp-Source: APXvYqzmdb8IS+2Nkk3kcuYVRERIbGo/VlfR31dgBSs4E3UjFAVaEDEgCZSdQD0w5lwlQaqmVmw5e7uoKWU3SY/HIXg=
X-Received: by 2002:a2e:8054:: with SMTP id p20mr6387087ljg.36.1568919359286; Thu, 19 Sep 2019 11:55:59 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 19 Sep 2019 11:55:47 -0700
Message-ID: <>
To: Tommy Pauly <>
Cc: IETF IPPM WG <>,, 6man WG <>, Mirja Kuehlewind <>
Content-Type: multipart/alternative; boundary="00000000000017716c0592ec814f"
Archived-At: <>
Subject: Re: [ippm] Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options
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: Thu, 19 Sep 2019 18:56:05 -0000

Dear Authors, et al.,
I have a number of questions on this draft and hope you'll find time to
clarify some aspects of iOAM encapsulation in IPv6 EHs:

   - format of both Hop-by-Hop Options header and Destination Options
   header, as defined in RFC 8200, allow the length of Options field in the
   header to be no more than 2K - 2 octets. I consider that to be an important
   limitation of the proposed encapsulation method but I don't find that being
   discussed in the document.
   - Section 3 of your draft defines iOAM Option encapsulation format. How
   this encapsulation relates to the encapsulation of IPv6 options for the
   Hop-by-Hop Options header and Destination Options header?
   - Section 4.2 in RFC 8200 defines four types of actions to be associated
   with the option. Which of these and in what scenarios may be used to carry
   iOAM information in IPv6 packet?
   - Also, in Section 4.2 defined on-bit long flag in the Option Type field
   to indicate whether option data may change en route. How this flag will be
   used when iOAM option data encapsulated in IPv6 EHs?
   - Further, the question of choosing a padding option - Pad1 or PadN?
   Which these two to be used for iOAM data in IPv6 EHs?

With this number of technical issues being underspecified, I don't support
the adoption of the draft by IPPM WG. And I feel that it would be more
appropriate to ask 6man WG to host this work.


On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <tpauly=> wrote:

> Hello IPPM,
> This email starts a working group adoption call for
> draft-ioametal-ippm-6man-ioam-ipv6-options. This document defines the IPv6
> option encapsulation for IOAM data. This document was discussed with the
> 6man WG, which advised that the work be done in ippm, with review by 6man.
> The documents are available here:
> Please reply to this email by Wednesday, September 25, with your input on
> whether or not the WG should adopt this document.
> Best,
> Tommy (as IPPM co-chair)
> _______________________________________________
> ippm mailing list