I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-opsawg-oam-overview-08.txt
Reviewer: Elwyn Davies
Review Date: 22 Jan 2013
IETF LC End Date:25 Jan 2013
IESG Telechat date: (if known) -
Summary: In my opinion, this draft has serious issues as described
below.
Major issues:
General 1: Title vs Abstract vs Section 1 vs actual content:
Here in the UK a well-known brand of varnishes and wood preservative
paints uses the slogan 'Does what it says on the tin!'. If my
understanding and the write-up in RFC 6491, OAM covers a whole lot more
than the coverage of the specific mechanisms discussed in this
document .. and there are various other mechanisms such as SNMP and
Netconf that support the OAM constellation. I would take the view that
this document certainly does not 'do what it says on the tin'.
Accordingly I take issue with the title as it doesn't provide a total
overview of OAM mechanisms; the abstract closes down the scope of OAM as
compared with RFC 6491 and s1 restricts it even more - and certainly
does not summarize all the OAM tools and mechanisms defined in the IETF.
The last para of s1 claims that 'management aspects are outside the
scope of this document' - if this is really saying that this 'overview'
of OAM skips the whole M aspect of OAM then I'm afraid the document is
badly misnamed. And it significantly reduces the value of the work.
General (2): The intended purpose of this document: Back in 2011 Stewart
Bryant summarized a review of a previous version of this document from
the routing directorate
(https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry
dated 2011-08-10 referring to version 05 of the document). IMO the initial
section of that review regarding the audience of this document was well
targeted and *has not been fixed*. If this is intended as an introductory
overview for people wishing to see what OAM is about in the IETF then it needs
further introductory text and some background. It should also state what its
target audience actually is.
General (3): I don't know if Scott Bradner has actually produced a proto
shpeherd write up, but I would be intrigued to know the level of
concensus behind this document. In particular the tool classification
in s1.1 and terminology in s2 (particularly s2.2.2) is that used
exclusively in the MPLS-TP work in the IETF which is derived from the
802.1ag terminology. The terminology is presented as if it is common to
OAM work across the IETF. Does the IETF management community at large
concur with this expansion of the applicability of the terminology set
based on 'Management Domains' etc?
General (4): As an overview, I think it would be advisable to point out
that one reason for the multiplicity of tools is that they support at
least four different data plane technologies (native IP, vanilla MPLS,
MPLS-TP and PWE) and note that in several cases the data plane
technologies rely on distinct (IP-based) management channels to allow
the information gleaned by the operations in the the data plane to be
reported back to the application that originated the operation.
Minor (or at least less major) issues:
s1, para1: For consistency with the abstract, s1.1 .. and because I'd
expect OAM to handle it as well ... OAM deals with performance
monitoring and statistics gathering as well as dealing with degradation.
s1.1: The section is entitled building blocks but actually only mentions
one block, i.e., the OAM protocol. Presumably this section really ought
to say something about the applications and device drivers that have to
instantiated in the MPs. In particular as introduction to the text in
the following section it should say something about classifying
applications into continuously running or proactive monitoring and
on-demand applications (since the latter are introduced without any
definition in the next section.)
s2.2.2/3: I am not familiar with 802.1 management issues and I was
rather confused by the logical status of MIPs . The text here seems to
indicate that they are intermediate and generally don't terminate
messages but then says in s2.2.3 that messages are 'destined to' MIPs.
Looking for some additional understanding, I fetched up at Wikipedia
(now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag.
This page mentions the concept of maintenance domains and the
explanation of MIPs as internal points in the domain that generally
forward messages within the domain whereas end points (MEPs) are
effectively on the domain boundary. This makes a whole lot more sense
and seemed to be a rather better set of term definitions than we have in
this draft.
I noticed eventually that the term Management Domain (MD) had appeared
in the first line of s1.1 but does not appear in s2 at all. If we are
going to accept the Management Domain terminology set, then MD certainly
ought to be defined and discussed here.
s2.2.3, para1, sentence 1:
either initiates or reacts to OAM messages.
The following sentences contradict this. Should be 'initiates and/or
reacts to OAM messages'. See comment above.
s3, general: The level of detail regarding the various toolsets is not
very even. In particular, the MPLS-TP toolset gets significantly more
attention than others and the detail in OWAMP/TWAMP may be more than is
desirable for an overview.
s3.1: A few words about the likely suppression of pings and traceroute
messages due to ICMP filtering is probably desirable as these limit
their usefulness in the wider Internet.
s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in
the list in s1.4 but is not mentioned here.
s3.4.1: Talking about what the MPLS working group 'is currently doing'
will not be helpful for an archival document.
s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean
RFC 6426 which appears to be the TP variant?
Nits/editorial comments:
General: For a reader who wants to go on and look at the RFCs that
define the various tools, it would probably be helpful to use reference
tags that either are or include the RFC number.
s1.3, para 2: s/in several fronts/covering several different approaches/
s2.2.2, last para: Need to expand 'p2mp'.
s3.4.3.8: Should this section reference RFC6375?
s3.5.1: It appears that the basic AC acronym (associated channel) is not
defined.