Last Call Review of draft-ietf-opsawg-oam-overview-08

Request Review of draft-ietf-opsawg-oam-overview
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-01-25
Requested 2013-01-17
Authors Tal Mizrahi, Nurit Sprecher, Elisa Bellagamba, Yaacov Weingarten
Draft last updated 2013-02-27
Completed reviews Genart Last Call review of -08 by Elwyn Davies (diff)
Genart Telechat review of -14 by Elwyn Davies (diff)
Secdir Last Call review of -?? by Paul Hoffman
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-opsawg-oam-overview-08-genart-lc-davies-2013-02-27
Reviewed rev. 08 (document currently at 16)
Review result Not Ready
Review completed: 2013-02-27


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


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

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

 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)

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