[ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-flags-09: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-ippm-ioam-flags-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document. I have one issue I'd like to be sure we clear up.

1. In §4.1.1,

   The loopback flag MUST NOT be set if it is not guaranteed that there
   is a return path from each of the IOAM transit and IOAM decapsulating
   nodes,

This is heartwarming but I can’t see how you could guarantee this property at
all times in any network using dynamic routing or even subject to dynamic
conditions (and that would be all networks), and for that matter I’m not sure
how to write code to even determine this in any general way. Is it your
intention that this MUST NOT is directed to the operator and not to the code
implementor? Or perhaps is it for very small values of “guarantee”? That is, is
this an aspirational MUST and not a MUST MUST?

In general it's a little problematic when we use RFC 2119 keywords in a
protocol document, to express desires about how a protocol's operator should
deploy it. They are at their best when used to express requirements for how a
coder should implement the protocol. Please consider creating an operational
considerations section, and grouping operational requirements and advice there,
at least in that case it becomes clear to whom the RFC 2119 keywords are
speaking.

Alternately, please qualify the keywords appropriately in-line, e.g. in the
above text you could say something like

   The domain MUST be configured such that there is expected to be a return
   path from each of the IOAM transit and IOAM decapsulating nodes; if this
   expectation does not apply then configuration MUST NOT enable the loopback
   flag to be set,

To me it seems as though it might be less painful to group these into an
operational considerations section, but whatever works for you, as long as it's
clear.

I did a cursory check over the document with this in mind, the other place I
identified what looks like operational guidance to me is also in §4.1.1, the
paragraph about how you "SHOULD NOT exceed 1/N of the interface capacity". At
first blush that looks like something that could be computed automatically by
inspection of the router's hardware, but by the time we get to the end of the
paragraph we see that "prior knowledge about the network topology or size" is
needed, so it must really be operational guidance. (Possibly this applies to
the 1/N paragraphs in §4.2 and §5 also, although it's less clearly the case.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

2. The document cites RFCs 7014 and 5475 normatively. They don't seem normative
to me, they seem informative.

3. In §4.2,

                                              The L-bit MUST be cleared
   in the copy of the packet that a node sends back towards the source.

This makes me wonder, does the looped back packet inherit the IP TTL/hop limit
of the parent packet? The description of it as a “copy” makes me think it does.
Should this be explicit?

NITS:

4. In §5,

   This draft focuses on three possible use cases of active measurement

Should be "this document focuses".

5. Again in §5,

                                                              A selected
      data packet that is replicated, and its (possibly truncated) copy
      is forwarded with one or more IOAM options, while the original
      packet is forwarded normally, without IOAM options.

I think you need to delete the "that" from the first clause?

6. And once again in §5,

   o  IOAM active measurement using replicated data packets: probe
      packets are created by the encapsulating node by selecting some or
      all of the en route data packets and replicating them.

The 1/N requirement calls into question "or all" above, unless N=1, something
you strongly discourage. Although you don't technically *forbid* N=1, I think
the inclusion of "or all" creates confusion and you could and should leave it
out while still not technically forbidding N=1.

7. In §8,

                                                        The attacker can
      potentially leverage the Loopback flag for a Distributed Denial of
      Service (DDoS) attack, as multiple devices send looped-back copies
      of a packet to a single source.

The use of "source" is odd here. By the nature of an attack, the looped-back
copies wouldn't be targeted at the actual source of the packets. Possibly
"target" or even "victim"?