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

Mark Smith <> Wed, 29 December 2021 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D19933A08C2; Wed, 29 Dec 2021 11:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.039
X-Spam-Status: No, score=-1.039 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] 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 Z595f0JAGofQ; Wed, 29 Dec 2021 11:14:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D37163A08C0; Wed, 29 Dec 2021 11:14:51 -0800 (PST)
Received: by with SMTP id s6so18230186ioj.0; Wed, 29 Dec 2021 11:14:51 -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; bh=wgGgIv5mjbXoMtAxcEFAYMTXczi1WDCa+dXwtw5lB4Q=; b=ebZXHhRZW7yPOvxURVp5+s5O28WLKJV/PGyNbdgLNtRCHN5n9a0+sdO9xFK4O2yHYu 1s8eagArcowxXtEujw2sAsBXZzLGjUKWS+/ZkukOUJ2UuI5LCpaKQXT4q1vmHytVt8JT NjCzvJT+oLzQnKbrlyDyvJlxGrYOwO+H2D1fmb2iHOPoLYCVGLU0/rAEUEt1gQ0k24xz tUmCIlt8ml2XsYlj4vXwu58uv9F61PoscSigkKlrvQd/hYGTjczVSfyIXGWzOgjzD/qR Sw4y3W/Bfa10lWQR/dSmxEO//hQBAj1N0yMyzIP2sCk53JaniVP1Scc7TzBXUJXhAG8A iHZA==
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; bh=wgGgIv5mjbXoMtAxcEFAYMTXczi1WDCa+dXwtw5lB4Q=; b=G4BvpwVSw1eVxXYYuMwLDR2Xc3Oy2dJq2S5HuKLVxIG951LTpACoM01kjfKlFhqz+3 0QEuDXsyKH7qB1RV8flgUqa6kts1G/h5JFHVxp6xRp+/lwFWM0WIg5IfWDMI614iihVn z8vF45NyTBUrokY1siT9ygpnRQf9VQaDxjFIvVrsLvf1izWRPg67chaVSFLn8+3q+1cC EcaQYxxjCFzrWasJmBy6vcHI/ahx2wkJ/jQtMaPrQ2OVm+t2sch7qSTfiCUkPCR5LaWS SNkoCqL0OasNCtNZnU9Z7rcs265W3aWi0o/Tl5PX1yRxjdaQRniSKNrn/C4YQjECXzSY 1+vQ==
X-Gm-Message-State: AOAM532Qcp41EEtJ/EAD3C2R54ufRFnIGfRwV6t48gfHQF+wO7uJGYBO 5RGnNBPF4aWGrFyrSXYzOBfccjTaczecdF64Nco=
X-Google-Smtp-Source: ABdhPJxpmGFJZMqbO2ARtm3zSkpH2d38/rMtWkA79viwGOW1WbdMvts2cnpIFlRrqmWS3nQqWDQjZHxNY5mQNrHr6k0=
X-Received: by 2002:a05:6638:3391:: with SMTP id h17mr12390200jav.188.1640805289725; Wed, 29 Dec 2021 11:14:49 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Thu, 30 Dec 2021 06:14:23 +1100
Message-ID: <>
To: Erik Kline <>
Cc: IPv6 List <>, Marcus Ihlar <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 29 Dec 2021 19:14:53 -0000


Hmm, not sure how I missed this, I thought I was subscribed to the IOAM ML.

I've been thinking for a while that there might be an opportunity to
simplify IOAM over IPv6 significantly, based on the following:

- that the IOAM domain is contiguous, which I think is really saying
that all IOAM nodes in the IOAM paths/IOAM domain are directly
adjacent at layer 2, meaning directly connected to each other via
layer 2 links (or tunnels, which are virtual layer 2 links.)

- IOAM over IPv6 IOAM nodes are RFC8200 IPv6 Nodes.

- per RFC4291, all IPv6 enabled interfaces on IPv6 nodes are required
to have Link-Local addresses.

Since the IOAM domain is a contiguous path of IPv6 nodes, it means
that the DA of the outer IOAM encapsulation IPv6 packet could be the
next node's IPv6 Link-Local Address. For each IOAM node (IPv6
router/host) these LLAs would be the same LLAs as the next hop router
used by routes/routing protocols e.g. OSPF route next hop LLAs or
default router LLAs advertised to hosts via RAs.

This idea is really just a simpler version of the IPv6-in-IPv6 using
ULA method described. The ULA addressing was partly necessary to skip
past/over non-IOAM enabled nodes within an IOAM domain, and was a way
to prevent or mitigate the effects of IOAM encapsulated packets
leaking. Using LLAs for IOAM encap DAs solves that problem too, and is
also simpler because there is no need to deploy a ULA address space.
The automatic LLAs can be used instead.

That being said, I've also wondered about a "donut" IOAM deployment
model. IOAM processing is performed at a contiguous IOAM edge of the
network (e.g. IOAM enabled access, distribution layers) using LLAs.
IOAM is not normally performed in the core of the network for
performance reasons, and ULA addressing is used for the encapsulation
DAs to send those IOAM packets from one side of the network core
"donut hole" to the other.