[Last-Call] Intdir telechat review of draft-ietf-ippm-ioam-flags-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Pascal Thubert
Review result: Ready with Nits

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.



-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux