|
Re: Last Call: <draft-ietf-opsawg-oam-overview-08.txt> (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC
2013-01-15 08:49:59
Some more feedback, send on behalf of Al Morton.
Regards, Benoit
=================================================
Hi Benoit,
Here are some additional comments, just checking a few things
I know a little about.
Al
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
1.1. The Building Blocks of OAM
...
o Performance Monitoring:
Consists of 3 main functions
o Loss Measurement (LM) - monitors the packet loss rate of a
connection.
o Delay Measurement (DM) - monitors the delay and delay
variation between MPs.
o Throughput measurement - monitors the throughput of a
connection.
Apparently, no OAM tool currently measures Throughput,
because no such tool is cited in the memo (and the term "throughput"
never appears again). my guess is that there was some reference to
RFC 2544 that has now been removed. Remove Throughput from the list.
1.3 OAM Toolsets
...
o OWAMP and TWAMP:
The One Way Active Measurement Protocol (OWAMP) and the Two Way
Active Measurement Protocols (TWAMP) are two protocols defined in
the IP Performance Metrics (IPPM) working group in the IETF. These
protocols allow delay and packet loss measurement in IP networks.
and Delay variation, duplication, reordering, etc. (all the metrics limited
tools
completely ignore).
1.4 IETF OAM Documents
Expand Table 1 as noted above, to include all the metrics they missed.
3.6.1
...
TWAMP [TWAMP] is a similar protocol that enables measurement of
both one-way and
two-way (round trip) characteristics.
sentence below is simply not true, because the authors did not understand
the one-way measurement capability:
TWAMP does not require accurate
time of day, and, furthermore, allows the use of a simple session
reflector, making it an attractive alternative to OWAMP.
go back and read the memo...
3.7. Summary of OAM Functions
Table 3 summarizes the OAM functions that are supported in each of
the categories that were analyzed in this section.
+-----------+-------+--------+--------+-----------+-------+--------+
| Standard |Continu|Connecti|Path |Defect |Perform|Other |
| |ity |vity |Discover|Indications|ance |Function|
| |Check |Verifica|y | |Monitor|s |
| | |tion | | |ing | |
+-----------+-------+--------+--------+-----------+-------+--------+
...
+ --------- + ----- + ------ + ------ + --------- + ----- + ------ +
|OWAMP and | | | | |-Delay | |
|TWAMP | Yes | Yes | | | measur| |
| | | | | | ement | |
| | | | | |-Packet| |
| | | | | | loss | |
| | | | | | measur| |
| | | | | | ement | |
+-----------+-------+--------+--------+-----------+-------+--------+
Table 3 Summary of OAM Functions
Both Continuity Check and Connectivity Verification are tested and
confirmed by establishing the *WAMP Control Protocol TCP connection,
so this should be indicated the table.
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
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-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
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.2>. OAM
Maintenance Entities ..........................13
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-13>
2.2.3
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.3>. OAM
Maintenance Points ............................14
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-14>
2.2.4
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.4>.
Proactive and On-demand activation ................15
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-15>
2.2.5
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.5>.
Connectivity Verification and Continuity Checks ...15
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-15>
2.2.6
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#section-2.2.6>.
Failures ..........................................15
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#page-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
hadhttp://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
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-MPLS-LM-DM>],
[TP-LM-DM
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-TP-LM-DM>]), and in
Ethernet
OAM [ITU-T-Y1731
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08#ref-ITU-T-Y1731>].
My conclusions: this document still needs some work
Regards, Benoit
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
Mechanisms'
<draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2013-01-25. Exceptionally, comments
may be
sent toiesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
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.
This document presents an overview of the OAM mechanisms that have
been defined and are currently being defined by the IETF.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/
No IPR declarations have been submitted directly on this I-D.
|
|