Hi,
Please find an additional set of comments. Hopefully these are clear and
useful, they include both substantive and editorial comments.
1. Introdoction
1.1. Background
I agree with Ron that this is hard to parse, even more so describing plane
interactions without a diagram. Frankly, the Management-plane mentions are a
bit of a distraction from the main point (other than saying that it is out of
scope)
1.2. The OAM Toolsets
...
The IETF has defined OAM protocols and mechanisms in several
different fronts:
This section is confusing, at least to me, in that it is not clear if it is
defining protocols, program, mechanisms, or all intertwined, and which one it
is cataloging or listing.
I think it is very important for this document to have precision in the
definition of OAM terms, differentiating a protocol from a tool from a program.
For example, the document says:
o ICMP Ping:
ICMP Echo request, also known as Ping, as defined in
[ICMPv4<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-07#ref-ICMPv4>],
and
[ICMPv6<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-07#ref-ICMPv6>].
ICMP Ping is a very simple and basic mechanism in
failure diagnosis. LSP Ping is to some extent based on ICMP Ping.
AFAIK, "ICMP Echo request" is not known as Ping per se. ICMP Echo requests are
sent in some OSes traceroute implementations (with increasing TTL, etc.)
Specifically, RFC1147 ("Tools for Monitoring and Debugging TCP/IP Internets")
describes:
Ping
a tool that sends packet probes such as ICMP echo mes-
sages; to help distinguish tools, we do not consider
NMS queries or protocol spoofing (see below) as probes.
RFC1208 ("A Glossary of Networking Terms") defines:
ping: Packet internet groper. A program used to test reachability of
destinations by sending them an ICMP echo request and waiting for a
reply. The term is used as a verb: "Ping host X to see if it is up!"
RFC 1122 as:
* Active probes such as "pinging" (i.e., using an ICMP
Echo Request/Reply exchange)
Further, that paragraph says:
o ICMP Ping:
ICMP Echo request, also known as Ping, as defined in
[ICMPv4<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-07#ref-ICMPv4>],
and
[ICMPv6<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-07#ref-ICMPv6>].
ICMP Ping is a very simple and basic mechanism in
failure diagnosis. LSP Ping is to some extent based on ICMP Ping.
And LSP Ping is not "based" on ICMP Ping. It is, instead, as per RFC 4379:
In this document, we describe a mechanism that accomplishes these
goals. This mechanism is modeled after the ping/traceroute paradigm:
ping (ICMP echo request [ICMP<http://tools.ietf.org/html/rfc4379#ref-ICMP>])
is used for connectivity checks, and
traceroute is used for hop-by-hop fault localization as well as path
tracing. This document specifies a "ping" mode and a "traceroute"
mode for testing MPLS LSPs.
1.3<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-07#section-1.3>.
IETF OAM Standards
Even further down, the document says:
+-----------+--------------------------------------+-----+----------+
| | Title |Type | RFC |
+-----------+--------------------------------------+-----+----------+
|ICMPv4 Ping| Internet Control Message Protocol |Tool | RFC
792<http://tools.ietf.org/html/rfc792> |
| | | | |
+-----------+--------------------------------------+-----+----------+
However Ping, if considered a tool, is not defined in RFC 792. ICMPv4, a
protocol, is defined, which can be used in ping and in traceroute probes and
other tools.
+-----------+--------------------------------------+-----+----------+
|Traceroute | A Primer On Internet and TCP/IP |Tool | RFC
2151<http://tools.ietf.org/html/rfc2151> |
| | Tools and Utilities | | |
+-----------+--------------------------------------+-----+----------+
What is the RFC column pointing to? There are traceroute (as a tool) mentions
and definitions earlier (RFC 1147) and later.
+-----------+--------------------------------------+-----+----------+
|IETF MPLS | Operations and Management (OAM) |Misc.| RFC
4377<http://tools.ietf.org/html/rfc4377> |
|OAM | Requirements for Multi-Protocol Label| | |
|(LSP Ping) | Switched (MPLS) Networks | | |
| +--------------------------------------+-----+----------+
...
| +--------------------------------------+-----+----------+
| | ICMP Extensions for Multiprotocol |Tool | RFC
4950<http://tools.ietf.org/html/rfc4950> |
| | Label Switching | | |
+-----------+--------------------------------------+-----+----------+
RFC 4950 does not define "LSP Ping". It is ICMP with Extension for MPLS, not
MPLS OAM.
Perhaps there needs to be a section on RFC 4884, and specific extensions like
RFC 4950, RFC 5837, etc?
Also, RFC 4950 is cited here but not included in the References section.
+-----------+--------------------------------------+-----+----------+
|PW VCCV | Pseudowire Virtual Circuit |Inf. | RFC
5085<http://tools.ietf.org/html/rfc5085> |
| | Connectivity Verification (VCCV): | | |
| | A Control Channel for Pseudowires | | |
+-----------+--------------------------------------+-----+----------+
This is missing RFC 5885 as well.
3. OAM Tools.
This section seems to also somewhat mixed different things, since BFD and LSP
Ping are for example used within VCCV.
3.7.3.3 and 3.7.3.4 Lock ...
This section seems to miss a pointer to RFC 6435.
Thank you,
-- Carlos.
On Jan 3, 2013, at 11:24 AM, Ronald Bonica
<[email protected]<mailto:[email protected]>> wrote:
Authors,
Thanks for submitting this draft and for suffering through the drawn out
process. The following are a few comments.
Section 1 and 1.1
=========
The introduction is harder to parse than it needs to be. In the introduction, I
think that that you are trying to make the following points:
- This memo summarizes IETF OAM mechanisms
- An OAM mechanism provides the following laundry list of functions (e.g.,
connectivity checking, path discovery, etc.) Provide a definition for each
function.
- The scope of this document is limited to OAM mechanisms that operate on the
data plane. (SNMP is out of bounds).
Do I have that much right? If so, would it be possible to craft Sections 1 and
1.1 so that these points are brought to the forefront?
Section 1.2
===========
- Should every OAM mechanism listed in Table 1 should appear in the bullet
list. Some are missing (e.g., TRACEROUTE).
- You list MPLS as an OAM tool. You probably mean to say MPLS LSP Ping.
- For the most part, the bullet list is a list of tools. The notable exception
is IPPM, which is a WG, not a tool. Should you replace that bullet item with
the tools that the produce (e.g., OWAMP, TWAMP)?
Section 1.3
===========
- The title of this section is inappropriate, because some of the documents
that you list are not on the standards track. Maybe a better title would be
IETF OAM Documents, Grouped by the OAM mechanism that they support.
- If you accept the suggestion listed above, the first column of Table 1 should
specify an OAM mechanism, drawn from the bullet list in Section 1.2. The second
column should be an RFC number. The third column should be an RFC title, and
the fourth column should be the type.
- RFCs 4884, 4950 and 5837 should be associated with TRACEROUTE, because they
all augment the ICMP Destination Unreachable message and their output is
intended for consumption by TRACEROUTE. (While RFC 4950 has something to do
with MPLS, it is a different mechanism than MPLS LSP PING.
Section 2.1
============
- Please do a brief scan of the document to make sure that you actually use all
of the acronyms that you define. I found quite a few that are unused.
Section 3
=========
The subsections of Section 3 should map to the bullet points in Section 1.2
Section 3.2
===========
By default, traceroute sends 3 probes per TTL. However, in most
implementations, this is configurable through the command line
Nits
====
Please run the nit checker and correct all errors and warnings
--------------------------
Ron Bonica
vcard:
www.bonica.org/ron/ronbonica.vcf<http://www.bonica.org/ron/ronbonica.vcf>
_______________________________________________
OPSAWG mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
