Re: [OPSAWG] Gen-art last call review of draft-ietf-opsawg-oam-overview-08.txt

[Benoit Claise <[e-mail]>]

Elwyn,

Thanks for your review.
I don't plan to reply for the authors (btw, not sure I've seen a reply 
to this), and but a few clarification questions in line, to engage the 
discussion.

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-opsawg-oam-overview-08.txt
> Reviewer: Elwyn Davies
> Review Date: 22 Jan 2013
> IETF LC End Date:25 Jan 2013
> IESG Telechat date: (if known) -
>
> Summary: In my opinion, this draft has serious issues as described
> below.
>
> Major issues:
> General 1: Title vs Abstract vs Section 1 vs actual content:
>
> Here in the UK a well-known brand of varnishes and wood preservative
> paints uses the slogan 'Does what it says on the tin!'.  If my
> understanding and the write-up in RFC 6491, OAM covers a whole lot more
> than the coverage of the specific mechanisms discussed in this
> document .. and there are various other mechanisms such as SNMP and
> Netconf that support the OAM constellation.
Can you provide an example of what you mean here?
Do you mean that SNMP (and NETCONF) can be used to monitor the OAM results?

> I would take the view that
> this document certainly does not 'do what it says on the tin'.
> Accordingly I take issue with the title as it doesn't provide a total
> overview of OAM mechanisms; the abstract closes down the scope of OAM as
> compared with RFC 6491 and s1 restricts it even more - and certainly
> does not summarize all the OAM tools and mechanisms defined in the IETF.
> The last para of s1 claims that 'management aspects are outside the
> scope of this document' - if this is really saying that this 'overview'
> of OAM skips the whole M aspect of OAM then I'm afraid the document is
> badly misnamed.  And it significantly reduces the value of the work.
Ok, the document title could be improved.
>
> General (2): The intended purpose of this document: Back in 2011 Stewart
> Bryant summarized a review of a previous version of this document from
> the routing directorate
> (https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/history/ entry dated 2011-08-10 referring to version 05 of the document).  IMO the initial section of that review regarding the audience of this document was well targeted and *has not been fixed*.  If this is intended as an introductory overview for people wishing to see what OAM is about in the IETF then it needs further introductory text and some background.  It should also state what its target audience actually is.
This sentence was added:

       The target audience of this document includes network equipment
        vendors, network operators and standard development organizations,
        and can be used as an index to some of the main OAM tools defined in
        the IETF.

And section 1.2


      1.2
      <http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-13#section-1.2>.
      Target Audience



    The target audience of this document includes:

    o Standard development organizations - both IETF working groups and
       non-IETF organizations can benefit from this document when
       designing new OAM protocols, or when looking to reuse existing OAM
       tools for new technologies.

    o Network equipment vendors and network operators - can use this
       document as an index to some of the common IETF OAM tools.

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


Please let the authors know what you would like to see.

I let the authors/doc. shepherd answer the following points.

Regards, Benoit
>
> General (3): I don't know if Scott Bradner has actually produced a proto
> shpeherd write up, but I would be intrigued to know the level of
> concensus behind this document.  In particular the tool classification
> in s1.1 and terminology in s2 (particularly s2.2.2) is that used
> exclusively in the MPLS-TP work in the IETF which is derived from the
> 802.1ag terminology.  The terminology is presented as if it is common to
> OAM work across the IETF. Does the IETF management community at large
> concur with this expansion of the applicability of the terminology set
> based on 'Management Domains' etc?
>
> General (4): As an overview, I think it would be advisable to point out
> that one reason for the multiplicity of tools is that they support at
> least four different data plane technologies (native IP, vanilla MPLS,
> MPLS-TP and PWE) and note that in several cases the data plane
> technologies rely on distinct (IP-based) management channels to allow
> the information gleaned by the operations in the the data plane to be
> reported back to the application that originated the operation.
>
>
> Minor (or at least less major) issues:
>
> s1, para1: For consistency with  the abstract, s1.1 .. and because I'd
> expect OAM to handle it as well ... OAM deals with performance
> monitoring and statistics gathering as well as dealing with degradation.
>
> s1.1: The section is entitled building blocks but actually only mentions
> one block, i.e., the OAM protocol.  Presumably this section really ought
> to say something about the applications and device drivers that have to
> instantiated in the MPs.  In particular as introduction to the text in
> the following section it should say something about classifying
> applications into continuously running or proactive monitoring and
> on-demand applications (since the latter are introduced without any
> definition in the next section.)
>
>
> s2.2.2/3: I am not familiar with 802.1 management issues and I was
> rather confused by the logical status of MIPs .  The text here seems to
> indicate that they are intermediate and generally don't terminate
> messages but then says in s2.2.3 that messages are 'destined to' MIPs.
> Looking for some additional understanding, I fetched up at Wikipedia
> (now there's a surprise) http://en.wikipedia.org/wiki/IEEE_802.1ag.
> This page mentions the concept of maintenance domains and the
> explanation of MIPs as internal points in the domain that generally
> forward messages within the domain whereas end points (MEPs) are
> effectively on the domain boundary. This makes a whole lot more sense
> and seemed to be a rather better set of term definitions than we have in
> this draft.
> I noticed eventually that the term Management Domain (MD) had appeared
> in the first line of s1.1 but does not appear in s2 at all. If we are
> going to accept the Management Domain terminology set, then MD certainly
> ought to be defined and discussed here.
>
>
> s2.2.3, para1, sentence 1:
>>    either initiates or reacts to OAM messages.
> The following sentences contradict this.  Should be 'initiates and/or
> reacts to OAM messages'.  See comment above.
>
> s3, general: The level of detail regarding the various toolsets is not
> very even.  In particular, the MPLS-TP toolset gets significantly more
> attention than others and the detail in OWAMP/TWAMP may be more than is
> desirable for an overview.
>
> s3.1: A few words about the likely suppression of pings and traceroute
> messages due to ICMP filtering is probably desirable as these limit
> their usefulness in the wider Internet.
>
> s3.3: What about RFC6374 (MPLS packet loss measurement)? It appears in
> the list in s1.4 but is not mentioned here.
>
> s3.4.1: Talking about what the MPLS working group 'is currently doing'
> will not be helpful for an archival document.
>
> s3.4.3.1: The OnDemand-CV reference is for non-TP MPLS... do you mean
> RFC 6426 which appears to be the TP variant?
>
> Nits/editorial comments:
> General: For a reader who wants to go on and look at the RFCs that
> define the various tools, it would probably be helpful to use reference
> tags that  either are or include the RFC number.
> s1.3, para 2: s/in several fronts/covering several different approaches/
>
> s2.2.2, last para: Need to expand 'p2mp'.
>
> s3.4.3.8: Should this section reference RFC6375?
>
> s3.5.1: It appears that the basic AC acronym (associated channel) is not
> defined.
>
>