draft-ietf-opsawg-oam-overview
authors,
Here is my feedback on this document.
1.
Is this document in line with
http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
Fault: The term Fault refers to an inability to perform a required
action, e.g., an unsuccessful attempt to deliver a packet.
Defect: The term Defect refers to an interruption in the normal
operation, such that over a period of time no packets are delivered
successfully.
Failure: The term Failure refers to the termination of the required
function over a longer period of time. Persistence of a defect for a
period of time is interpreted as a failure.
* For example, on the basic abstract
Abstract
Operations, Administration, and Maintenance (OAM) is a general term
that refers to a toolset that can be used for fault detection and
isolation, and for performance measurement. OAM mechanisms have been
defined for various layers in the protocol stack, and are used with a
variety of protocols.
Abstract (draft-ietf-trill-oam-req-04)
OAM (Operations, Administration and Maintenance) is a general term
used to identify functions and toolsets to troubleshoot and monitor
networks. This document presents, OAM Requirements applicable to
TRILL.
So, as an example: does OAM include function?
I advice to review draft-ietf-trill-oam-req-04
2.
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
This document presents an overview of the OAM mechanisms that have
been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references.
Ok, I see later on:
This document focuses on IETF
documents that have been published as RFCs, while other ongoing OAM-
related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts.
However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.
3.
Section 1
The term OAM in this document refers to Operations, Administration
and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
A Maintenance Point (MP) is a functional entity that is defined at a
node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?
4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data
plane, control plane, or management plane?
Note that I found later on in the draft:
OWAMP and TWAMP use two separate protocols: a Control plane protocol,
and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/,
and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its relationship
to various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane.
Way too many.
Please be consistent
7.
Table 1 summarizes the IETF OAM related RFCs discussed in this
document.
Table 2 summarizes the OAM standards mentioned in this document.
You need to change the Table 2 description. Do you want to say something along the lines of:
Table 2 summarizes the OAM standards specified by other Standard Development Organization
(SDO) than the IETF, along with IETF references where applicable.
8.
Section 2.2.1
For a formal definition of each term, refer to the references at the end of
this document.
Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references.
You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms,
just read first all references!"
9.
You specify some terms and some OAM categories,
2.2.2. OAM Maintenance Entities .......................... 13
2.2.3. OAM Maintenance Points ............................ 14
2.2.4. Proactive and On-demand activation ................ 15
2.2.5. Connectivity Verification and Continuity Checks ... 15
2.2.6. Failures .......................................... 15
... but you don't use them in the section 3
Just one example with section 3.2.2
-
o Demand mode: in this mode, BFD control packets are sent on-demand.
Upon need, a system initiates a series of BFD control packets to
verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5
- OLD:
Each of the end-points of the monitored path maintains its own
session identification
NEW:
Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
Each of the MP maintains its own session identification
- OLD
A BFD echo packet is sent to a peer system
Peer system = MEP, MP, or something else?
- etc...
10.
This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.org/html/rfc6632#section-1.1
The target audience of the document is, on the one hand, IETF working
groups, which aim to select appropriate standard management protocols
and data models to address their needs concerning network management.
On the other hand, the document can be used as an overview and
guideline by non-IETF Standards Development Organizations (SDOs)
planning to use IETF management technologies and data models for the
realization of management applications. The document can also be
used to initiate a discussion between the bodies with the goal to
gather new requirements and to detect possible gaps. Finally, this
document is directed to all interested parties that seek to get an
overview of the current set of the IETF network management protocols
such as network administrators or newcomers to the IETF.
You should have something similar.
11.
Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense
Alternative protocols for performance measurement are defined, for
example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
OAM [ITU-T-Y1731].
My conclusions: this document still needs some work
Regards, Benoit