Background ========== This review is done as [I-D.mb-mpls-ioam-dex] is prepared for the Working Ground Adoption Poll (WGAP).) RTG-DIR Early review draft-mb-mpls-ioam-dex =========================================== To: mpls-wg-chairs@ietf.org; draft-mb-mpls-ioam-dex.all@ietf.org; Cc: rtg-dir@ietf.org; mpls@ietf.org; loa@pi.nu; Subject: RtgDir Early review: draft-mb-mpls-ioam-dex.txt Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-draft-mb-mpls- ioam-dex/ (https://datatracker.ietf.org/doc/draft-draft-mb-mpls-ioam- dex/) The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. This review is done as [I-D.mb-mpls-ioam-dex] is prepared for the Working Ground Adoption Poll (WGAP).) For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir (https://wiki.ietf.org/en/group/rtg/RtgDir) Document: draft-mb-mpls-ioam-dex-06.txt Reviewer: Loa Andersson Review Date: 2024-06 Intended Status: copy-from-I-D Summary ======= I think this technology is useful and should be adapted to be used in MPLS Networks featuring MNA. The document is well written and easy to read. That said I have comments and questions on this draft. However they are not blocking for working group adoption, all of them could be addresed as the working groups takes over the revision control. Comments ======== Example on how direct export may be used ---------------------------------------- I'm an expert of OAM, IOAM or DEX, so it has taken me long time to get through the document and the background information I needed. My apologies for that. The review is also a bit "wordy" but I hope it may be useful anyway. This is how I think about DEX. This draft builds on RFC 9326 [RFC9326] that defines the direct export (DEX) technology as an alternative to the IOAM types (Pre-allocated, Incremental, and Edge-to-Edge) defined in RFC 9197 [RFC9197]. In the RFC 9197 IOAM Option types use user packets to collect and transport the operational state and telemetry information. In the "Direct Export technology" each node generates a message carrying the operational state and telemetry information that is sent directly to the node that will process this information. My take is that "the processing node" may the LSP LER or a management node, but this is not discussed in the draft. High level view --------------- On a slightly higher level one could say that the IOAM actions for each LSR may be controlled policies. The implications of "controlled by policies" should be better described in the document. This document adapt the "Direct Export technology" from RFC 9326 [RFC9326] to MPLS networks. There are some differencies on how the IOAM-DEX Format is defined in RFC 9326 and in this document (see below). Title ----- The document titel is "Supporting In-Situ OAM Direct Export Using MPLS Network Actions". OAM is not marked as well-known in the RFC Editors abbreviation list: https://www.rfc-editor.org/materials/abbrev.expansion.txt and has to be expanded. The title should be "Supporting In-Situ Operations, Administration and Maintenance Direct Export Using MPLS Network Actions". Note: We have tried to ask our ADs to request that at least the abbreviation OAM for Operation, Administration, and Maintenance are made well-known. Personally I'd also like to see IOAM be made well- known. Applicability of IOAM Option Types in an MPLS Network ----------------------------------------------------- In the first paragraph of this section the document says: "In some environments, for example, data center networks, this technique is useful as the available bandwidth and the use of jumbo frames can accommodate the increase of the packet payload. But for other use cases in which network resources are closely controlled, the use of in-band channels for collecting and transporting the telemetry information may noticeably decrease the cost-efficiency of network operations." It might be true that in a network with closely controlled resources, degraded services might be caused by excessive OAM traffic. However, I don't see that IOAM direct export save e.g. bandwidth, the amount of data an LSR sends is the same, regardless of how many messages it is sent in, it might even be that multiple messages somewhat increases the consumed bandwidth. The MTU argument might be valid, but at least for pre-allocated this should be under control. IOAM-DEX Format for an MPLS Network ----------------------------------- In RFC 9326 the IOAM-DEX Format looks like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace-ID | Flags |Extension-Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this document it looks like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Namespace-ID | Resv |S| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| IOAM-Trace-Type-MNA |S|O|R| Ext-Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~1| Extended IOAM-Trace-Type-MNA (Optional) |S| Resv ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Flow ID MNA (Optional) |S| Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Sequence Number MNA (Optional) |S| Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The document does not motivate the changes done to the IOAM-DEX format between RFC 9326 and [I-D.mb-mpls-ioam-dex]. Comparing the IOAM-DEX Format in RFC 9326 and draftmb-mpls-ioam-dex ------------------------------------------------------------------- * Namespace-ID A 16 bit field in the IOAM-DEX format in both documents. -- In the RFC 9326 it is placed as bit 0-15 -- In the mpls-iom-dex it is placed bit 1-16. The reason for not starting it in the bit 0, is that since this goes in Format D ISD LSEs bit 0 is set to avoid possible mix up with a bSPL. * flags There are no indication what the flags are used for in either document. -- in RFC 9326 the flags are placed as bit 16-23 in the first 4 octet word -- in mpls-iom-dex the flags are placed in bit 24-31 in the first format D LSE. Bit 17-22 are reserved. A registry for the "IOAM DEX Flags" is created by RFC 9326, since mpls-ioam-dex does not create a registry I assume the the mpls-ioam-dex will use the flags assigned in the RFC 9326 registry. * extension flags The extension-flags are used to indicate the presence of optional 4-octet fields. In RFC 9326 the extension-flag is defined to be an 8 bit field, and in mpls-ioam-dex field is 6-bits. Since RFC 9326 defines the only registry, there must be some type of mapping between the 8-bit and 6-bit fields, There are two optional fields currently defined o Flow ID o Sequence Number The optional fields in RFC 9326 are 32 bit bits. In mpls-ioam-dex they are 22-bits. There is no motivation for this difference. I think it weould be relevant to have an explanation why the sequence number is "only" 22-bits in mpls-ioam-dex. RFC 9326 says that that the optional fields, if present, reside after the "Reserved field". Since there are more than one reserved field in mpls-ioam-dex, this might be ambigious. Please clarify. * IOAM-Trace-Type RFC 9326 says that the IOAM-Trace-Type is a 24 bit field and mpls- ioam-dex that is a 22-bit field. To my understanding mpls-ioam-dex is wrong, the IOAM-Trace-Type is a 24-bit field also in mpls-ioam-dex. In RFC 9326 the IOAM-Trace-Type is found in bit 0-23 of the second 4 octet word of IOAM-DEX format. In the mpls-oam-dex it is found in bit 1-22 and 24-25 of the 2nd Format D LSE of the IOAM-DEX format. RFC 9326 says that the bit that corresponds to the Checksum Complement (bit 7) is not relevant for DEX scenarios, and should be set to xero when sent and ignored on receipt. mpls-ioam-dex should make the same statement, and also identify which bit it is. * Extended IOAM-Trace-Type-MNA (Optional) In mpls-ioam-dex IOAM-Trace-Type-MNA is followed by optional Format D LSEs carrying a fields that are called "Extended IOAM-Trace-Type-MNA (Optional)". I can't find how it is determined if these optional are there or not, or how many of them that are there. It also need to clarified how to the extension-flags are used if one or more of the Extended IOAM-Trace-Type-MNA are present. This is relevant when it comes to understand how you find the starting point of the optional fields indicated by the extensioon-flags. * Summary "IOAM-DEX Format for an MPLS Network" It is fully possible carry the IOAM-DEX Format as ISD and make it work. It is just a bit "cludgy" and the fields is not nicely octet aligned. It would be much "cleaner" to carry the IOAM-DEX Format as PSD, we could just point to RFC 9326, and not spend time to map bits from one specification to the other. Software and hardware does not care much about the extra mapping, but it is an issue when designing. Some thoughts in DEX and In-situ OAM ------------------------------------ - RFC 9197 [RFC9197] is referenced and is the base IOAM document. RFC 9197 list some characteristics of In-Situ OAM * IOAM records OAM information within the packet while the packet traverses a particular network domain. * The term "in situ" refers to the fact that the OAM data is added to the data packets rather than being sent within packets specifically dedicated to OAM. * I don't think that mpls-ioam-dex is the right place to sort this out, just needed to document the questions above, possibly to be discuss somewhere else. Nits ==== idnits ------ Nits-tool finds no nits (sic)! The Introduction ---------------- The introdcution says (2nd paragraph from the end): [I-D.ietf-mpls-mna-fwk] indicate actions to be performed on any combination of Label Switched Paths (LSPs), MPLS packets, the node itself, and also allow for the transfer of data needed for these actions. There are two issues with with this sentence: First, "indicate actions to be performed" make expect a list of Network Action. There is no such list in the framework. Could we replace it with "indicates Netwiork Actions that may be performed". Second, "the node itself", this is high level language and as such correct. However, we are in MPLS-land, and all "nodes are LSRs". Note: We have the same use of "node" in the first paragraph of the Introduction, this should also be replaced by LSR. Note: I think the use of "node" in the Abstract is motivated. since there it is high level language. Page 3 "2.1 Acronyms" --------------------- Title s/Acronyms/Abbreviations In the abbreviation list s/LSE: Label Stack Element/LSE: Label Stack Entry