Telechat Review of draft-ietf-ippm-ioam-flags-09
review-ietf-ippm-ioam-flags-09-intdir-telechat-thubert-2022-06-28-00

Request Review of draft-ietf-ippm-ioam-flags
Requested revision No specific revision (document currently at 10)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2022-06-26
Requested 2022-06-21
Requested by Éric Vyncke
Authors Tal Mizrahi , Frank Brockners , Shwetha Bhandari , Barak Gafni , Mickey Spiegel
I-D last updated 2022-06-28
Completed reviews Secdir Early review of -06 by Donald E. Eastlake 3rd (diff)
Tsvart Early review of -06 by Dr. Bernard D. Aboba (diff)
Genart Last Call review of -08 by Paul Kyzivat (diff)
Secdir Last Call review of -08 by Donald E. Eastlake 3rd (diff)
Intdir Telechat review of -09 by Pascal Thubert (diff)
Assignment Reviewer Pascal Thubert
State Completed
Request Telechat review on draft-ietf-ippm-ioam-flags by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/dMFxK2jvA5MuC5oDNWjwp6EOcuM
Reviewed revision 09 (document currently at 10)
Result Ready w/nits
Completed 2022-06-28
review-ietf-ippm-ioam-flags-09-intdir-telechat-thubert-2022-06-28-00

I am an assigned INT directorate reviewer for <draft-foo.txt>. These comments
were written primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with any other
Last Call comments that have been received. For more details on the INT
Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

1.  Introduction

   IOAM [RFC9197] is used for monitoring traffic in the network by
   incorporating IOAM data fields into in-flight data packets.

Should we read that the data is manipulated in-flight? Then it's not just
incorporated...

                       If an encapsulating node receives a looped
   back packet that was not originated from the current encapsulating
   node, the packet is dropped.
Should we read "originated from self"?

   or sets the loopack
typo

            The copy is also truncated, i.e., any payload that
   resides after the IOAM option(s) is removed before transmitting the
   looped back packet back towards the encapsulating node.

IUs there enough info to correlate with the copied packet in case the
encapsulator keeps stats, e.g. packet size? Could the loopbakc copy carry
packets stats (again like size or time)

   The looped back data rate SHOULD NOT exceed 1/N of the interface
   capacity on any of the IOAM node's interfaces.  Using N>100 is
   RECOMMENDED.  Depending on the IOAM node's architecture
This is not really the same N as before. Why is it the same value?
I see that it makes sense to throttle at the encapsulation, but here this
should not be done beyond a self protection maesure wihc should not be
triggering in normal conditions. Because loosing loop back copies may cause the
encapsulator to think there is a problem when there is none.

   It is not intended as a replacement for existing
   active OAM protocols, which may run in higher layers and make use of
   the Active flag.
Sorry could you reformulate? Higher levels could not use that flag, that would
be a layer violation.