Re: [Time] TIME BoF not approved

[Jan Lindblad <[e-mail]>]

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

On 13 jun 2014, at 12:34, Qin Wu <[e-mail]> 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.
>  
> Regards!
> -Qin
> 发件人: Benoit Claise [mailto:[e-mail]] 
> 发送时间: 2014年6月13日 16:51
> 收件人: Qin Wu; [e-mail]
> 抄送: [e-mail]; 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
> 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
> 
> 
> 
> _______________________________________________
> Time mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/time
>  
> _______________________________________________
> Time mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/time