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

[Mark Smith <[e-mail]>]

Hi,

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.

Regards,
Mark.