[Time] OAM Layering

Qin Wu <bill.wu@huawei.com> Wed, 18 June 2014 07:29 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 949461A0033 for <time@ietfa.amsl.com>; Wed, 18 Jun 2014 00:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.899
X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qDnp6UJidKsK for <time@ietfa.amsl.com>; Wed, 18 Jun 2014 00:29:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13EF1A0022 for <time@ietf.org>; Wed, 18 Jun 2014 00:29:34 -0700 (PDT)
Received: from (EHLO lhreml405-hub.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIO02350; Wed, 18 Jun 2014 07:29:33 +0000 (GMT)
Received: from nkgeml409-hub.china.huawei.com ( by lhreml405-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 18 Jun 2014 08:29:32 +0100
Received: from NKGEML501-MBS.china.huawei.com ([]) by nkgeml409-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 15:29:26 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jan Lindblad <janl@tail-f.com>
Thread-Topic: OAM Layering
Thread-Index: AQHPiscItokL+zdFbEetqEL0ZB6gLA==
Date: Wed, 18 Jun 2014 07:29:25 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8454CEDE@nkgeml501-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA8454B41E@nkgeml501-mbs.china.huawei.com> <539ABB74.3090109@cisco.com> <B8F9A780D330094D99AF023C5877DABA8454BBF2@nkgeml501-mbs.china.huawei.com> <A6BBA24B-BFFD-4B3B-88A3-9C5F85D01693@tail-f.com> <B8F9A780D330094D99AF023C5877DABA8454CE99@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA8454CE99@nkgeml501-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8454CEDEnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/BaJgdDhGJJtwjegXn4bTF0W6XuM
Cc: Benoit Claise <bclaise@cisco.com>, "joelja@bogus.com" <joelja@bogus.com>, Adrian Farrel <adrian@olddog.co.uk>, "time@ietf.org" <time@ietf.org>, Alia Atlas <akatlas@gmail.com>
Subject: [Time] OAM Layering
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jun 2014 07:29:42 -0000

One point to add:
For other common OAM information that occur to my head is performance measurement information
My initial thought about this is:
¨C      Common metrics for Performance measurement
*       Packet Loss
*       Delay
*       Jitter
*       Bandwidth

·¢¼þÈË: Time [mailto:time-bounces@ietf.org] ´ú±í Qin Wu
·¢ËÍʱ¼ä: 2014Äê6ÔÂ18ÈÕ 14:55
ÊÕ¼þÈË: Jan Lindblad
³­ËÍ: Benoit Claise; joelja@bogus.com; Alia Atlas; time@ietf.org; Adrian Farrel
Ö÷Ìâ: Re: [Time] TIME BoF not approved

Hi, Jan:
Thanks for your interesting initial thoughts.
Please see my reply inline below.

·¢¼þÈË: Jan Lindblad [mailto:janl@tail-f.com]
·¢ËÍʱ¼ä: 2014Äê6ÔÂ16ÈÕ 23:20
ÊÕ¼þÈË: Qin Wu
³­ËÍ: Benoit Claise; time@ietf.org<mailto:time@ietf.org>; joelja@bogus.com<mailto:joelja@bogus.com>; Adrian Farrel; Alia Atlas
Ö÷Ìâ: Re: [Time] TIME BoF not approved


Thanks for kicking off this list, and working the IETF processes to move it along. To get the discussion going, I've put down some of my thoughts around this and propose a five layer management stack.

OAM standardization would cover a wide range of concepts, data models, data modeling languages, management and control protocols. Some of these could very well be the same for all domains, vendors, layers, etc. I would say, for example, there is no reason to use a different data modeling language for ethernet switching, mobile backhaul, voip, service chaining or managing the electrical grid.

[Qin]: Exactly. That is one important aspect of management plane OAM consolidation we like to do. Using generic data model and unfied data modeling language can keeping operation complexity and thus OpEx reasonably low.

Some control protocol functionality, on the other hand, probably has to remain different for different layers and domains, at least for use cases off of the beaten path. Ethernet supports a different set of operations/functionality than an IP network or a VLAN. Debugging a disconnect without knowing which one of of the above you are dealing with sounds difficult. Some use cases might be tractable, however. How would you define a single 'ping' operation that applies equally well to each one of these?

[Qin]: Just to clarify, we are not intend to replace all existing data plane OAMs(e.g., Ethernet OAM, IP OAM, MPLS OAM) with technology independent OAM given that these existing data plane OAMs have already had  large deployment. We are not intend to apply IP OAM(e.g., ¡®ping¡¯  operation) to Ethernet network or apply Ethernet OAM operations(e.g., connectivity verification) to IP network. what we are looking for is OAM Consolidation in either data plane or management plane.
We believe in some multi-layer OAM cases, it will be nice to have technology independent OAM. To support technology independent OAM, we may either  enhance BFD protocol or extend protocol header or Done with TLV extension, when we agree to develop these technology independent OAM protocol, we may think integrate Ethernet OAM functionality with IP OAM functionality, e.g., we may have a technology independent OAM protocol that¡¯s support both a subset of erthernet OAM functionalities and a subset of IP OAM functionality.

To decide what common OAM functionalities that need to be supported, it is better to identify all the existing technology dependent OAM and technology independent OAM protocol
and defines the requirements the technology independent OAM protocol needs to meet.

By watering down the concepts sufficiently, it is possible to define abstract operations that work in all the above scenarios. You would get a 'connectivity-verification' operation that can operate on a 'set' of 'endpoints'. Such models exist, e.g. as defined in DMTF's CIM model or TM Forum's GB922/SID. The value and utility of these generic models can be (and often is) debated.

[Qin]:Interesting model, would you like to provide a link to this model or send me  the document about this generic model. What does this model looks like? Is it a data model or something else?

Just because many people do not see these generalization efforts as completely effective, that doesn't mean that it's impossible to find a better balance between generality vs. functionality -- but I do think these examples suggest that it will be pretty hard.

[Qin]: Yes, balance between generality vs. functionality needs to be seeked. But I am not pessimistic about looking for such balance.
My initial thought for this effort is to look for integrate Ethernet OAM functionality and IP OAM functionality into new transport independent OAM protocol.
Alternatively we may look for Common OAM components that can be applied to various technology dependent OAMs protocols, e.g.,
a.Defects Detection
b.Defects Localization
c.Defects information
d.Performance measurement
e.System protections

IMHO the first step we have to take to move towards a layer, domain, vendor, etc -neutral OAM interface is to define the relevant management stack layers. Don't we have enough layers already with the ISO L1-L7? We do, for the transport stack. But I say we don't for management.

[Qin]:Interesting proposal, for the first step, we need to identify in the existing OAM protocol which is technology dependent OAM and which is technology independent OAM?
And then we can figure out what are OAM information common various layer, various domain, various operators and what are common OAM functionality that needs to be supported?

The management stack is also comprised of layers, but they are altogether other layers than the seven (or so) ISO layers. I think the original SDN gurus Casado, Shenker, McKeown, Koponen et al, got a few pieces of this stack right (see for example http://www.slideshare.net/martin_casado/sdn-abstractions slide 39, from 2011). And perhaps a couple of the TM Forum concepts fit into this as well, a bit higher up in the stack (http://www.tmforum.org/ProductsServices/ServiceInventoryManagement/4296/Home.html)

So with this introduction, I propose the following five layer management stack. Maybe we will invent more layers and refine this, so don't take the numbers too literally quite yet. It hasn't been ISO ratified...

M5: "Customer facing service layer"
M4: "Resource facing service layer"
M3: "Network OS layer"
M2: "Device layer"
M1: "Forwarding layer"

The M1 layer provides OpenFlow and similar control interfaces into a device. Many devices don't even have this layer exposed publicly, so you'd have use M2.

[Qin]:I think the Forwarding layer can be further decomposed into transport layer and network layer since one network may use various transport protocol(e.g.,UDP, TCP) and there are various network technologies we can rely on.
Then we have transport layer OAM and network layer OAM, but what we are really looking for is transport independent OAM or technology independent OAM that be built on top of various transport.

So the M2 contains the interface which management systems use to talk to individual devices or OpenFlow/etc controllers. This is where you'd find protocols like SNMP, Command Line Interfaces, NETCONF, and many, many more. I.e. the languages you use to tell a device what to do. While I think it would be technically possible and really valuable to standardize this layer across all domains, layers and vendors, for the foreseeable future I think we will have to live with a major hodge-podge of interfaces and device capabilities.

On the M3 layer, what you get is a uniform interface (API and/or UI) that covers all the managed devices and can execute network-wide transactions. This layer allows applications and operators to execute configuration, monitoring and action tasks across multiple devices, from a mix of domains, layers, vendors. Still the abstraction level is that of the network elements themselves, so whatever configurables, status, actions and notifications they provide, that is what you get here, but without having to worry about the location and protocol to reach the device.

[Qin]: I think both M2 and M3 can provide uniform interface to individual devices or network element It will be great to seek a synergy of M2 and M3 layer or more layers that is above M3 layers.

The M4 layer contains a uniform interface to resource facing services. A service is anything you want to provision in your network, but don't have direct support for in a single device in the network. Some typical services could be VPN, ACL management, or service chaining. Resource facing means that these services are still quite close to the network equipment. Services may also be stacked on each other, so that a VPN service might use a generic router service which in turn maps to equipment of different brands, models and versions.

The M5 layer contains the customer facing services, the ones you as a customer of a service provider find in the price list. E.g. a IPTV customer facing service might consist of three resource facing services: broadband+DNS+DHCP.

Now, in each layer, you'd find a collection of objects that could be read+written (configuration) and read-only (status), executable operations and notifications. All of these should be described in a standardized data modeling language (e.g. YANG, SMI, XSD), so the higher M-layers know what they can access. Ideally a good portion should also be possible to standardize so that it works across domains, layers and vendors. In the proposal submitted by Qin, there are already some proposed generic operations sketched out. Interesting, indeed.


On 13 jun 2014, at 12:34, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:

Hi, Benoit:
Thanks for sharing IAB/IESG concerns to us.
I am glad IAB/IESG agree this is the real problem.
Thanks for your confirming to offer us a chance in the combined OPSAWG/OPS area meeting.
Also Thanks Adrian offer us another chance to present this topic in the RTGWG meeting.
We will keep on working on the proposal and try our best to address issues raised in IESG/IAB.

·¢¼þÈË: Benoit Claise [mailto:bclaise@cisco.com]
·¢ËÍʱ¼ä: 2014Äê6ÔÂ13ÈÕ 16:51
ÊÕ¼þÈË: Qin Wu; time@ietf.org<mailto:time@ietf.org>
³­ËÍ: joelja@bogus.com<mailto:joelja@bogus.com>; Adrian Farrel; Alia Atlas
Ö÷Ìâ: Re: [Time] TIME BoF not approved

Dear all,

As you know (it has been documented at http://trac.tools.ietf.org/bof/trac/ directly after the call on Wednesday), the TIME BoF has not been approved.
It would actually be appropriate for the responsible AD to explain what was discussed during the BoF coordination call, and the reasons why this BoF was declined. So here am I.

First of all, it's true that each time there is a new protocol, engineers jump into the new sand box and create their own unique OAM way.  And there is a  multiplication of slight different ways to perform similar tasks. With my OPS perceptive, performance metrics come to mind. This is an issue.
If we decompose OAM:
    data plane:
        - some part of OAM are embedded and will remain embedded
        - some part of OAM are not embedded: Connectivity Verification (CV), Path Verification and Continuity Checks (CC), Path Discovery / Fault Localization, Performance Monitoring, etc.
        - can we have generic OAM protocol?
     management plane:
        - configuration
So there is possible consolidation here.

It's also true that OAM will be key in a SFC environment. An extra difficulty is that OAM across certain entities might be involving different layers.

The IAB/IESG had the following concerns
- not enough public discussion on the topic
- not enough support, even from the proponents listed on the WIKI
Note: draft-ww-opsawg-multi-layer-oam, posted June 5th, might be one reason.

In conclusion: the problem is real, but we can't conclude there is enough interest and preparation at this point in time.

There is always a big question mark with consolidated management or oam solutions is whether the industry is truly interested in consolidation, or wants to compete with different solutions. This was raised but not discussed as the BoF coordination call objective is to take a decision on granting BoF time, and not to debate the topic).

However, to evaluate interest, we will be allocating time in the combined OPSAWG/OPS area meeting.
Another aspect of OAM sits in the routing area. Discussing with Adrian Farrel, he could try to find some time for you in the routing area or RTGWG meeting.

Regards, Benoit
Our proposed BoF for Toronto called the TIME BoF did not get granted in yesterday IESG and IAB meeting given by insufficient public discussion on the list
and not enough preparation that had been done. Sorry about that.

I have talked with Benoit about possibility to present our idea in the opsawg before IESG and IAB meeting.
We plan to present this topic in the upcoming Toronto meeting, OPS-area and opsawg joint session.
We will keep on working on the drafts we already have.
I have got a lot of messages offline from subscribers on this list and they told me they are very excited about this work initiative.
We expect more discussion on this mailing list.

If you have any proposals, suggestions or good ideas, please don¡¯t hesitate to drop a message on the list or to me directly.



Time mailing list



Time mailing list