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

[Sam Aldrin <[e-mail]>]

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 <[e-mail]> 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
>>> [e-mail] mailing lists by 2013-01-25. Exceptionally, comments may be
>>> sent to [e-mail] 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.
>>> 
>>> 
>>> 
>> 
>