[mpls] Rtgdir early review of draft-mb-mpls-ioam-dex-06

[Loa Andersson via Datatracker <[e-mail]>]

Reviewer: Loa Andersson
Review result: Has Issues

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: [e-mail];

   [e-mail];

   Cc:

   [e-mail];

   [e-mail];

   [e-mail];

   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