Subject: [Time] TIME BoF not approved

From: Qin Wu <[email-masked]>
Date: Thu, 12 Jun 2014 04:02:58 +0000

Hi,
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.

Regards!
-Qin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Jun 2014 10:51:00 +0200

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
>
> Hi,
>
> 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
>
> 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.
>
> If you have any proposals, suggestions or good ideas, please don't 
> hesitate to drop a message on the list or to me directly.
>
> Regards!
>
> -Qin
>
>
>
> _______________________________________________
> Time mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/time

---

From: Loa Andersson <[email-masked]>
Date: Fri, 13 Jun 2014 11:34:11 +0200

Benoit,

> Fault Localization, Performance Monitoring, etc.

Isn't it a further problem that what is embedded for one data-plane
technology might no be it for another?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Jun 2014 10:18:43 +0000

Hi, Loa:
I think it is up to whether we need technology specific OAM or technology independent OAM.
Whether data plane technology is technology specific OAM or technology independent OAM,
It always can have a unified management plane, e.g., generic Yang Data model.
It is orthogonal what data plane technology is used.

Regards!
-Qin
-----邮件原件-----
发件人: Time [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2014年6月13日 17:34
收件人: [email-masked]
主题: Re: [Time] TIME BoF not approved

Benoit,

On 2014-06-13 10:51, Benoit Claise wrote:
>          - some part of OAM are not embedded: Connectivity 
> Verification (CV), Path Verification and Continuity Checks (CC), Path 
> Discovery / Fault Localization, Performance Monitoring, etc.

Isn't it a further problem that what is embedded for one data-plane technology might no be it for another?

/Loa

--

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Jun 2014 10:34:05 +0000

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.

Regards!
-Qin
发件人: Benoit Claise [mailto:[email-masked]]
发送时间: 2014年6月13日 16:51
收件人: Qin Wu; [email-masked]
抄送: [email-masked]; 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.

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
Hi,

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

Regards!
-Qin

Time mailing list

[email-masked]<mailto:[email-masked]>

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 16 Jun 2014 17:20:18 +0200

Qin,

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.

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?

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. 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.

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.

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.

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.

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.

/Jan

---

From: Qin Wu <[email-masked]>
Date: Wed, 18 Jun 2014 06:55:29 +0000

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

Regards!
-Qin
发件人: Jan Lindblad [mailto:[email-masked]]
发送时间: 2014年6月16日 23:20
收件人: Qin Wu
抄送: Benoit Claise; [email-masked]; [email-masked]; Adrian Farrel; Alia Atlas
主题: Re: [Time] TIME BoF not approved

Qin,

[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.

[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

[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?

[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.

[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.

/Jan

On 13 jun 2014, at 12:34, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Benoit:

Regards!
-Qin
发件人: Benoit Claise [mailto:[email-masked]]
发送时间: 2014年6月13日 16:51
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>; Adrian Farrel; Alia Atlas
主题: Re: [Time] TIME BoF not approved

Dear all,

Regards, Benoit
Hi,

Regards!
-Qin

Time mailing list

---

From: Qin Wu <[email-masked]>
Date: Wed, 18 Jun 2014 07:29:25 +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:
–      Common metrics for Performance measurement
*       Packet Loss
*       Delay
*       Jitter
*       Bandwidth

Regards!
-Qin
发件人: Time [mailto:[email-masked]] 代表 Qin Wu
发送时间: 2014年6月18日 14:55
收件人: Jan Lindblad
抄送: Benoit Claise; [email-masked]; Alia Atlas; [email-masked]; Adrian Farrel
主题: Re: [Time] TIME BoF not approved

Hi, Jan:

Regards!
-Qin
发件人: Jan Lindblad [mailto:[email-masked]]
发送时间: 2014年6月16日 23:20
收件人: Qin Wu
抄送: Benoit Claise; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Adrian Farrel; Alia Atlas
主题: Re: [Time] TIME BoF not approved

Qin,

/Jan

Hi, Benoit:

Regards!
-Qin

Dear all,

Regards, Benoit
Hi,

Regards!
-Qin

Time mailing list