Re: [OpenWrt-Devel] [OpenWrt] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT

[Delbar Jos]

Eric, all,

Eric Schultz  wrote:
> I'm excited to see so many people interested in TR-069 support! As a follow up
> to the previous TR-069 email,  I've set up a meeting on TR-069 support for
> OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.

We have prepared a short presentation giving a high level overview of 
Technicolor's proposed TR-069 contribution. It includes an architecture 
diagram, a description of the main components and a few examples and code 
snippets. We can add more detail in the Friday meeting and we are happy to 
review questions up front.

You can grab the PDF at the link below, which will be invalidated in 5 days. 
Can anyone recommend a more permanent place to store this information?

Url : 
https://rdupload.technicolor.com/dl/9f263b37a666282e2368fcbb15e4714f6a7311cc7467cef0
Login : TCH75e8f8
Password : 232IT_5G

Regards,
Jos
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt

[Delbar Jos]

Hauke Mehrtens <ha...@hauke-m.de> wrote:
> On 05/27/2016 01:43 AM, Delbar Jos wrote:
> > At Technicolor we have followed with great interest the recent proposals
> to enhance OpenWrt with an open source solution for TR-069 remote
> management. As one of the world's largest vendors of modems and routers
> for carrier applications, making use of OpenWrt in a significant share of our
> install base, we want to support this initiative in a meaningful way.
> Concretely, we are willing to open source Technicolor's in-house TR-069
> solution and thereby contribute to OpenWrt:
> >  * a TR-069 protocol agent,
> >  * a data model mapping framework that we use to bridge the world of
> > OpenWrt, UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ...
> > (and by extension with the world of SNMP, MIB, NETCONF, YANG ...),
> >  * a set of mappings.
> 
> That is really nice to hear. For me personally it looks like the remote
> management with TR-069 and similar protocols is one of the biggest
> extensions commercial vendors add to the user space of OpenWrt to make it
> fit their needs.
> 
> In addition to the TR-* family does this also include support for SNMP, MIB,
> NETCONF, YANG ?

Our proposal does not include protocol agents for SNMP or NETCONF but it does 
include a data model mapping framework that can be used to bridge between these 
protocols' data models MIB and YANG and an OpenWrt environment. If you compare 
this framework with the slides shown by Felix at the prpl weekly then it's an 
implementation of the "configuration backend", or if you compare it with the 
architecture of a NETCONF project like 
https://wiki.openwrt.org/inbox/howto/opencpe then it's an implementation of 
"mand". (We aren't using mand.)

> That's good to hear, would it also be possible that other interested people
> can join such a workshop?

The answer is yes as far as I'm concerned.

Jos
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt

[Delbar Jos]

Felix Fietkau  wrote:
> > We are conscious of the fact that together with the proposals made by
> > Felix, Luka and Wojtek we are now looking at many "competing" proposals.
> > As a next step, we recommend to organize a workshop, at a practical
> > location and time, where we put everything on the table and define the
> > most appropriate path forward to the benefit of OpenWrt as a whole.
> I think such a workshop would be a great idea. It would be nice to have the
> code available for review some time before that workshop, so we can all take
> a detailed look at the various proposals before we sit down and decide how
> to move forward with this.

I agree that would be helpful. In our case it will take us some weeks before we 
can formally release sources. We will be able to share documentation on 
architecture, API, features, etc. up front to get the discussions going.

Jos
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [OpenWrt] TR-069 for OpenWrt

[Delbar Jos]

Eric,

Sounds good. Please continue scheduling the online meeting in parallel. I think 
we’ll need both.

Jos


From: Eric Schultz [mailto:eschu...@prplfoundation.org]
I think your idea for an in-person workshop is a great idea. While we were 
planning on having a online meeting with the interested parties, I think an 
in-person workshop is an even better idea. There's a lot of potential code on 
the table and related projects to fund. I know from prpl's perspective we want 
to make sure the result is valuable to industry and the community. I don't want 
to put everyone on the spot so I'll contact individually Felix, Luka and Wotjek 
and get their feedback (unless they'd like to comment here). If everyone's in 
agreement, we can work out a time and place that works well for everyone.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] TR-069 for OpenWrt

[Delbar Jos]

David Lang  wrote:
> I wasn't questioning why it's useful to support TR-069. The only part I was
> questioning was the statement that OpenWRT needed work to make it
> support remote management.
> 
> There are already many tools to remotely manage/monitor OpenWRT
> 
> But that's why I'm saying that it seems like most of the work is in the 
> protocol
> interface. If there is already a daemon that does the network protocol
> properly, that should make things very easy. If such a daemon needs to be
> written, that would be the place I would suggest that they focus. There are a
> lot of people who can do the plumbing work to make the daemon do the
> right thing on the system, who are not in a position to work on the network
> protocol side and make sure that it works properly with the management
> software.

Listing some of the things that come to mind:
 * Data models. The language that TR-069 uses to describe a certain feature or 
function is not the same language that OpenWrt uses. The translation is often 
not straightforward.
 * Events/notifications. This boils down to the TR-069 protocol agent notifying 
the ACS when something on the CPE changes. Now imagine that a change occurs to 
a configuration parameter in UCI, like the wireless SSID. How to address this?
 * Commit and apply. When the ACS changes the configuration of the CPE, it also 
expects this configuration to be applied soon after. Updating the configuration 
in UCI is not enough.
 * Transactional behavior. A set of TR-069 configuration changes is either 
applied successfully or not at all. UCI has a commit function but how to check 
if a configuration change in UCI will also be successfully applied by the 
system? Now one can debate what "successful" means but you get the point.
 * Persistent indices. TR-069 expects that a certain object in an array, like 
"the second network interface", retains its index "the second" during the 
lifetime of the CPE (barring a factory reset) even if "the first network 
interface" is deleted. The way that lists work in UCI doesn't make this 
trivial. Using named instances or aliases are possible ways out.

We've attempted to overcome these challenges in our TR-069 solution within the 
confines of OpenWrt. I'm sure that other management systems (local ones like 
LuCi or remote ones) are solving similar problems in different ways. Instead of 
doing all the heavy lifting on the protocol side, I'm hopeful that we can carve 
out a common subset of requirements that apply to management systems in general 
and come to better and more reusable frameworks.

Jos
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] TR-069 for OpenWrt

[Delbar Jos]

Hi all,

At Technicolor we have followed with great interest the recent proposals to 
enhance OpenWrt with an open source solution for TR-069 remote management. As 
one of the world's largest vendors of modems and routers for carrier 
applications, making use of OpenWrt in a significant share of our install base, 
we want to support this initiative in a meaningful way. Concretely, we are 
willing to open source Technicolor's in-house TR-069 solution and thereby 
contribute to OpenWrt:
 * a TR-069 protocol agent,
 * a data model mapping framework that we use to bridge the world of OpenWrt, 
UCI, UBUS ... with the world of TR-069, TR-098, TR-181 ... (and by extension 
with the world of SNMP, MIB, NETCONF, YANG ...),
 * a set of mappings.

We are conscious of the fact that together with the proposals made by Felix, 
Luka and Wojtek we are now looking at many "competing" proposals. As a next 
step, we recommend to organize a workshop, at a practical location and time, 
where we put everything on the table and define the most appropriate path 
forward to the benefit of OpenWrt as a whole.

TR-069 is a complicated remote management system and in order to make this 
initiative a success, we must ensure that the complexity is handled in an 
elegant way and with respect for OpenWrt's core architecture. More than on the 
protocol itself, we believe that we should focus on the architectural 
enhancements required to support remote management in general.

Looking forward to hearing from you.

Jos Delbar & Dirk Feytons
Technicolor
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel