Here are my comments. #1 1.1. The Building Blocks of OAM
An OAM protocol is run in the context of a Maintenance Domain, consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP). %sam - I do not think that, MP, MEP, etc., terminology is used in OAM across different layers. It was introduced in MPLS-TP and later in TRILL, but prior to that, it is not. Is it the authors intention that this new terminology be used going forward? #2 Sec 1.1 - An OAM protocol typically supports one or more of the tools described below. %sam - what is OAM protocol? Shouldn't it be management plane OR OAM tools? #3 Section 1.2 The considerations of the control-plane maintenance tools or the functionality of the management-plane are out of scope for this document, which will concentrate on presenting the forwarding-plane tools that are used for OAM. %sam - Why is it out of scope? For example, checking consistency of control plane to forwarding plane is part of OAM or not? #4 Section 1.3 The set of OAM mechanisms described in this memo are applicable to IP unicast, MPLS, pseudowires, and MPLS for the transport environment (MPLS-TP). %sam - For ex: Is ATM OAM (RFC4717) within the scope of this draft? I did't see any mention of it or FR. I know that they are legacy, but still within IETF. One day even MPLS will be legacy protocol (just saying :D) #5 Over all draft %sam - I do not think this draft even considered 'multicast traffic'. There are rfc's in ever layer supporting multicast. There is no reference I could find. Ex: RFC6450, RFC6425 etc #6 Sec 3.5 %sam - I think it is good to add details on different types of VCCV types of CC and CV and their use. #7 General %sam - Do you consider MIB part of OAM? Does Traps considered as error reporting or fault indication? #8 Sec 3.4.3.8 and 9 %sam - Do these consider actual packet LM and DM or synthetic packets? #9 Section 4 %sam - I think this section should provide more details on what the general security issues are with OAM messages etc. And how they could be mitigated. For in-depth details, one could go into each of those documents. #10 Sec 3.7 I do not think this is complete representation. For ex: no representation of multicast. BFD could be used for RDI, I think. #11 IP Ping and Traceroute %sam - When you say IP ping, does it imply ICMP ping or IP/UDP ping? cheers -sam On Jan 15, 2013, at 6:48 AM, Benoit Claise <[email protected]> wrote: > Some more feedback, send on behalf of Al Morton. > > Regards, Benoit > > ================================================= > Hi Benoit, > > Here are some additional comments, just checking a few things > I know a little about. > > Al > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > 1.1. The Building Blocks of OAM > ... > o Performance Monitoring: > Consists of 3 main functions > > o Loss Measurement (LM) - monitors the packet loss rate of a > connection. > > o Delay Measurement (DM) - monitors the delay and delay > variation between MPs. > > o Throughput measurement - monitors the throughput of a > connection. > > >>> Apparently, no OAM tool currently measures Throughput, > because no such tool is cited in the memo (and the term “throughput” > never appears again). my guess is that there was some reference to > RFC 2544 that has now been removed. Remove Throughput from the list. > > 1.3 OAM Toolsets > ... > o OWAMP and TWAMP: > The One Way Active Measurement Protocol (OWAMP) and the Two Way > Active Measurement Protocols (TWAMP) are two protocols defined in > the IP Performance Metrics (IPPM) working group in the IETF. These > protocols allow delay and packet loss measurement in IP networks. > > >>> and Delay variation, duplication, reordering, etc. (all the metrics > >>> limited tools > completely ignore). > > 1.4 IETF OAM Documents > > >>> Expand Table 1 as noted above, to include all the metrics they missed. > > > 3.6.1 > ... > TWAMP [TWAMP] is a similar protocol that enables measurement of > >>> both one-way and > two-way (round trip) characteristics. > > >>> sentence below is simply not true, because the authors did not understand > the one-way measurement capability: > TWAMP does not require accurate > time of day, and, furthermore, allows the use of a simple session > reflector, making it an attractive alternative to OWAMP. > >>> go back and read the memo... > > > 3.7. Summary of OAM Functions > > Table 3 summarizes the OAM functions that are supported in each of > the categories that were analyzed in this section. > > +-----------+-------+--------+--------+-----------+-------+--------+ > | Standard |Continu|Connecti|Path |Defect |Perform|Other | > | |ity |vity |Discover|Indications|ance |Function| > | |Check |Verifica|y | |Monitor|s | > | | |tion | | |ing | | > +-----------+-------+--------+--------+-----------+-------+--------+ > ... > + --------- + ----- + ------ + ------ + --------- + ----- + ------ + > |OWAMP and | | | | |-Delay | | > |TWAMP | Yes | Yes | | | measur| | > | | | | | | ement | | > | | | | | |-Packet| | > | | | | | | loss | | > | | | | | | measur| | > | | | | | | ement | | > +-----------+-------+--------+--------+-----------+-------+--------+ > Table 3 Summary of OAM Functions > > >>> Both Continuity Check and Connectivity Verification are tested and > confirmed by establishing the *WAMP Control Protocol TCP connection, > so this should be indicated the table. > > >> 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 >>> [email protected] mailing lists by 2013-01-25. Exceptionally, comments may be >>> sent to [email protected] 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. >>> >>> >>> >> >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
