Dear all,
As the new document shepherd, I've been spending some time reviewing the
draft-ietf-opsawg-oam-characterization draft, the mailing list feedback,
the WG presentation (oh surprise: this draft was only presented once, in
IETF 119 , when it was still an individual draft), trying to understand
the different view points, reading some of the references, etc.
Note: I read this draft for the time recently. Why only now? I was
minding my own IETF business before becoming OPSAWG chair ;-)
The good news is that it forces a new pair of eyes on this
draft.
In this review, I want to address some high level points (exactly 3), as
opposed to editorial comments (which might come later)
1. I am confused by the terms in section 3: the IPPM RFC 7799 terms
with OAM suffixes. Which problem do we try solve here? What do these new
terms bring to the table? RFC 7799 is about performance metrics, the 4
new terms (active OAM, Passive OAM, Hybrid OAP, Compound OAM) are even
confusing to me.
First, I wonder how the 4 terms relate to the previously defined terms
in the draft an Active OAM is always a Dedicated-Packet OAM, right? a
Passive OAM is always a In-Packet OAM, right? So some of terms are
redundant with your previous OAM definition
Second, I scratch my head trying to use the terms with a simple example:
ping, measuring the connectivity & delay. Looking at the following
pieces of information in the draft
Dedicated-Packet OAM:
The OAM information is carried in its own OAM packets, separate
from data traffic. This was sometimes referred to as "out-of-
band".
Active OAM:
Depends on injected, dedicated OAM packets.
I don't know which term(s) I should be using!
- In my day to day life, I would say: ping is active OAM mechanim.
- According to this draft, I guess I should say: ping is
Dedicated-Packet OAM mechanism. In this case, then, why do I need the
Active OAM definiton?
- And, if I want to be complete according to the draft, I would have to
say that: ping is Dedicated-Packet Path-Congruent
Equal-Forwarding-Treatment OAM mechanism (assuming there is no
ping-specific policy-based routing and QoS) Or maybe: ping is Active OAM
Dedicated-Packet OAM mechanism.
And now if I want to specify a Hybrid Type I or II (from RFC 7799), do I
need to create yet new terms; Hybrid OAM Type I or II.
In conclusion, as you see, I am confused by the intended goal of the
terms in section 3, and I believe this section does more harm than helping.
Like Tim in his OPS-DIR review, I believe you would have more success by
reducing the document scope, and completely removing this section.
2. Use in all future IETF document that refers to OAM
I see in the abstract:
This document considers some common qualifiers and modifiers that are
prepended, within the context of packet networks, to the OAM
abbreviation and lays out guidelines for their use in future IETF
work.
And in the intro
This document
considers some common qualifiers and modifiers that are prepended to
the OAM abbreviation, and lays out guidelines for their use in future
IETF work to achieve consistent and unambiguous characterization
And in section 2.1
The definitions presented in this
document are for use in all future IETF documents that refer to OAM,
And later on:
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 use in all future IETF
documents that refer to OAM.
Many repetitions about "you SHALL use those definitions". I can feel why
some people (from other WGs) might frown upon this formulation.
At https://youtu.be/d-XEKtM_VTQ?t=3197, Adrian had a softer formulation:
"clear and consistent terminology that can applied in all future
documents. We are not looking to fix RFCs that are out there or even
late drafts"
Proposal:
- no need for all the repetitions,
- chose the softer formulation. Typically, I would remove the last
two occurrences. No need to go in the enforcement part (for use in all
future IETF documents); the enforcement is done by the IESG, typically
3. Guidelines for Characterizing "OAM": What are the actual guidelines
for future document authors?
I see in the abstract:
This document updates RFC 6291 by adding to the guidelines for the
use of the term "OAM".
I have been trying to list the guidelines, and I found two:
- the terms "in-band OAM" and "out-of-band OAM" are not to be used in
future documents
- This document recommends avoiding the creation and use of extended
abbreviations for the qualifiers of "OAM".
Do I miss any?
I was after some guidelines around:
- composition
taking back my ping example: Dedicated-Packet Path-Congruent
Equal-Forwarding-Treatment OAM mechanism
Should be put all the OAM charactistics in future documents?
- some combinations are not possible in Path-Congruent OAM vs
Non-Path-Congruent OAM | In-Packet OAM vs Dedicated-Packet OAM |
Equal-Forwarding-Treatment OAM vs Different-Forwarding-Treatment OAM
As you wrote:
It is noteworthy that In-Packet OAM cannot be Non-Path-Congruent OAM.
So In-Packet OAMs are always Path-Congruent OAMs?
In situ OAM, as an example, is both In-Packet and Path-Congruent. Should
be always use "In-Packet Path-Congruent" in future documents, or
Path-Congruent is implicit?
Equal-Forwarding-Treatment OAM falls in the same category: In-Packet OAM
are also Equal-Forwarding-Treatment OAM
What are the guidelines for future document authors? I believe I know
enough about OAM & measurements ... but putting myself in the shoes of
future document authors, I don't have the clear guidelines I am after
- I have not even mentioned the section 3 terms here, which adds a
fourth (sometimes) redundant dimension.
Regards, Benoit
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
