Skip to main content

An Overview of Operations, Administration, and Maintenance (OAM) Tools
draft-ietf-opsawg-oam-overview-16

Yes

(Benoît Claise)

No Objection

(Martin Stiemerling)
(Richard Barnes)
(Stephen Farrell)

Note: This ballot was opened for revision 14 and is now closed.

Benoît Claise Former IESG member
Yes
Yes (for -14) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2014-03-20 for -14) Unknown
I want to thank the authors for working so hard to address the concerns
raised by Stewart Bryant during the previous IESG review. I know it was
not an easy process for all concerned, but I believe the resulting
document is substantially improved.

I have checked for the Discuss issues and Comments that I raised last 
time around. Thank you or doing an excellent job of mopping them up. I
am left with just a few that I carry over as Comments, this time.

---

I still feel that sections 4.1 and 4.2 should include some mention of
OAM in multicast IP scenarios. Perhaps this got added somewhere else,
but  couldn't find it.

---

I should have liked Section 6 to have included a discussion of the 
security considerations of OAM in general, and the security provisions
available for the various OAM mechanisms discussed. What you have
still seems like a bid of a dodge.
Alia Atlas Former IESG member
No Objection
No Objection (2014-03-26 for -15) Unknown
In Sec 4.5.4: "The MPLS  working group currently plans to use a mixture of OAM tools that are
   based on various existing standards, and adapt them to the requirements of [MPLS-TP-OAM]."

Hasn't the MPLS WG finished up the MPLS-TP work and specifically the OAM related work?  Could this be rephrased to reflect that?
Barry Leiba Former IESG member
No Objection
No Objection (2014-03-26 for -15) Unknown
I'm glad that we have this sort of overview; thanks for the work on this.

I have a couple of small points below, and one of more significance.  Please consider them -- especially the last:

1. The Introduction says this (and it's also in the Abstract):

   This document focuses on tools for detecting and isolating failures
   and for performance monitoring. Hence, this document focuses on the
   tools used for monitoring and measuring the data plane; control and
   management aspects of OAM are outside the scope of this document.

But the title says this:
"An Overview of Operations, Administration, and Maintenance (OAM) Tools"

Might it be better to change the title to something that indicates that it's limited, and not an overview of *all* OAM tools?  Something, maybe, like "An Overview of Operations, Administration, and Maintenance (OAM) Tools for Detecting and Isolating Failures and for Performance Monitoring"

I know that makes for a long title, but I think it's better than overselling the document.


2.
-- Section 1.2 --

   It should be noted that this document is not necessarily suitable for
   beginners without any background in OAM.

I'd think that a statement of what's necessary would be more useful.  Pick one or two references that are the most critical, perhaps, and say something like this instead:

   It should be noted that some background in OAM is necessary in order
   to understand and benefit from this document.  [OAM-Def] and [..other..]
   are particularly important starting points.


3. Further to that point, I see that you have no normative references.  Perhaps you think that Informational documents don't need normative references, an opinion I don't share.  I think that the references that are required in order to understand the document at hand are normative references, regardless of the status of the document at hand.  I'm not making this a DISCUSS point, but I strongly urge you to do a separation of the references, and at least move the most critical ones into a Normative References section, to make it clear to the reader which documents absolutely have to be read as background material.
Jari Arkko Former IESG member
No Objection
No Objection (2014-03-27 for -15) Unknown
Please consider the following comments Elwyn Davies and his Gen-ART review:

Summary:
Ready with nits and a couple of very minor issues.
I was pleased that this version of the document seems to have been
greatly improved since -08 which I reviewed previously in Jan 2013, and
the scope is now quite clear.  Thanks for the work that has been done!  

Major issues:
None.

Minor issues:
General:  I wondered about the wisdom of using more or less mnemonic
tags for the multitude of references but on reflection the mnemonic
value is probably worthwhile.  I toyed with the idea of adding the RFC
number next to the reference in the text on first occurrence so that
people don't have to keep skipping off to the references, but in the end
this is probably a silly idea.

s2.2.9, Discussion: The added complexity of P2MP is called out but
nothing is said about MP2MP, which I think would be even more tricky.
Would it be useful to say something also about MP2MP? [*Are* there any
tools for this case?]

s4.4.1, para 6: There seems to be possibly a minor contradiction between
the statements:

LSP Ping is easily extensible to
  include additional information needed to support new functionality,
  by use of Type-Length-Value (TLV) constructs.

and

The usage of TLVs is
  typically not easy to perform in hardware, and is thus typically
  handled by the control plane.

What is the implication of adding a new TLV as regards hardware and
performance? Does the second statement mean that either the hardware
will throw away messages with unknown, new TLVs, complain about such
messages or have poor performance?  If so, the "easily" in the first
statement is possibly "easily but impractically".  A little explanation
is probably needed (or maybe this is just too complex to explain here).
Maybe reducing all this to "LSP Ping is extensible using additional TLVs
but there may be hardware issues (see RFC...)." 

Nits/editorial comments:
General: s/i.e./i.e.,/, s/e.g./e.g.,/ (a couple of missing cases)

General: It would be helpful to use non-breaking hyphens in MPLS-TP and
all references if possible.

s1.2, first bullet: s/Standard development/Standards development/

s1.3: It would be useful to put a forward reference to the terminology
section 2.1 to cover the various acronyms and abbreviations in Table 1.

s3, 2nd bullet: s/also allows to detect/also allows detection of/  It
might also be appropriate to be a bit less definite about localization -
add in 'attempts' or 'tries' maybe?

s3, Delay Measurement: Maybe mention 'jitter' as an alternative for
delay variation.

s4.3.3, 2nd bullet: s/a failure is detected/a failure is reported/

s4.3.3, last para: s/i.e. no failures are detected,/i.e., when no
failures have been detected,/

s4.3.3, last para: "...negotiated transmission time" Do you mean
"transmission rate" as mentioned in the previous para?  If not it might
be good to make it clear that this isn't a typo.

s4.4.1, para 4 (after 2nd bullet): s/and also Maximum Transmission Unit
(MTU) problems/and also identify Maximum Transmission Unit (MTU)
problems/

s4.4.1, para 5: s/the MPLS faults/MPLS faults/

s4.5.1, 2nd bullet: 
and there is a need to
     differentiate OAM packets from data plane ones.
This is slightly confusing - the congruence requirement makes all the
packets (OAM and user) to be data plane packets. How about:

and there is a need to
     differentiate OAM packets from ordinary user packets in the data plane.


s4.5.1, Maintencance Intermediate Point section:
A MIP in MPLS-TP identifies OAM packets destined
  to it by the value of the TTL field in the OAM packet.
This is not terribly helpful: Either a reference to where to find out
what TTL value is needed or some explanation of the required value would
be a good idea.

s4.5.1, Up and Down MEPs:
The term "bridge interface" is IEEE/MPLS-TP jargon and needs defining.
Might be also worth a note that, unlike prior usage of up/down, this has
nothing to do with defects (or layabout parliamentarians in
Brussels). ;-)

s4.5.3: Please add a reference for PWE3 ACH and VCCV and a pointer to a
document where "PW control word" is defined (preferably with section
numbers.

s4.5.4.6: s/if there a return path exists/if a return path exists/

s4.7.3, last para: s/Server accepts the modes./Server accepts the mode./

s4.7.3, last para: I think there is a bit of interaction missing: (i)
server tells Session-sender to start sending; (ii) if Control-client
stops the session, it tells server and server tells Session-sender;
(iii) when session is finished Session-sender reports to Server which
recovers data from Session-receiver (or controls Fetch client?) 

s5.1, Traceroute: Should this mention the Paris traceroute?

s5.1, OWAMP/TWAMP: For consistency should probably reference RFCs.

s5.3: s/in as much accuracy/with as much accuracy/
Joel Jaeggli Former IESG member
No Objection
No Objection (2014-03-24 for -14) Unknown
I can live with the current version of this document.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-03-26 for -15) Unknown
The draft provides a nice overview.  I was surprised that the Security Considerations section does not cover reconnaissance (network addresses, ports, and path) and should at least mention it as it is one of the major concerns between security and performance management techniques (ping, traceroute, etc.).  It is the typical first stage of an attack to gather information on a network - what hosts exist, what ports are active, how many routes are there to the network (think DoS attack), and any additional information revealed through OAM techniques.  I'd like to see some text added to generally cover this topic.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -15) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2014-03-25 for -14) Unknown
I really appreciate the work that has gone into providing this understandable overview.
Stephen Farrell Former IESG member
No Objection
No Objection (for -15) Unknown