|
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 12:59:38
Here are my comments.
#1
1.1. The Building Blocks of OAM
An OAM protocol is run in the context of a Maintenance Domain,
consisting of two or more nodes that run the OAM protocol, referred
to as Maintenance Points (MP).
%sam - I do not think that, MP, MEP, etc., terminology is used in OAM across
different layers. It was introduced in MPLS-TP and later in TRILL, but prior to
that, it is not. Is it the authors intention that this new terminology be used
going forward?
#2
Sec 1.1 - An OAM protocol typically supports one or more of the
tools described below.
%sam - what is OAM protocol? Shouldn't it be management plane OR OAM tools?
#3
Section 1.2 The considerations of the control-plane maintenance tools or the
functionality of the management-plane are out of scope for this
document, which will concentrate on presenting the forwarding-plane
tools that are used for OAM.
%sam - Why is it out of scope? For example, checking consistency of control
plane to forwarding plane is part of OAM or not?
#4
Section 1.3 The set of OAM
mechanisms described in this memo are applicable to IP unicast, MPLS,
pseudowires, and MPLS for the transport environment (MPLS-TP).
%sam - For ex: Is ATM OAM (RFC4717) within the scope of this draft? I did't see
any mention of it or FR. I know that they are legacy, but still within IETF.
One day even MPLS will be legacy protocol (just saying :D)
#5
Over all draft
%sam - I do not think this draft even considered 'multicast traffic'. There are
rfc's in ever layer supporting multicast. There is no reference I could find.
Ex: RFC6450, RFC6425 etc
#6
Sec 3.5
%sam - I think it is good to add details on different types of VCCV types of CC
and CV and their use.
#7
General
%sam - Do you consider MIB part of OAM? Does Traps considered as error
reporting or fault indication?
#8
Sec 3.4.3.8 and 9
%sam - Do these consider actual packet LM and DM or synthetic packets?
#9
Section 4
%sam - I think this section should provide more details on what the general
security issues are with OAM messages etc. And how they could be mitigated. For
in-depth details, one could go into each of those documents.
#10
Sec 3.7
I do not think this is complete representation. For ex: no representation of
multicast. BFD could be used for RDI, I think.
#11
IP Ping and Traceroute
%sam - When you say IP ping, does it imply ICMP ping or IP/UDP ping?
cheers
-sam
On Jan 15, 2013, at 6:48 AM, Benoit Claise <bclaise(_at_)cisco(_dot_)com> wrote:
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], 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
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 to iesg(_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.
|
|