Hi Benoit, Thanks for the thorough review. We have posted an updated version that hopefully addresses your concerns.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/08/ Please see my responses below, marked [TM]. Please let us know if there are further comments. On Wed, Jun 18, 2025 at 6:17 PM Benoit Claise <[email protected]> wrote: > > Tal, Carlos, Adrian, > > As document shepherd, I provided my feedback on the version 4. See > https://mailarchive.ietf.org/arch/msg/opsawg/zQxI0xpOv1X5VFZDJP0YH1PJ-tU/ > Now looking at the diff between version 4 and 7. > > A couple of quick reactions. The draft improved a lot. Thanks Tal for jumping > in helping with this document. > Looking at the long email thread on this topic, I believe this work is > (painfully) important. There are some many slightly different OAM definitions > in RFCs: someone can always find one definition or one interpretation of it > for our own use. While this is apparently good, this is not helping our > industry with consistency. > > From my previous review, the following points have been addressed > - draft simplification (removed the "Processing of OAM by Notes, removed > Compound OAM, etc) > - softer language than "you SHALL" > > > - 3.3. Active, Passive, Hybrid, and In-Packet OAM > [RFC7799] provides clear definitions for active and passive performance > assessment such that the construction of metrics and methods can be described > as either "Active" or "Passive". Even though [RFC7799] does not include the > specific terms "Active", "Passive", or "Hybrid" as modifiers of "OAM", the > following terms are used in many RFCs and are provided here for clarity. > > You mention RFC7799, great. My question is: are the "Active", "Passive", or > "Hybrid" terms define here aligned with RFC7799. If yes, you should stress it. [TM] Agreed. The section "Active, Passive, Hybrid, and In-Packet OAM" was updated with explicit text that says that the definitions in the current document are consistent with RFC7799. > > - Since this document is about guidelines, I would had some more text around > "Packet Forwarding Treatment OAM" > Greg has a point that "having equivalence between both topological and QoS > aspects makes the results of the observation more operationally useful.". > Some maybe some text around: Determining whether an OAM mechanism is > Equal-Forwarding-Treatment or Different-Forwarding-Treatment is not obvious, > except in the case of Hybrid OAM thatis always Equal-Forwarding-Treatment > OAM, as the forwarding device hash functions are typically not known. > However, if we can determine that the OAM will have the same forwarding > treatment, it's best as the results are more operationally useful. > [TM] Right. The section "Packet Forwarding Treatment OAM" has been updated with more discussion about the motivation for equal-forwarding-treatment. > > - I believe that the section 3.4 need more advice for document authors (I > already mentioned this in my previous review) > Let me explain: I see 3 series of OAM adjectives > > [Path-Congruent | Non-Path-Congruent] > [ Equal-Forwarding-Treatment | Different-Forwarding-Treatment ] > [ Active | Passive | Hybrid ] > > Should we always be try to characterize OAM with terms in each 3 series? > Some are redundant: > Hybrid is always Path-Congruent and Equal-Forwarding-Treatment, right? > So does it make sense to call RFC 9197 as Path-Congruent > Equal-Forwarding-Treatment Hybrid OAM mechanism? > Some are not possible: > Passive & Non-Path-Congruent > Hybrid and Non-Path-Congruent > etc. > Think about authors who will need to chose the right terms. > Along the same lines, it might be nice to take the different examples in the > draft (RFC 9197, 9551, 5085) and express them with the terms define here. Or > even take as example very simple mechanism, such as ping. Ping is ... I guess > Active OAM and I am not sure about the rest: [Path-Congruent | > Non-Path-Congruent] & [ Equal-Forwarding-Treatment | > Different-Forwarding-Treatment ] [TM] Agreed. The section "Using Multiple Criteria" has been re-written and significantly extended with the relevant aspects and several examples. > > > Regards, Benoit Thanks, The authors. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
