TST decisions on Device Management

[Saurav Das]

Hi all,

The SEBA/VOLTHA TST debated Device Management (DM) related topics discussed in last week's TST call. Here is the outcome

------------------------------

On the question of whether DM belongs in SEBA/VOLTHA

There are some concerns in the TST that, while this work is clearly of importance to the operators, should it be a concern of the SEBA/VOLTHA open-source community or ONF?

The concern is that device management, or element-management via a "common EMS across vendors" can quickly become a burdensome and unwieldy task that can bog down the community and progress on other fronts. Also there are no components in SEBA/VOLTHA that require this capability, making it somewhat orthogonal to our current focus.

Nevertheless given that it is 

• an operator need, and 
• there is a perception that SEBA as a solution is incomplete without some form of DM, and that 
• ONF has been asked similar questions in other projects (eg. Stratum) from non-SEBA operators

TST has decided to move forward and include DM in SEBA in a limited form as detailed below.

On the question of DM interface schema being RFC 8348 or Redfish

TST feels that while both are good options and can easily meet the current needs of the operators, 

RFC 8348 can be simpler and easier to establish as a generic api.

TST decision:

• RFC 8348 yang modules ietf-hardware and iana-hardware are accepted for DM interfaces expressed in grpc protobufs (ie not xml encoded for use with netconf)
• While the existing yang module can be extended, there will be no generic extensions (eg. strings for whatever you want to get) or vendor-specific extensions 
• The intent is to have a generic api for a minimum set of hardware-components. If a vendor cannot meet this minimum set, it will fail certification

On the question of priorities and resources

TST believes DM is not of highest priority, and it's main concerns remain with the pon-management and control side (voltha stack)

TST also believes that community resources are better spent on the control stack

With that in mind

TST decision:

• We are only defining and building an interface (over gRPC) to the DMs. Discussions can be made in a DM-brigade and brought to TST for approval
• Protobuf definitions can be hosted in ONF repos. However, the DM GRPC protos should not be part of voltha protos nor should the end point be implemented in a voltha container.
• Test harness can be built around defined hardware-components in the interface (fans, power-supplies etc)
• TST and the community take no responsibility for building DMs. This is vendor responsibility

On the question of overlap with VOLTHA responsibilities vs DM responsibilities

While there is little overlap between VOLTHA's PON-management responsibilities and DM's device-management responsibilities for OLTs, there is still one case

of overlap -- ports and the device itself. Ports can be enabled/disabled by both. Port-statistics can be accessed by both. OLTs can be disabled/rebooted by both.

In general, TST would like to avoid multiple ways to do the same thing, or have multiple identifiers for the same resource.

This requires further investigation and the decision is postponed. 

Decisions on related discussion topics like the behavior of 'get' api-calls and harmonizing events published to kafka by Voltha and DM are also postponed.

Thanks

Saurav

[Saurav Das]

Folks,

A quick follow up. TST has appointed Andrea Campanella as Brigade Lead for the DM-Interface Brigade

Details to follow

Thanks

Saurav

[Andrea Campanella]

I’ll avoid the mailing list then and post meeting reminder on the `voltha-discuss` email. 

I’ll follow up right now with meeting details. 

Thanks, 

Andrea Campanella

Member of Technical Staff at ONF
Member of ONOS Technical Steering Team
Member of Ambassador Steering Team, ONOS and CORD Community

-- 
You received this message because you are subscribed to the Google Groups "SEBA Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seba-dev+u...@opennetworking.org.
To view this discussion on the web visit https://groups.google.com/a/opennetworking.org/d/msgid/seba-dev/CAJzs%3D6eWPxH5yo%3Dr8bJj8t6s4ToO4jXFjassGjUbP06uda-LaA%40mail.gmail.com.

[Manue...@telekom.de]

Congratulations, Andrea!

 

Best,

Manuel

--

[Andrea Campanella]

Hi All,

Thanks Saurav and the TST for the opportunity.

We will have a weekly call for the Device Management Interface brigade Friday 8-9 AM PST/5-6 PM CET. 

That call will start Friday 29/05 with a kickoff meeting.

We will use the same method of rolling agenda. 

You can find the agenda here

https://docs.google.com/document/d/16CIUUWGfYv9UGT4LxXuHHDvu1q9J4PYowlpijqL27F4/edit

Add any elements that you’d like to discuss. 

Please note that I’ve created a Slack Channel: https://opencord.slack.com/archives/C013YBT0VBP 

Hope to see you there. 

Thanks, 

Andrea Campanella

Member of Technical Staff at ONF
Member of ONOS Technical Steering Team
Member of Ambassador Steering Team, ONOS and CORD Community

On 20 May 2020, at 18:12, Saurav Das <saura...@opennetworking.org> wrote: