Re: [ippm] WGLC for IOAM Flags

[Greg Mirsky <[e-mail]>]

Dear Authors, WG Chairs, and All,
I've read the latest version of the draft and have several comments and
questions to share with you. I would much appreciate the opportunity to
discuss these before I can state my support for progressing this draft
to publication.

   - The Abstract states that:

   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in packets while they traverse
   a path between two points in the network.

I think that is not a complete description of IOAM options as it excludes
the Direct Export option. It might be easier to improve by
s/records/collects/. Also, what, in your opinion, is the distinction
between operational and telemetry information? I think that operational
information collected from remote nodes is one example of telemetry
information. What do you think?


   - nit s/the the/the/
   - I think that Abstract and Introduction can be improved by explaining
   the purpose of defining the Loopback and Active flags. What each of them is
   intended to achieve and improve?
   - It is stated in the Introduction that:

   This document defines
   two new flags in the Pre-allocated and Incremental Trace options: the
   Loopback and Active flags.
Does that mean that neither of the two flags is applicable in the Direct
Export option? Should draft-ietf-ippm-ioam-direct-export have an explicit
statement regarding the applicability of the Loopback and Active flags? And
if any is applicable, describe the behavior of an IOAM node receiving it.


   - In Section 4 the purpose of using the Loopback flag is explained as:

   Loopback allows an IOAM encapsulating node to trace the path to a
   given destination, and to receive per-hop data about both the forward
   and the return path.
In my previous comments, I've pointed out that the Loopback mode is just a
special case of the Direct Export option. In addition to that, I would
appreciate your explanation of how the IOAM encapsulating node receives
per-hop data about the return path. How does that work, for example, in an
MPLS or SFC NSH environment?


   - Further it Section 4, it is stated that:

   The two IOAM looped back copies are
   terminated by the encapsulating node.
But I don't see any technical explanation that could sustain that
assumption. As I understand the diagram in figure 1, a transit node doesn't
know the identity of the IOAM encapsulating node. Correct? If that is the
case, where does the transit node direct the looped packet?
It seems that the text in the last paragraph attempts to walk around my
questions. But I don't find that paragraph sufficient. It lacks the
normative language to guide a developer to produce resilient
implementation. For example, how to interpret:
   Loopback can be used only if a return path from transit nodes and
   destination nodes towards the source (encapsulating node) exists.
That reads like a recommendation, not a requirement. As a result, an
implementation may transmit an IOAM packet with the Loopback fag set
regardless of whether there's a return path or not. Then, how must a
transit node process such an IOAM packet?


   - A very concerning statement I've found in Section 4.1

   The encapsulating node either generates synthetic packets with an
   IOAM trace option that has the Loopback flag set ...
IOAM has been defined as a hybrid measurement protocol. This statement
implies that it is to be used as an active OAM protocol (all per RFC 7799
definitions). The requirements for active OAM protocols in terms of their
applicability and, most of, security are very different from those set for
a hybrid measurement protocol. I believe that extending IOAM into an active
mode of measurement requires more discussion and the audience from other
IETF WGs, e.g., 6man, SFC, BIER, MPLS, BFD, RTGWG.


   - The next statement explains the use case for the Loopback flag:

   Loopback is used
   either proactively or on-demand, i.e., when a failure is detected.
That is the same use of ICMP and LSP Ping. What is the benefit of using the
Loopback flag instead of readily available ICMP? Does it work as L2
Linktrace? I don't see that as a sufficient benefit considering the
complexity, exclusions, and risks associated and identified in the draft.
It is clear that there are tools like ICMP and LSP Ping that adequately
address scenarios listed in the draft. Don't see any technical reason for
the introduction of another mechanism that does not have any significant
benefit compared to the existing OAM tools. Especially, considering the
limited information that is allowed to be collected using the Loopback IOAM
flag ("every transit node that processes this trace option only adds a
single data field, which is the Hop_Lim and node_id data field"). With the
abundance of information and additional verification achieved using ICMP
and LSP Ping, there's even less rationale in the introduction of this
over-complex and unnatural mechanism.


   - The last paragraph states the requirement:

   IOAM encapsulating nodes MUST NOT push an IOAM encapsulation with the
   Loopback flag onto data packets that already include an IOAM
   encapsulation.
I couldn't find any guidance on how an IOAM node that receives such invalid
combination processes the packet.



   - It is assumed that the identity of the IOAM encapsulating node is
   known to the node that is expected to sent a copy of the received packet
   back. But what if that is not the case? How must that node act?
   - I believe that there's inconsistency between Figure 1 and the
   following text in Section 4.2

   Thus, the
   source address of the original packet is used as the destination
   address in the copied packet.
It seems that the text assumes that the IOAM encapsulating node adds also a
network layer encapsulation. But how would it work, for example, in SFC NSH
data plane? Or MPLS?


   - Section 4.4 states that

   If the Node ID matches the current
   IOAM node, it indicates that this is a looped back packet that was
   initiated by the current IOAM node, and processed accordingly.
But according to the definition of node_id in Section 5.4.2.1
of draft-ietf-ippm-ioam-data, "Node identifier field to uniquely identify a
node within the IOAM-Namespace and associated IOAM-Domain." It appears that
simply comparing Node IDs is not sufficient to verify that the node
received its looped back packet. What is your opinion?


   - If, as stated in Section 5,

   It [Active flag] is not intended as a replacement for existing
   active OAM protocols, which may run in higher layers and make use of
   the Active flag.
Then the question, What is the purpose of the Active flag? Existing active
protocols, Fault Management and Performance Monitoring, are identified by,
for example, use of a well-known destination port number or, in case of
MPLS, Generic Associated Channel type. There's no apparent need of using
IOAM option header to identify the payload as a control message of an
active OAM protocol. On the contrary, that would likely cause more
confusion and challenges to interoperation among different implementations.


   - Three cases analyzed in Section 5 require special consideration, as
   these likely present the motivation for the introduction of the Active flag:
      - the first use case is not really using the Active flag at all and
      thus the text doesn't seem adding any value to the draft;
      - it is not clear what is viewed as the benefit of using the Active
      flag compared with using any of the existing active OAM protocols in the
      second use case. I would appreciate it if you can clarify that for me.
      Since an SFC NSH network is used as an example, is it required that a
      Service Function (SF) or an SF Proxy process the IOAM header with Active
      flag set? Or would a Service Function Forwarder (SFF) avoid sending a
      packet with the IOAM header that has an Active flag set? And can you
      compare that with the procedures defined in the Active OAM for SFC
      draft
      <https://datatracker.ietf.org/doc/draft-ietf-sfc-multi-layer-oam/>?
      - My questions for the third use case described in Section 5 are the
      same as above because I don't see the benefit of using a replicated data
      packet (less benefits if it is truncated) compared to a special
test packet.
   - In my conclusion on the Active flag, I don't see any clear benefit of
   introducing it and using whether in place or in addition to the existing
   active OAM protocols.

I am looking forward to your feedback and the continued discussion.

Regards,
Greg

On Mon, Aug 30, 2021 at 1:58 PM Tommy Pauly <tpauly=
[e-mail]> wrote:

> Hello IPPM,
>
> This email starts a Working Group Last Call on two related IOAM
> documents, draft-ietf-ippm-ioam-flags
> and draft-ietf-ippm-ioam-direct-export.
>
> In-situ OAM Loopback and Active Flags
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-flags-06
>
> In-situ OAM Direct Exporting
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export-06
>
> Please provide feedback by replying to this email with your reviews and if
> you think these documents are ready to progress, by *Wednesday, September
> 15*.
>
> Best,
> Tommy & Ian
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>