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

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

John Scudder has entered the following ballot position for
draft-ietf-ippm-ioam-conf-state-07: 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-conf-state/



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

### Clarity about scope of the document

As I understand it, this document isn't intended to be an implementable
protocol specification on its own; rather, "specification details for these
different echo request/reply protocols are outside the scope of this document".

If this approach is to be followed there are some changes needed. Below I
provide some suggested text -- please know that I'm just supplying this as a
straw man to illustrate my thinking; while you're welcome to use the text I've
provided, I don't necessarily expect that.

The Abstract says that "This document describes an extension to the echo
request/reply mechanisms". It does not. Here's an example of how it might be
changed to be clearer.

OLD:
   This document describes an extension to the echo request/reply
   mechanisms used in IPv6 (including Segment Routing with IPv6 data
   plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
   (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
   Replication (BIER) environments, which can be used within the In situ
   Operations, Administration, and Maintenance (IOAM) domain, allowing
   the IOAM encapsulating node to discover the enabled IOAM capabilities
   of each IOAM transit and IOAM decapsulating node.

NEW:
   There is a need to extend echo request/reply mechanisms used in IPv6
   (including Segment Routing with IPv6 data plane (SRv6)), MPLS
   (including Segment Routing with MPLS data plane (SR-MPLS)), Service
   Function Chain (SFC) and Bit Index Explicit Replication (BIER)
   environments, for use within the In situ Operations, Administration,
   and Maintenance (IOAM) domain, allowing the IOAM encapsulating node
   to discover the enabled IOAM capabilities of each IOAM transit and
   IOAM decapsulating node.

   Although this document does not itself specify the necessary
   extensions, it specifies formats and objects that can be used in such
   specifications, and provides guidelines and requirements for their
   development.

I think the Introduction also needs to be cleaned up. Saying that
"specification details... are outside the scope" undersells the scope of what's
needed. For example, maybe these changes would work in the Introduction:

OLD:
   This document describes an extension to the echo request/reply
   mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS),
   SFC and BIER environments, which can be used within the IOAM domain,
   allowing the IOAM encapsulating node to discover the enabled IOAM
   capabilities of each IOAM transit and IOAM decapsulating node.

NEW:
   This document specifies formats and objects that can be used in the
   extension of echo request/reply mechanisms used in IPv6 (including
   SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can
   be used within the IOAM domain, allowing the IOAM encapsulating node
   to discover the enabled IOAM capabilities of each IOAM transit and
   IOAM decapsulating node.

OLD:
   Note that specification details for these different echo request/
   reply protocols are outside the scope of this document.  It is
   expected that each such protocol extension would be specified by an
   RFC and jointly designed by the working group that develops or
   maintains the echo request/reply protocol and the IETF IP Performance
   Measurement (IPPM) Working Group.

NEW:
   It is expected that the specification of the instantiation of each of
   these extensions will be done in the form of an RFC jointly designed
   by the working group that develops or maintains the echo
   request/reply protocol and the IETF IP Performance Measurement (IPPM)
   Working Group.

### Clarity of formats

Because this document is specifying things (or trying to) in absence of any
concrete instantiation, it's difficult for me to evaluate if the formats as
specified are complete and unambiguous. For now I've left my detailed
discussion of this in my COMMENT section, and am optimistic that we can sort it
out. However, I'm putting a placeholder here in case that problem turns out to
be thornier than hoped.


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

# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @jgscudder

## COMMENTS

### Section 1

```
   Fate sharing is a common requirement for all kinds of active OAM
   packets, echo request is among them, in this document that means echo
   request is required to traverse a path of IOAM data packet.  This
   requirement can be achieved by, e.g., applying same explicit path or
   ECMP processing to both echo request and IOAM data packet.
```

Explicit path, yes, but it's known that you can't simply expect to "apply same
ECMP processing" to two quite distinct packets, without carefully arranging for
that to happen. If this is a requirement (and the paragraph says it is) then I
think it's necessary to be clearer about how it's to be achieved.

### Section 3.1, Default-Namespace-ID

```
               A list of IOAM Namespace-IDs (one or more Namespace-IDs)
   MUST be included in this container in the echo request, and if
   present, the Default-Namespace-ID 0x0000 MUST be placed at the
   begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
   node requests only the enabled IOAM capabilities that match one of
   the Namespace-IDs.  The Namespace-ID has the same definition as
   what's specified in Section 4.3 of [RFC9197].
```

- You specify that if present 0x0000 must be placed at the beginning of the
list. Is there any other sorting requirement on the list, or is that the only
mandated ordering?

- It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request
carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000
matches everything) or if it would elicit replies only for capabilities that
have no configured non-default namespace, or are explicitly configured with
namespace 0x0000. Can you either clarify this in the text, or if you think it's
clear from the reference, help me understand what makes it clear?

- If the first guess above is correct (0x0000 elicits replies for all
Namespace-IDs) then it would seem that if the list contains 0x0000, it's
pointless to include anything else in the list, and that might be worth
pointing out in the text.

- If the first guess above is correct, that would also prompt comments on the
use of Namespace-ID field in Sections 3.2.x, but we can address that if needed.

### Section 3.1, container format, padding

```
   The IOAM Capabilities Query Container has a container header that is
   used to identify the type and optionally length of the container
   payload, and the container payload (List of IOAM Namespace-IDs) is
   zero-padded to align to a 4-octet boundary.

   The length, structure, and definition of the IOAM Capabilities Query
   Container Header depends on the specific environment it is applied
   at.
```

I regret I'm not sufficiently familiar with all the different bearer protocols
you're envisioning embedding this container in. So I'll just ask,

- Why is the length of the payload said to be optional, when it's a (presumably
variable-length) list? Does this relate to a bearer protocol where the length
of the list is inferred some other way, or what?

- The specification that the payload is zero-padded to 4-octet alignment
carries some implications. Let's explore these with an example. Suppose we want
to signal a single Namespace-ID, 0x0001. Then presumably the payload has to be
0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed
to know that it ignores the 0x0000 value (which is otherwise the
Default-Namespace-ID) because it comes at the end of the list, not the
beginning as the previous paragraph required? If so, this seems worth calling
out. If not, how is the receiver supposed to know where payload ends and
padding begins?

### Section 3.2, container format, padding

Similar questions to those above apply to:

```
   The IOAM Capabilities Response Container has a container header that
   is used to identify the type and optionally length of the container
   payload, and the container payload (List of IOAM Capabilities
   Objects) is zero-padded to align to a 4-octet boundary.
```

That is, considering you've disclaimed defining specifics about the semantics
of the header, how is the recipient of one of these things supposed to know how
to ignore the zero-padding?

I do see that all the objects you've defined in this document are a multiple of
four bytes long (if we assume their unspecified headers are a multiple of four
byte long, that is!) so no padding would ever be required for a payload
consisting only of these objects, and thus my question wouldn't apply. But if
that's the answer to my question, then the final clause I quote above (about
zero-padding) should just be removed.

### Section 3.2, object format, padding

```
   Similar to the container, each object has an object header that is
   used to identify the type and length of the object payload, and the
   object payload is zero-padded to align to a 4-octet boundary.
```

Similar to the above, in some cases there will be a need to know how to
separate payload from padding. In all the objects you defined in Sections 3.2.x
this is unnecessary (*if* you assume the unspecified header is 4-octet aligned
itself) since you've carefully specified them so that they don't require
padding.

It might be more straightforward to just mandate that future object
specifications have a length that is a multiple of four octets, as all of your
current ones do. That defers the question of what to do about variable payloads
to the specification of the -- notional? -- object that has such a payload.

### Section 4

You talk about TTL in the first paragraph. Do you mean "TTL or Hop Limit"?

### Section 6, integrity protection

You talk about integrity protection in passing. Let's assume a deployment
hasn't enabled any kind of integrity protection. Have you done any analysis of
what kind of mischief an attacker could cause by inserting incorrect
capabilities in a forged response?

### Section 6, MBZ fields

You suggest checking the must-be-zero reserved fields and reporting an
exception if they aren't zero. Often, such reserved fields are expected to be
extended in future, and indeed this is what you indicate in this spec too. I
guess since the packets terminate at the recipient of the reply, it's not
terribly harmful to police that these be zero, but it would likely create an
awfully noisy set of exceptions in the case of a partially rolled-out
extension. Is this really a good recommendation? The more usual practice is of
the form "must be zero on Tx, must be ignored on Rx".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments