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

Tom Herbert <> Tue, 24 September 2019 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04FEC12013D for <>; Tue, 24 Sep 2019 08:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 wnIGFzP-0APx for <>; Tue, 24 Sep 2019 08:55:19 -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 4CDF01200D6 for <>; Tue, 24 Sep 2019 08:55:19 -0700 (PDT)
Received: by with SMTP id a15so2315213edt.6 for <>; Tue, 24 Sep 2019 08:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e65DgOjjQx2YZBL6vSLr6MKbl/j8xS8shCd1niJGUS4=; b=lwhmPNJ4QLm29dQEFB8HUjiiwAU50eQtb3SWXY1YQ82T+rsJtK4nIrExIr3KmZmnkf KwM0Gdos0NOtAipzOg1eimYmIVstOMVg8TLxMkCj89dEbTY+yjFx34vsSskzb8eQzBLg SvjmPfleFgIwQc+AatyicnpHmSTE5VllBxELDmiC0154JPXk/T3H4KIZ60oqSOvt8sTx 7hhpe6FDmMiiPaxy09h86upA75BOQ40lc2010jj7EbGZgvglC7/gZCSEXunyNElbG8lf WdfGPun+WUofGS+uh5Peo2V1ZmZHMvrePflsPym0krdTG2joAZTaikLRzUu86gn+jlxd 0N4g==
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:content-transfer-encoding; bh=e65DgOjjQx2YZBL6vSLr6MKbl/j8xS8shCd1niJGUS4=; b=NWPH/r8WETTxpOf40xbqBOhbef5vD526TKu32AiFpLDxNLFTrWLNyFbhYTH69OMnkz NYtzp0rPEDomKRisE51coT+mI38XsdAUmqM11USmbusAMZSE17oGy3zex8hSu3yUfGF9 g+ODRK9KUe5iBebZKNhB/SOREoseN78ABxbwwrYSjamnV6WPBIJSpBiF5r9aev3AxCQP S5FmC4W2lZr1Aj2ioNn8fK16zZkrTjccrAffuxkvEHXWgObn4lmTpXWQJBfQCYDNNRAh kQXW8DyLtJKu8lJTMn0brQ2ibl1pIghtapBViMf0AnVTlpz5HpZzBslmY8G99tdxu7kZ i8zA==
X-Gm-Message-State: APjAAAW4zYHXJbk3mr2FB42VK2wjIzTuma1U1iSANjnUzwmbIxC4XQ+S 9OgB2eCo+j1eB6YqgnavRv6lLDGLZ79ZbnEqvywFuA==
X-Google-Smtp-Source: APXvYqzYMZCQWSC1N/uZRKZy5WkjL4DpS6otY2ik6keQOgtmT33SR3vL1vF8fKToAQxBhqF+qtke6B0491i+ZIfsmmg=
X-Received: by 2002:a17:906:5295:: with SMTP id c21mr3132702ejm.80.1569340517682; Tue, 24 Sep 2019 08:55:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 24 Sep 2019 08:55:06 -0700
Message-ID: <>
To: Greg Mirsky <>
Cc: Tommy Pauly <>, Mirja Kuehlewind <>,, 6man WG <>, IETF IPPM WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 24 Sep 2019 15:55:22 -0000

I support this draft for WG adoption. We implemented the option at
hackathon #104 as reported to the WG.

Some replies to Greg points below.

On Thu, Sep 19, 2019 at 11:56 AM Greg Mirsky <> wrote:
> 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.

What is the use case for having IOAM data consuming more than 2K bytes?

> 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 3 describes an option format for IOAM data using canonical
format HBH and DO options. The first two bytes of Option Type and
Option Data Len are straight out of RFC8200.

> 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?

Section 5 shows shows the act bits in requested IANA assignment to be
00, per RFC8200 "00 - skip over this option and continue processing
the header.". That is appropriate for IOAM.

> 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?

It's used the same way as in other options. If the chg bit is set in
the option then the Option data can change in flight, if it's not set
then the data can't change. I suspect most use cases for IOAM will use
the modifiable option.

> Further, the question of choosing a padding option - Pad1 or PadN? Which these two to be used for iOAM data in IPv6 EHs?
Either can be used. The type of option padding is orthogonal to any
particular option. RFC8504 describes limits on option padding that
might be applied, but these are generic and don't need to be mentioned
in this draft.

> 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.

I don't believe it's necessary for this to be in 6man. Definition a
new IPv6 option that is compliant with RFC8200 is pretty


> Regards,
> Greg
> On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <> 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------