Subject: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-options-02

From: Tom Herbert <[email-masked]>
Date: Fri, 26 Jun 2020 07:49:29 -0700

Some comments from section #3

>From the draft: "In order for IOAM to work in IPv6 networks, IOAM MUST
be explicitly enabled per interface on every node within the IOAM
domain."

Why this requirement? What if the user wants to only measure a few
routers or perform an incremental deployment of IOAM. If they don't
follow this requirement then what breaks?

>From the draft: "Unless a particular interface is explicitly enabled
(i.e. explicitly configured) for IOAM, a router MUST drop packets
which contain extension headers carrying IOAM data-fields. This is the
default behavior and is independent of whether the Hop-by-Hop options
or Destination options are used to encode the IOAM data."

But later in the draft the option types are defined with ack bits as
zeroes. From RFC8200 this means: "00 - skip over this option and
continue processing the header.". So there's a contradiction here. If
a legacy router, one that doesn't implement IOAM, sees a packet with
the options it will skip the TLV and continue to process per the
requirements of RFC8200. Either the option type needs to use non-zero
act bits or the above requirement needs to be relaxed (I would prefer
changing the requirement to skip the option especially if HBH are
used).

>From the draft: "This ensures that IOAM data does not unintentionally
get forwarded outside the IOAM domain."

I don't think it does. Consider that a packet containing the IOAM
option in Destination Options arrives at a border router of the
domain. If the packet destination is outside the domain, the border
router will only process the Hop-by-Hop options and doesn't look at
the Destination Options so the IOAM will leak. This would also assume
that all border routers either support IOAM or drop packet which as
shown above isn't met but the current requirements of the draft.

Leakage prevention of protocols out of a domain is a common issue. It
is in the realm of firewalls, not the individual protocols to best
support that. Please look at section RFC8754 which describes the
necessary filtering of SRH packets to contain them within a segment
routing domain.

Tom