[ippm] Alvaro Retana's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)
Alvaro Retana via Datatracker <email@example.com> Tue, 23 March 2021 17:58 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E54753A0E1C; Tue, 23 Mar 2021 10:58:00 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Alvaro Retana via Datatracker <firstname.lastname@example.org>
To: "The IESG" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Al Morton <email@example.com>
Reply-To: Alvaro Retana <firstname.lastname@example.org>
Date: Tue, 23 Mar 2021 10:58:00 -0700
Subject: [ippm] Alvaro Retana's No Objection on draft-ietf-ippm-ioam-data-12: (with COMMENT)
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 17:58:01 -0000
Alvaro Retana has entered the following ballot position for draft-ietf-ippm-ioam-data-12: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have several significant issues to bring up. Individually, none of them raise to the point of a DISCUSS, so I'm balloting No Objection. (1) §5.3: "Any IOAM-Namespace MUST interpret the IOAM-Option-Types and associated IOAM-Data-Fields per the definition in this document." This sentence seems to not say much beyond requiring compliance with this document, which is obvious since this document is the one defining the IOAM-Namespaces. (2) §5.3: "IOAM-Namespace identifiers MUST be present and populated in all IOAM-Option-Types." What does "populated" mean? I assumed that it meant that the field has to have a value in it, but then I found out that the Default-Namespace-ID is 0x0000. This seems to mean that the receiver can't tell the difference between the sender forgetting to populate the field and the default. IOW, it seems to me that requiring that the field be populated doesn't serve a specific need and cannot be normatively enforced. (3) §5.3: Given the example, I don't think this statement is true: "...node identifiers might not be unique for other organizational reasons, such as after a merger of two formerly separated organizations), the combination of node_id and Namespace-ID will always be unique." It seems to me that for the same reason that merged organizations can end up with overlapping node_ids, they can also end up with overlapping Namespace-IDs. If not deployed in an overlapping way (on the same set of nodes), it seems that it may be ok to have the same Namespace-ID in multiple places. This deployment consideration should be better explained in this document. I took a quick look at draft-brockners-opsawg-ioam-deployment and this item is not covered there either. (4) I think that the encapsulation-independent pieces of draft-brockners-opsawg-ioam-deployment would be better placed in this document. (5) §5.4: "Any deployment MAY choose to configure and support one or both of the following options." This sentence looks like a statement of fact and not a normative statement. s/MAY/may (6) §5.4.1: "The Namespace-ID value of 0x0000 is defined as the "Default-Namespace-ID" (see Section 5.3) and MUST be known to all the nodes implementing IOAM." The second part ("MUST be known...") is not needed because this document is defining the default value... (7) §5.4.1: An IOAM encapsulating node MUST set NodeLen. A node receiving an IOAM Pre-allocated or Incremental Trace-Option relies on the NodeLen value, or it can ignore the NodeLen value and calculate the node length from the IOAM-Trace-Type bits (see below). Assuming that the NodeLen is not 0 (i.e. set), when can the receiver ignore it? If NodeLen is 0 (not set), what should the receiver do? The text above requires NodeLen to be set, but then it makes its use optional. (8) §5.4.1: "RemainingLen: ...the sender MAY set the initial value of RemainingLen according to the number of node data bytes allowed before exceeding the MTU. ... When node data is added, the node MUST decrease RemainingLen by the amount of data added." This text includes a normative inconsistency. If the sender doesn't initialize the "value of RemainingLen according to the number of node data bytes allowed" (because it is optional!), and the transit node does "decrease RemainingLen by the amount of data added" (because it is required), then the value won't reflect the data space remaining and a downstream node may add enough bits to overflow -- or not add anything because it considered the overflow imminent. (9) §5.4.1: "If RemainingLen in a pre-allocated trace option exceeds the length of the option, as specified in the preceding header, then the node MUST NOT add any fields." I didn't find "the length of the option" defined anywhere. Did I miss it? (10) §5.4.1: Bit 12-21 Undefined. An IOAM encapsulating node MUST set the value of each of these bits to 0. If an IOAM transit node receives a packet with one or more of these bits set to 1, it MUST either: 1. Add corresponding node data filled with the reserved value 0xFFFFFFFF, after the node data fields for the IOAM-Trace-Type bits defined above, such that the total node data added by this node in units of 4-octets is equal to NodeLen, or This first option assumes that all undefined data fields will be 4-octets long. But if future data fields are defined to be 8-octets (and the transit node doesn't understand them) then 0xFFFFFFFF won't be enough and there will be a misalignment. IOW, I don't think it is possible to require this behavior -- unless it is also required that all future data fields have to be 4-octets long. (11) Some of the values to be included in the data fields (§5.4.*) are not well defined and could result in nodes reporting inconsistent measurements. Specifically, transit delay and queue depth. It would be ideal if the document provided some guidance for the implementation/use. (12) §8.7: "Upon a new allocation request, the responsible AD will appoint a designated expert, who will review the allocation request." This sentence is not needed: the assignment happens only once and not when whenever "a new allocation request" comes up.
- [ippm] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana via Datatracker