Elwyn,
Thanks for your review.
I don't plan to reply for the authors (btw, not sure I've seen a reply
to this), and but a few clarification questions in line, to engage the
discussion.
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.
Can you provide an example of what you mean here?
Do you mean that SNMP (and NETCONF) can be used to monitor the OAM
results?
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.
Ok, the document title could be improved.
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.
This sentence was added:
The target audience of this document includes network equipment
vendors, network operators and standard development organizations,
and can be used as an index to some of the main OAM tools defined in
the IETF.
And section 1.2
1.2
<http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13#section-1.2>.
Target Audience
The target audience of this document includes:
o Standard development organizations - both IETF working groups and
non-IETF organizations can benefit from this document when
designing new OAM protocols, or when looking to reuse existing OAM
tools for new technologies.
o Network equipment vendors and network operators - can use this
document as an index to some of the common IETF OAM tools.
It should be noted that this document is not necessarily suitable for
beginners without any background in OAM.
Please let the authors know what you would like to see.
I let the authors/doc. shepherd answer the following points.
Regards, Benoit
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.