Dear all,

In agreement between OPS ADs and the WG chairs, I'm resending 
draft-ietf-opsawg-oam-overview to the WG, for further work.
This document was sent to the IESG in August 2011.

The authors received a lot of feedback (150 if I'm not mistaken), mainly 
from the directorates and the IESG.
Some of this feedback relates to basic comments, such as the 
definitions. This leads me to think that the WG has not spent enough 
time reviewing the document.
On top of that, see 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview/ballot/
Based on this ballot half the positions are held by people who aren't on 
the IESG anymore.

This will probably arrive as a bad news, but my highest priority is 
document quality.

Here is also some background information, outcome of the IESG retreat
http://www.ietf.org/mail-archive/web/ietf/current/msg79194.html

    1. Send more documents back to the WG to complete the necessary changes. While the responsibility for changes has always been at the WG, the documents were still in the IESG process. The IESG felt that particularly in situations where changes are large or multiple, it would be useful to make the situation about WG ownership even clearer. We will do this by handing the document back to the WG and getting the IESG out of the loop, with the instruction that the chairs should manage the process and address the issues raised in the IETF last call and by the ADs.


Regards, Benoit (OPS AD)

> Hi Benoit, Joel,
>
> We have done quite a bit of work on this draft lately, and I believe 
> we are steadily moving towards convergence.
>
> Following Stewart's comments we have ~5 open issues, which I believe 
> can be resolved with a bit of work.
>
> Assuming we resolve Stewart's comments, how would you suggest to proceed?
>
> Thanks,
> Tal.
>
> *From:*Stewart Bryant [mailto:stbryant@cisco.com]
> *Sent:* Friday, September 20, 2013 3:24 PM
> *To:* Tal Mizrahi
> *Cc:* Benoit Claise
> *Subject:* Re: Mail regarding draft-ietf-opsawg-oam-overview
>
> Hi Tal,
>
> Next week is not the greatest week, as I am quite busy, but we should 
> be able to get some time morning or early afternoon 30th. Will this be 
> just with you, or are you also inviting your co-authors?
>
> However, so that we do not waste our time, can I suggest that you 
> first talk to your AD to see how they wishes to progress the draft.
>
> - Stewart
>
>
> On 20/09/2013 11:59, Tal Mizrahi wrote:
>
>     Hi Stewart,
>
>     Sorry for nagging, but it would be great if we could have a short
>     call early next week.
>
>     Thanks,
>     Tal.
>
>     *From:*Tal Mizrahi
>     *Sent:* Wednesday, September 18, 2013 12:06 AM
>     *To:* 'stbryant@cisco.com <mailto:stbryant@cisco.com>'
>     *Subject:* RE: Mail regarding draft-ietf-opsawg-oam-overview
>
>     Hi Stewart,
>
>     Thanks for your responses.
>
>     I am switching to unicast mode, as I think it will be more effective.
>
>     In the next few days I am going to do some further work following
>     your comments, and if it is okay with you I would like to do a
>     phone/Webex 1:1 meeting with you, to make sure we have addressed
>     your concerns. I think we can save a lot of back-and-forth emails
>     with a short conversation.
>
>     Wednesday-Friday are a holiday in Israel, but would you be
>     available on Monday morning for phone/Webex?
>
>     In the meantime, just a couple of clarification questions:
>
>     >>and a devolved application specific control plane function
>     >What is one of those?
>
>     Stewart, sorry but I could not understand the comment. Did you
>     mean that we should add an example of an application specific
>     control plane function?
>
>     >>>FRR is, at least within the ITU definition and OAM function. There
>     >>>is BTW no discussion of the network repair class of OAM function
>     >>>in this text. Now it is OK if you make it clear that you are only
>     >>>dealing with the network instrumentation OAM class, but you need
>     >>>to say so.
>
>     >>Network repair functions such as Fast Reroute (FRR) and
>     protection switching, which are often trigger by >>OAM protocols,
>     are also out of the scope of this document.
>
>     >That is a cop out. You need to deal this in terms of the various
>     definitions of OAM. Particularly as you >talk about the ITU
>     definitions of OAM.
>
>     I am not sure I understand "as you talk about the ITU definitions
>     of OAM". In an older version of this document there was an
>     overview of some of the ITU OAM mechanisms, but we were asked not
>     to survey non-IETF protocols in this document, so we just briefly
>     mention ITU related issues whenever it is necessary.
>     Do you mean section "2.2.7 Failures"?
>
>     Regards,
>
>     Tal.
>
>     *From:*Stewart Bryant [mailto:stbryant@cisco.com]
>     *Sent:* Tuesday, September 17, 2013 4:31 PM
>     *To:* Tal Mizrahi
>     *Cc:* nurit.sprecher@nsn.com <mailto:nurit.sprecher@nsn.com>;
>     wyaacov@gmail.com <mailto:wyaacov@gmail.com>;
>     ops-ads@tools.ietf.org <mailto:ops-ads@tools.ietf.org>; Adrian
>     Farrel; Benoit Claise; joel jaeggli;
>     draft-ietf-opsawg-oam-overview@tools.ietf.org
>     <mailto:draft-ietf-opsawg-oam-overview@tools.ietf.org>
>     *Subject:* Re: Mail regarding draft-ietf-opsawg-oam-overview
>
>     On 16/09/2013 23:07, Tal Mizrahi wrote:
>
>         Hi Stewart,
>
>         Thanks. We appreciate your comments, and hope to publish this
>         document soon.
>
>         Following your comments I am attaching an updated draft in
>         which we tried to resolve the comments you sent, with the
>         exception of the comments I am responding to below.
>
>         We intend to work hard to resolve all the pending comments and
>         hopefully publish this document soon.
>
>         If you have any comments about the updated draft, we will be
>         more than happy.
>
>         >Related to the above something that the RTG Reviewer brought up
>
>         >before was the issue of connection oriented vs connectionless
>
>         >paths. I think that you have responded by deleting all references
>
>         >to this, but in reading the draft I think that there really needs to
>
>         >be a discussion on CO vs CL and P2P vs P2MP vs MP2MP since
>
>         >these all have a major impact on what you need from an OAM
>
>         >and how you design the OAM. Indeed many of the differences
>
>         >in OAM design stem from these three network differences.
>
>         As you point out, there was some text about this in previous
>         versions of the document, but the RTG reviewer did not agree
>         with this text. We believed that it would be best to remove
>         this text, but now if we bring it back it may be controversial
>         again. Sorry, but I am running out of ideas here.
>
>         If you could help us out and provide some text here, that
>         would be great.
>
>
>     This was the comment:
>
>     3.   OAM in connectionless vs. connection-oriented networks:
>
>       
>
>     a. (2a) above suggests that OAM is applicable only
>
>     to connection-oriented networks (if you do not have
>
>     connections, connection problems do not exist by definition)
>
>       
>
>     b. At  the same time, the draft discusses ICMP Ping
>
>     (Section 4.1) operating in connectionless IP networks,
>
>     and Ethernet OAM (Sections  4.7 and 4.8) operating
>
>     in connectionless Ethernet networks.
>
>       
>
>       The authors should define the scope of OAM explicitly
>
>     and clearly - and then remove the sections dealing with
>
>     protocols and mechanisms that happen to be out of this
>
>     scope. In particular, explaining the relationship of
>
>     each specific defect to a specific networking plane.
>
>
>     I think that you need at  a section describing the
>     CL vs CO issues, noting that a Session is a type of
>     CO environment, noting  what is easy and what
>     is difficult in each case and noting the approaches used.
>
>
>     >I found your definition of "OAM Function" quite confusing - are
>
>     >you defining the function of OAM or the definition of an OAM function.
>
>     >I think that was looking for some text of the form "An OAM function
>     is...."
>
>     Indeed, a couple of lines later you will find the text "OAM
>     functions are the atomic building blocks of OAM, where each
>     function defines an OAM capability."
>
>     I gave this specific item in the document more thought than one
>     would expect, and here is what I came up with:
>
>     The term "OAM function" is pretty self-explanatory, and I cannot
>     think of a one-sentence definition that clarifies it more than the
>     two words "OAM function". Hence, we refer to it as an "atomic
>     building block", such that OAM **is defined** by the set of OAM
>     functions, and not vice versa. That is why I found it most
>     suitable to quote the OAM definition from the ATM Forum glossary
>     which says that "OAM is a group of functions that...".
>
>
>     That text does not work either.
>
>     Are you defining the function of OAM, or an OAM function?
>
>
>     >"The Data Plane is typically described as the hardware and software
>
>     >components responsible for receiving a packet..."
>
>     >There needs to be something about sending packets!
>
>     Indeed, the rest of the sentence continues with "...and forwarding
>     the packet out through the appropriate outgoing interface".
>
>     Again, I put quite a bit of effort into looking for the right
>     definitions of 'data plane' and 'control plane'. These terms are
>     so commonly used that nobody even thinks about defining them. I
>     finally found and quoted this definition from RFC 6192, which is
>     based on IETF consensus (I hate to use the IETF consensus card,
>     but it is what it is).
>
>     I really do not think that is a productive approach to the problem
>     at hand.
>
>     A document only has consensus in its own context.
>
>     I just grepped rfc6192 and it only has one instance of the term
>     "data" and that is the prefix of "datagram".
>
>     So that's not the right reference, and even if it were a suitable
>     reference, the title might explain why it does not talk about sending.
>
>     So you need to find a suitable definition for DP.
>
>
>     >"The Control Plane, as described in [Cont], is generally described as
>
>     >the hardware and software components for handling packets destined to
>
>     >the device itself as well as building and sending packets originated
>
>     >locally on the device."
>
>     >Do you mean the OAM control plane, or the network control plane.
>     This is
>
>     >certainly not the definition of the network control plane.
>
>     This definition refers to the network control plane, and once
>     again, is based on RFC 6192. I don't want to use the IETF
>     consensus card again, but I am certainly open to other suggestions
>     (hoping that this doesn't open a whole new thread/DISCUSS ...).
>
>     I think that you need to start by reading and answering my question.
>
>     Looking at the changes;
>
>     and a devolved application specific control plane function
>
>     What is one of those?
>
>
>     Network repair functions such as Fast Reroute (FRR) and protection
>     switching, which are often trigger by OAM protocols, are also out
>     of the scope of this document.
>
>     That is a cop out. You need to deal this in terms of the various
>     definitions of OAM. Particularly as you talk about the ITU
>     definitions of OAM.
>
>     Paris Traceroute is an extension to Traceroute that discovers all
>     the available paths from A to B by scanning different values of
>     header fields (such as UDP ports) in the probe packets.
>
>     Really? maybe you mean "attempts to discover"?
>
>     Conversely, MPLS-TP OAM does not use ECMP
>
>     It is MPLS-TP that does not support ECMP
>
>
>     Thanks,
>
>     Tal.
>
>     *From:*Stewart Bryant [mailto:stbryant@cisco.com]
>     *Sent:* Monday, September 16, 2013 6:13 PM
>     *To:* draft-ietf-opsawg-oam-overview@tools.ietf.org
>     <mailto:draft-ietf-opsawg-oam-overview@tools.ietf.org>
>     *Cc:* ops-ads@tools.ietf.org <mailto:ops-ads@tools.ietf.org>;
>     Adrian Farrel
>     *Subject:* Mail regarding draft-ietf-opsawg-oam-overview
>
>     As requested I have taken a look at this draft, and it is much
>     improved.
>
>     There are however a few things that still need be looked at. Please
>     see below.
>
>     A note to the responsible AD - what are your plans for this document
>     and what is it state? If I look at the draft, I see I hold a
>     discuss on it
>     but if I look at my discuss list it does not show.
>
>     =======
>
>     Something I did not see, but which I found very useful in
>     understanding
>     OAM is to consider it as providing two functions, and instrumentation
>     function, and a devolved application specific control plane function.
>     FRR is, at least within the ITU definition and OAM function. There
>     is BTW no discussion of the network repair class of OAM function
>     in this text. Now it is OK if you make it clear that you are only
>     dealing with the network instrumentation OAM class, but you need
>     to say so.
>
>     =======
>     It would really help the reader if you sorted the references, I spent
>     quite a while hunting through the paper copy I used to review the
>     text
>     to find a couple of references.
>
>     =======
>     " OAM typically has a multi-layer architecture; each transport
>     technology
>     has its own OAM mechanisms"
>
>     I think that networks have the multi-layer arch, not the OAM
>
>     =======
>     A major topic that you have not addressed is ECMP which although
>     addressed at some complexity in MPLS is not addressed in IP and
>     can lead to false negatives. This is important in a number
>     of dimensions, not the least of which is fate sharing.
>
>     Related to the above something that the RTG Reviewer brought up
>     before was the issue of connection oriented vs connectionless
>     paths. I think that you have responded by deleting all references
>     to this, but in reading the draft I think that there really needs to
>     be a discussion on CO vs CL and P2P vs P2MP vs MP2MP since
>     these all have a major impact on what you need from an OAM
>     and how you design the OAM. Indeed many of the differences
>     in OAM design stem from these three network differences.
>
>     It might also be worth some text somewhere on the hw
>     vs sw tradeoffs that impact OAM design which accounts for
>     some of the differences.
>
>     =========
>
>     I found your definition of "OAM Function" quite confusing - are
>     you defining the function of OAM or the definition of an OAM function.
>     I think that was looking for some text of the form "An OAM
>     function is...."
>
>     ========
>
>     "The Data Plane is typically described as the hardware and software
>
>     components responsible for receiving a packet..."
>
>       
>
>     There needs to be something about sending packets!
>
>       
>
>     ============
>
>       
>
>     "The Control Plane, as described in [Cont], is generally described as
>
>     the hardware and software components for handling packets destined to
>
>     the device itself as well as building and sending packets originated
>
>     locally on the device."
>
>       
>
>     Do you mean the OAM control plane, or the network control plane. This is
>
>     certainly not the definition of the network control plane.
>
>       
>
>     ============
>
>       
>
>     "and hence it is imperative to have fate-sharing between OAM
>
>         traffic and the data plane traffic it monitors."
>
>       
>
>     It is a lot more complicated than that. Some elements of the
>
>     OAM need to fate share, but by no means all. Specifically
>
>     it is only required that measurement packets of some types
>
>     fate share, but there is a lot more to OAM than that.
>
>       
>
>       
>
>     ============
>
>     "take after" is slang
>
>       
>
>     ============
>
>       
>
>     "'Ping' is an abbreviation for Packet internet groper"
>
>       
>
>     I am sure that was a contrived definition, and in any case given the
>
>     common meaning of the term groper, if this were my text, I would
>
>     finesse the name.
>
>       
>
>     =============
>
>       
>
>     In IP traceroute, you really need to talk about ECMP as well as
>
>     path asymmetry.
>
>       
>
>     =============
>
>       
>
>     In the section on LSP ping/traceroute, you really need text to help the reader
>
>     understand the ECMP issue and how it gets the packet back to the sender.
>
>       
>
>     You may wish to note how this contrasts with how MPLS-TP does it.
>
>     =============
>
>       
>
>     You have some discussion on one way packet delay measurement. That really
>
>     needs some supporting text on the issue of time synchronization. In the
>
>     two way, some warning about OW != TW/2 is called for due to path asymmetry.
>
>       
>
>     ============
>
>       
>
>     In your discussion on PW OAM a reference todraft-ietf-pwe3-vccv-impl-survey-results-02  <http://datatracker.ietf.org/doc/draft-ietf-pwe3-vccv-impl-survey-results/>
>
>     may be beneficial to the reader.
>
>       
>
>     ============
>
>       
>
>     You talk about ECMP in the context of TRILL as if it is novel to TRILL
>
>     this is not the case, and indeed is consider in the case of MPLS
>
>       
>
>     ============
>
>       
>
>     - Stewart
>
>       
>
>       
>
>       
>
>       
>
>       
>
>
>
>
>     -- 
>
>     For corporate legal information go to:
>
>       
>
>     http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>       
>
>
>
>
> -- 
> For corporate legal information go to:
>   
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>