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: 6.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. 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 consistent7. 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. |