Re: [ippm] WG Last Call for draft-ietf-ippm-ioam-ipv6-options

Mark Smith <> Thu, 30 December 2021 01:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44BC73A0800; Wed, 29 Dec 2021 17:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.038
X-Spam-Status: No, score=-1.038 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.559, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6rhEBaXOTZq7; Wed, 29 Dec 2021 17:26:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B754D3A07FD; Wed, 29 Dec 2021 17:26:55 -0800 (PST)
Received: by with SMTP id y16so17793619ilq.8; Wed, 29 Dec 2021 17:26:55 -0800 (PST)
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:content-transfer-encoding; bh=eiQA68y46th0+k4+JQyhuPJE0dn+xOppYjbYUI3T4zM=; b=pRnDV6otKVMHOZljxCy5M6w9AzzHyWozrCBRGP2nlCm93rCDRhUQGHRPuhhiDfddDs 3tDgohFueqMRI7Y666W/jGMsX0AniUyRRypHMpM7N0U3nKp0oZVYL7/JvdPO49Sv3QNF QZ87cOSZx5MDB4w1abXzfOgyGAEbM/vlAYfR0qhYcFMHA7XnGR59TBbwMd6IBU41FZ7o Z70bvh6W+crN0msOS3SrQWBRb5JvIR978oZveaBYmBO7gmYCg8COfmmosd0067GEhvh7 65inQI1ZMLoYDNYSskJ7BrmFFS4AbXgpfNSR8icULAhQjuFal3xMcTUCT3V6W8B3ciSK nnhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eiQA68y46th0+k4+JQyhuPJE0dn+xOppYjbYUI3T4zM=; b=Q/ROySA3WPfjmt/ElRpJJmXJG9bUOuFIP5vNd9EptbwVcw7ThmbwlM1GVh4wFnGeZq HyVDcySzqZSS/LkM4aK0pBCiLGBZWCMaMDVfufSBlZMup753TW51X5EK/Zh76Kh66W3S FuU41ztYmhfQ9tS9g9MzwY/98WuZM987jYMoF9X4YJo68CIjlOkwOhclclew/o5ZOF23 ebzvjJXrU0WCUBVr20gaJAZEkS19zr6jSCuarYhx7V9d9VUVACZym79cyNeWUqQAmfiQ oDKg2bZOdRhJWsL8nltBSlFRM2ZNxF/Rgj5M1KpBFH6kiro5n0wN4auTm1pqvpEO5QcZ xX+Q==
X-Gm-Message-State: AOAM531845EVDPU7J7BdJdY6pwjMPBziozmALxnLCLvVBhOspc+YUZiN Ia3xxZRk3wNbxar+O9vSs6U3VA5ejJgWvKmQL14=
X-Google-Smtp-Source: ABdhPJz+XHvC5FAFsIJaRvOJ85gLqHA8i2mc5WNE6NyBSHm3UbH2LpgPPIC2qKuYBjHHKSVQqC4G12iZnJBzOsTSizU=
X-Received: by 2002:a92:8747:: with SMTP id d7mr12796852ilm.203.1640827613523; Wed, 29 Dec 2021 17:26:53 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Thu, 30 Dec 2021 12:26:27 +1100
Message-ID: <>
To: Haoyu Song <>
Cc: Marcus Ihlar <>, "" <>, 6man <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [ippm] WG Last Call for draft-ietf-ippm-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, 30 Dec 2021 01:27:01 -0000

On Thu, 30 Dec 2021 at 08:30, Haoyu Song <> wrote:
> Hi IPPM and 6MAN,
> After reading the draft, I have one question. My understanding is that the proposed approach basically uses IP-in-IP encapsulation and encapsulates the IOAM option in the outer IPv6 header. While the in-band measurement is intended for the inner IPv6 packet, I’m concerned on how the requirement C1 can be met. For example, I’m not sure how the forwarding and ECMP can behave identically with and without the outer IPv6 header (i.e., for the overlay and underlay networks).

I think this is another example of where thinking IP-in-IP is
something special and different makes things confusing. "IP
tunnelling" is no more than a link-layer encapsulation. An "IP tunnel"
is a virtual layer 2 point-to-point link.

Original IPv6 packet forwarding through the IOAM domain would still
use information in the original packet (DA minimum, and whatever else
is considered for ECMP). The addition of the encapsulated updated IOAM
information and the outer IP header to get it to the next hop occurs
after that, as the packet goes down to the link-layer when link-layer
encapsulation occurs. IOAM conceptually occurs at "layer 2.5".

Since the IOAM domain is contiguous IPv6 nodes, meaning they're all
link-layer adjacent, imagine instead using bare Ethernet to carry the
IOAM information to the next IOAM hop, with the IOAM information added
when the original IPv6 packet is passed down for link-layer

Packet With IOAM:

[Ethernet] - [IOAM] - [original IPv6 packet A]

Packet Without IOAM:

[Ethernet] - [original IPv6 packet A]

Now substitute [Outer IPv6] for [Ethernet] above. Except, don't do
that often, it is far less confusing with "IP tunnels" if you imagine
the link-layer encapsulation format is a typical layer 2 frame
different from the original link-layer payload IPv6 packet.

(I've started to think using native Ethernet as above would be better
when possible for IOAM instead of IPv6-in-IPv6 -
draft-weis-ippm-ioam-eth-04 defines an Ethertype. IPv6-in-IPv6 could
be used when there is no native link-layer type field defined to carry
IOAM e.g. [Bluetooth]-[IPv6]-[IOAM]-[original IPv6 packet A]).


> Thanks,
> Haoyu
> From: ippm <> On Behalf Of Marcus Ihlar
> Sent: Friday, December 17, 2021 7:39 AM
> To:
> Subject: [ippm] WG Last Call for draft-ietf-ippm-ioam-ipv6-options
> Hello IPPM,
> This email starts a Working Group Last Call on draft-ietf-ippm-ioam-ipv6-options.
> Please provide feedback by replying to this email with your reviews and if you think this document is ready to progress, by Friday, January 14.
> Best Regards,
> Marcus & Tommy
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------