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.
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-oam-characterization-07#section-3.3>Active,
Passive, Hybrid, and In-Packet OAM
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-oam-characterization-07#name-active-passive-hybrid-and-i>
[RFC7799 <https://www.rfc-editor.org/info/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
<https://www.rfc-editor.org/info/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.
- 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.
- 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 ]
Regards, Benoit
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
