Hi Benoit, Thanks for the very detailed shepherd review. Please see inline comments, marked [[TM]].
On Wed, Jun 25, 2025 at 7:57 PM Benoit Claise <[email protected]> wrote: > > Hi Tal, > > On 6/25/2025 7:30 AM, Tal Mizrahi wrote: > > 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. > > BC> Stressing the alignment with RFC7799 was key to me. Thanks. > > - 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. > > BC> Exactly the text I had in mind. > If you feel like this, you can even go further > OLD: > > Without such equivalence, discrepancies in treatment > could lead to misleading measurements or diagnostics, reducing the > utility of the OAM mechanism for performance monitoring and fault > detection. > > NEW: > Without such equivalence, discrepancies in treatment > could lead to misleading measurements, diagnostics, and even inadequate > corrective actions, reducing the > utility of the OAM mechanism for performance monitoring and fault > detection. > [[TM]] Updated. > - 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. > > I have been scratching my head on how to represent these 3 dimensions in the > draft, where some combinations don't make sense > > [Path-Congruent | Non-Path-Congruent] > [ Equal-Forwarding-Treatment | Different-Forwarding-Treatment ] > [ Active | Passive | Hybrid ] > > In my head, I represent them in the following way > > > So starting from the type. Note: I learned that "In-Packet OAM, a subset of > hybrid OAM", which was not in the defintion btw. > The path followed OAM, then packet forwarding. > When I have identified which OAM I am going to mention in my future IETF > drafts, the next question is: how do you name it? > See the questions in the last two lines of the picture. > > Now, is the order important? > Is it Equal-Forwarding-Treatment Path-Congruent Active OAM or Path-Congruent > Equal-Forwarding-Treatment Active OAM? > The section order is not clear to me. > > Could we find a way to represent the different choices in a logical tree in > the draft? > Bonus points if you could attach your examples to it. > > Final nits: be consistent with capitalization in section 3.4 vs the rest of > the document > ex: non-path-congruent versus Non-Path-Congruent [[TM]] Based on these comments, Section 3.4 "Using Multiple Criteria" was significantly revised with clearer guidelines and examples of how to use the multiple criteria. The order of the criteria was changed, so that active/passive/hybrid/in-packet is presented first. The text now clearly recommends that the first step should be to classify according to the active/passive/... criterion, and then consider whether the other criteria are relevant. While the current text does not go into an exhaustive description of all possible combinations, it hopefully explains the relation between these criteria in a clearer manner. > > > Regards, Benoit > > > > Regards, Benoit > > Thanks, > The authors. > > Cheers, Tal. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
