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

Greg Mirsky <gregimirsky@gmail.com> Tue, 25 June 2024 02:15 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4957C14F6FF; Mon, 24 Jun 2024 19:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRhGyph-H3NL; Mon, 24 Jun 2024 19:15:50 -0700 (PDT)
Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C36C14F6B7; Mon, 24 Jun 2024 19:15:46 -0700 (PDT)
Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-643efaf0786so18160047b3.1; Mon, 24 Jun 2024 19:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719281746; x=1719886546; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hWkBsUjuYb8OYDknGVoU+iXz9ZVZzN4bjSqk4Ur5F4g=; b=JfU9floynSxC3EjKLxgJF7AJXLrNeHzkkx0oh5kKPypJ27ZjdxBVHoQFrx54JAR+Vl 1gzducB39Q4GeyK2TwBDDAyO3Pl/NWdTw8USsEbU+G8zX2UjaDOh9KkRrjrHbbwLX4or b8xWGyG3mgPExExDLKE7jL28TnsSqJLuB/GE3LCoMnHUNGdoqVERiu/Ex9+4ipRXj/bN C32XRSS85a81VSZ9lEnpmBAIJsJz5HINclpVSdmxnpMX+YJJaaLuFEk0aCJtsms/38zw aAvQO7j42D4P0IlkxYB/ehh7tbgot5xqxUFe5YFtWPJkmGTQCRhxPjtu6q/Xtrq6tzu1 2ofQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719281746; x=1719886546; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hWkBsUjuYb8OYDknGVoU+iXz9ZVZzN4bjSqk4Ur5F4g=; b=d0Pu0OIwttyZygDqQWBRhT1wQ5rLWiAsTLkm47zyWAf7HDeWfYFuXQGZ+VLieZM3br SoAjCdRoutkJCCjI5z9/LHxVfX27spZk9jumxyTJ8HKuIaWv8nTW/smOL/Rp+6qeqWzM 5ouBTieE66K9l3HuhCWxZ9X8/7q/p8X1ryvgWr4JDN9ndNkiS4VOSipJoWBU+R74Au0y HWnjHcUpA6ZaXkMayVRfUxE++he+5ktucNIcVpwzpSyYzCubF2RHQCeyLS5oITUyF4Vz mGgZdnnxWPwjb0Ht3V0w/B74uiJM3aMKAtdu9K/6nJsUygF+FxK8Zxa6j0WXkBCcqK38 Myog==
X-Forwarded-Encrypted: i=1; AJvYcCVTo/UjYW4PkTaaS495vYjFj/oMWqLA7l+ajvev4/AaXC57v0HO5gAG/OMrmnX3Aek9AVpv6Ju7qzTGdosDmphTk3hOEUm+ZdaiGNfGXSMjtfKV79BkoE3ZkIlWOiXN/3OmFA==
X-Gm-Message-State: AOJu0YwewJdTkvbL3onobIYRbg+zEuNfdRADBLhlwXXHTUI4vvA5r+fe 5f6fHIovuum4DTtGJUg06qQffOc29mGFQ8Y+9D7pGuZiosztzU59ArLXs3r5oO+JfLcxNaSLwmr Jl5/LGYTX/9TgKlya/La6VsxFrhCo4mUQ
X-Google-Smtp-Source: AGHT+IEc0QMxNBDUKyzsXdSqwACY/sKNBw9jiUbAW9dD1GIzI/mssbq5ouCA6LjeFY0qZpU/OXmfKusIsqNr7N+lmHM=
X-Received: by 2002:a05:690c:60c5:b0:63b:ca6d:7bb8 with SMTP id 00721157ae682-6433eaf198cmr70720187b3.11.1719281745569; Mon, 24 Jun 2024 19:15:45 -0700 (PDT)
MIME-Version: 1.0
References: <171861391409.20105.6430464169391364016@ietfa.amsl.com>
In-Reply-To: <171861391409.20105.6430464169391364016@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 24 Jun 2024 19:15:33 -0700
Message-ID: <CA+RyBmXxCVUVzT0hBPep-RMxFgqZY-_CZ-M3X1SBPf0idGmpCA@mail.gmail.com>
To: Loa Andersson <loa@pi.nu>
Content-Type: multipart/mixed; boundary="000000000000b6eae4061bad7963"
Message-ID-Hash: V4E5YQQWPAINW7P5HHUJ6VC6UQADWVZ5
X-Message-ID-Hash: V4E5YQQWPAINW7P5HHUJ6VC6UQADWVZ5
X-MailFrom: gregimirsky@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: rtg-dir@ietf.org, draft-mb-mpls-ioam-dex.all@ietf.org, mpls@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Rtgdir early review of draft-mb-mpls-ioam-dex-06
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/QygeU9kaE2jNwXThJu3LAZS-fAU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Hi Loa,
many thanks for your thorough review and helpful comments. Please find my
notes below tagged GIM>>. Attached, please find the new working version and
diff that highlights the updates.

Regards,
Greg

On Mon, Jun 17, 2024 at 1:45 AM Loa Andersson via Datatracker <
noreply@ietf.org> wrote:

> 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: 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.
>
GIM>> AFAICS, your understanding is accurate and is well-aligned with the
IOAM-related discussions in the IPPM WG.

>
> 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".
>
GIM>> Updated accordingly, thank you.

>
>    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.
>
GIM>> I agree on both proposals.

>
> 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.
>
GIM>> Your point is valid. AFAIK, excessive number of packets carrying
operational state and telemetry information over the management plane may
cause a serious problem to efficient use of that information. That problem
can be mitigated by either aggregating information locally, on a transit
node or collecting that information using protocols like
draft-ietf-ippm-hybrid-two-step
<https://datatracker.ietf.org/doc/draft-ietf-ippm-hybrid-two-step/>
(temporarily
expired).

>
>    The MTU argument might be valid, but at least for pre-allocated this
>    should be under control.
>
GIM>> I think that and with the IOAM Incremental Trace Option-Type MTU can
be managed by limiting the number of nodes adding telemetry information
until the MTU limit is reached. AFAICS, that is how MTU concern is
mitigated in draft-filsfils-spring-path-tracing-srmpls
<https://datatracker.ietf.org/doc/draft-filsfils-spring-path-tracing-srmpls/>
.

>
> 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.
>
GIM>> Thank you for pointing this out and suggesting text to clarify the
decision-making process. I've added the following:
NEW TEXT:
   The IOAM-DEX in MNA header is
   using LSE Format D, as defined in Section 4.4 [I-D.ietf-mpls-mna-hdr]
   mapping IOAM-DEX Optin Type format [RFC9326].  In addition to the
   requirement to preserve the Bottom of Stack field, the most
   significant bit in LSE Format D is always set to 1 avoiding a
   possible mix-up of the LSE with one of the Base Special Purpose
   Labels.

>
>    *  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.
>
GIM>> Correct. Added the reference to the IOAM DEX Flags 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,
>
GIM>> I added the follwoing text to flag the difference between the lengths
of Ext.Flags in IOAM-DEX in MNA and Extension Fields in RFC 9326:
NEW TEXT:
      The length of the Ext-
      Flags field in IOAM-DEX Option-Type in MNA is shorter by two one-
      bit fields compared to the length of the Extension Flags field
      defined in Section 3.2 of [RFC9326].  Mapping of these two bit
      positins is for further study.

>
>    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.
>
GIM>> I agree that that must be explained in the draft. Added the following
text:
NEW TEXT:
      Although the length of the
      Sequence Number field in IOAM-DEX in MNA is 22 bit-long smaller
      than the 32-bit length allotted in [RFC9326], there is sufficient
      space before the rollover so that its value, in combination with
      the value of the Flow ID field, can be used to correlate the
      exported data generated by the same trigger packet carrying IOAM-
      DEX MNA.

>
>    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.
>
GIM>> AFAICS, that requirement is specific to IOAM-DEX format as defined in
RFC 9326. Reserved field is used in RFC 9326 to align optional fields at
four-octet word's boundary. That is not required in IOAM-DEX in MNA. I
added the following explanation:
NEW TEXT:

   *  Optional fields, i.e., Flow ID and Sequence Number, according to
      [RFC9326], immediately follow the Reserved field used to align
      optional fields at the four-octet word boundary.  In the case of
      IOAM-DEX in MNA, such alignment can be achieved without using
      padding.

>
>    *  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.
>
GIM>> Added the following text:
   *  The concatenation of IOAM-Trace-Type-MNA, O, and R fields,
      explained above, is identical to IOAM-Trace-Type in the
      interpretation of its bits, assigned in IANA's IOAM Trace-Type
      registry [IANA-IOAM-Trace-Type].  Also, note that the Bit 7 field,
      i.e., checksum complement, is handled as defined in [RFC9326].

>
>    *  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.
>
GIM>> After double checking RFC 9197 and the definition of Bit 23 in IOAM
Trace-Type registry, the concluded that the specification of using Extended
IOAM-Trace-Type was intentionally left for the future study and discussion.
As the result, removed LSE Format D containing Extended IOAM-Trace-Type-MNA
field altogether.

>
>    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.
>
GIM>> As it is removed in the updated draft, we will learn from the
discussion in IPPM WG, when the question of extending IOAM-Trace-Type space
comes up.

>
>    *  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.
>
GIM>> thank you for your thorough and professional review, Loa. Much
appreciated.

>
> 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
>
GIM>> For this draft, RFC 9197 must be considered in combination with RFC
9326  <https://datatracker.ietf.org/doc/rfc9326/>

>
>         * IOAM records OAM information within the packet while the
>           packet traverses a particular network domain.
>
GIM>> As I understand it, IOAM encompaces different Option Types. Some,
like Preallocated Trace, Incremental Trace, and Proof-of-Transit, use the
trigger packet (either customer's or test probe) to collect and transport
operational state and telemetry information that reflects conditions as
experienced by that trigger packet. IOAM Direct Export (IOAM-DEX), doesn't
use the trigger packet to collect and transport OAM information.

>
>         * 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.
>
GIM>> It might be appropriate to bring these questions to the attention of
IPPM WG.

>
>
> 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".
>
GIM>> I think that the confusion could be caused by the reference. Perhaps
the following update makes it clearer:
OLD TEXT:
   MPLS Network Actions (MNA) techniques
   [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.
NEW TEXT:
   MPLS Network Actions (MNA) techniques, described in
   [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.
WDYT?

>
>    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.
>
GIM>> Agree, and that makes the proposed update as follows:
NEW TEXT:
   MPLS Network Actions (MNA) techniques, described in
   [I-D.ietf-mpls-mna-fwk], indicate actions to be performed on any
   combination of Label Switched Paths (LSPs), MPLS packets, LSR,
   and also allow for the transfer of data needed for these actions.


> Page 3 "2.1 Acronyms"
> ---------------------
>
>    Title s/Acronyms/Abbreviations
>
>    In the abbreviation list
>    s/LSE: Label Stack Element/LSE: Label Stack Entry
>
GIM>> Thank you!