Re: [Time] OAM Initiative: Situation

Qin Wu <> Tue, 09 September 2014 03:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A735E1A048F for <>; Mon, 8 Sep 2014 20:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.402
X-Spam-Status: No, score=-3.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zaL1XUd1VMJF for <>; Mon, 8 Sep 2014 20:33:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5FFF1A0415 for <>; Mon, 8 Sep 2014 20:33:30 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BJF13812; Tue, 09 Sep 2014 03:33:29 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 9 Sep 2014 04:33:28 +0100
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Tue, 9 Sep 2014 11:33:23 +0800
From: Qin Wu <>
To: Benoit Claise <>, "" <>
Thread-Topic: [Time] OAM Initiative: Situation
Thread-Index: AQHPyzsV5leRXFyR6UG18J0dy3VbNZv4JEaA
Date: Tue, 9 Sep 2014 03:33:22 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA845C151Bnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "" <>
Subject: Re: [Time] OAM Initiative: Situation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Sep 2014 03:33:33 -0000

Thank Benoit and Joel for the update of the current status.
“OAM initiative” is a good name, I think.
It remind me IESG/IAB arranged a Joint Design Session on Forwarding Plane OAM
Before to discuss tunneled forwarding plane OAM,

However the scope of this design session is limited to the forwarding plane. Proposals concerning
On control/management plane was not touched.

Even this, some of their proposal matches what we proposed in the PS draft right now, .e.g.,
In draft-bonica-oam-considerations-00, it said:
The API should insulate the user application from the following

      - The procedure that the OAM mechanism employed to obtain OAM

      - Whether the OAM mechanism is integrated into the lower layer

发件人: Time [] 代表 Benoit Claise
发送时间: 2014年9月8日 16:01
主题: [Time] OAM Initiative: Situation

Dear all,

[Let us call this "OAM Inititiave" for now, as the mailing list is being renamed from TIME to LIME]
During the last IETF meeting, there were various discussions with different audiences regarding OAM.

Here is what we concluded:
1. Building an OAM generic protocol is impractical for multiple reasons.
2. It is desirable to have an unified view of OAM information at each layer, in order to correlate information, and detect the faulty element in the network path
3.. Consistent configuration, reporting, and presentation for the OAM mechanisms makes sense.
4. Using YANG as a modeling language is a logical choice. Note that there are already some efforts in that direction
5. A set of guidelines for future OAM developments would be welcome for consistency sake
We also believe that there is sufficient interest to start working on a charter proposal.
Regards, Joel and Benoit (OPS ADs)

*         We should preserve the existing OAM technology implementations and behavior “on-the-wire”

*         We will propose a unified management interface for multiple OAM technologies that will expose a common set of management interface capabilities for different OAM technologies (e.g. ping, traceroute)

*         The management interface implementation will convert the defined common management capabilities to the OAM technology specific operations

*         We will model OAM operations management using YANG following

*         Specific OAM technology models will augment the generic OAM management model

*         Cisco will support continued development of technology specific OAM standards within the appropriate IETF technology working groups

*         We will promote generic OAM in the IETF OPS Working Group

*         We will propose a set of guidelines new OAM technology implementations should follow
*         We will investigate methods for scaling the return of large volumes of OAM data from the network