Re: Last Call: <draft-ietf-opsawg-oam-overview-08.txt> (An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



draft-ietf-opsawg-oam-overview authors,

Here is my feedback on this document.

1.
Is this document in line with http://tools.ietf.org/html/draft-ietf-trill-oam-req-04?
* For example, the following definitions could be reused.
   Fault: The term Fault refers to an inability to perform a required
   action, e.g., an unsuccessful attempt to deliver a packet.

   Defect: The term Defect refers to an interruption in the normal
   operation, such that over a period of time no packets are delivered
   successfully.

   Failure: The term Failure refers to the termination of the required
   function over a longer period of time. Persistence of a defect for a
   period of time is interpreted as a failure.

* For example, on the basic abstract 
Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

Abstract (draft-ietf-trill-oam-req-04)

   OAM (Operations, Administration and Maintenance) is a general term
   used to identify functions and toolsets to troubleshoot and monitor
   networks. This document presents, OAM Requirements applicable to
   TRILL. 

So, as an example: does OAM include function? 
I advice to review draft-ietf-trill-oam-req-04

2. 
draft-ietf-trill-oam is not mentioned, while the abstract mentions:
   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.
Search for OAM in the current draft names (https://datatracker.ietf.org/), and you will find many references.
Ok, I see later on:	
   This document focuses on IETF
   documents that have been published as RFCs, while other ongoing OAM-
   related work is outside the scope.
Ok, fine then: we don't need a reference to all the drafts. 
However, draft-ietf-trill-oam is closed to be a RFC, and should be mentioned.


3.
Section 1
   The term OAM in this document refers to Operations, Administration
   and Maintenance [OAM-Def], focusing on the forwarding plane of OAM.
What does it mean "focusing on the forwarding plane of OAM"?
Do you take a subset of the definition for this document?
Btw, I don't see a definition in the terminology section.
In section 2.2.3
   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and either initiates or reacts to OAM messages.
Which plane is MP?

4.
Section 1, Introduction
"Hence, management aspects are outside the scope of this document."
I don't understand which management aspects we speak about here.
5.
Clarifying question regarding 1.2
If speak about OWAMP or TWAMP 'synthetic traffic), is that data plane, control plane, or management plane?
Note that I found later on in the draft:
   OWAMP and TWAMP use two separate protocols: a Control plane protocol,
   and a Test plane protocol.
Interestingly enough, after reading the document, I reviewed http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/, and saw the same feedback from Stewart Bryant:
Provide a clear view of OAM functionality and its relationship
to various “planes” of networking (data plane, control plane,
management plane). In particular, the importance of
fate-sharing of OAM and user traffic flows in packet networks
should be explained.
6.
I see a multiplication of "plane" terms in the IETF document, and in this document in particular.
I could find: forwarding plane, management plane, control plane, data plane, user plane, and test plane.
Way too many.
Please be consistent
7.
   Table 1 summarizes the IETF OAM related RFCs discussed in this
   document.

   Table 2 summarizes the OAM standards mentioned in this document. 

You need to change the Table 2 description. Do you want to say something along the lines of:
   Table 2 summarizes the OAM standards specified by other Standard Development Organization 
   (SDO) than the IETF, along with IETF references where applicable.


8.
Section 2.2.1
   For a formal definition of each term, refer to the references at the end of
   this document.
Without a reference to a specific RFC, this is the type of statement which is not useful: you have 5 pages of references.
You position this document as "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", but you tell the reader: "if you want to know about the terms,
just read first all references!"

9.
You specify some terms and some OAM categories, 
   2.2.2. OAM Maintenance Entities .......................... 13
         2.2.3. OAM Maintenance Points ............................ 14
         2.2.4. Proactive and On-demand activation ................ 15
         2.2.5. Connectivity Verification and Continuity Checks ... 15
         2.2.6. Failures .......................................... 15
... but you don't use them in the section 3

Just one example with section 3.2.2
-
   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      verify the liveness of the session
Instead of liveness, you have defined Connectivity Verification and Continuity Checks in section 2.2.5
- OLD:
   Each of the end-points of the monitored path maintains its own
   session identification
NEW:
   Each of the MEP maintains its own session identification
OR NEW (actually I don't know)
   Each of the MP maintains its own session identification
- OLD
	A BFD echo packet is sent to a peer system
Peer system = MEP, MP, or something else?
- etc... 

10. 
This document is composed of a list of OAM content and references, but I'm really missing the document "scope and target audience".
When we did RFC 6632, which is the companion document, we had http://tools.ietf.org/html/rfc6632#section-1.1
 
   The target audience of the document is, on the one hand, IETF working
   groups, which aim to select appropriate standard management protocols
   and data models to address their needs concerning network management.
   On the other hand, the document can be used as an overview and
   guideline by non-IETF Standards Development Organizations (SDOs)
   planning to use IETF management technologies and data models for the
   realization of management applications.  The document can also be
   used to initiate a discussion between the bodies with the goal to
   gather new requirements and to detect possible gaps.  Finally, this
   document is directed to all interested parties that seek to get an
   overview of the current set of the IETF network management protocols
   such as network administrators or newcomers to the IETF.

You should have something similar.


11.
Section 3.6.1, put the paragraph 2 at the end of the section. The "alternative" in the following sentence would then make sense
   Alternative protocols for performance measurement are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].


My conclusions: this document still needs some work

Regards, Benoit
 
The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'An Overview of Operations, Administration, and Maintenance (OAM)
   Mechanisms'
  <draft-ietf-opsawg-oam-overview-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset that can be used for fault detection and
   isolation, and for performance measurement. OAM mechanisms have been
   defined for various layers in the protocol stack, and are used with a
   variety of protocols.

   This document presents an overview of the OAM mechanisms that have
   been defined and are currently being defined by the IETF.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/


No IPR declarations have been submitted directly on this I-D.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]