[freeside-devel] Broadband Services Spec

[Kristian Hoffmann]

On Wed, 2007-06-27 at 18:55 -0400, Jeff Finucane wrote:

>    The more I look at it, the more they seem to be conceptually the same.
> Both objects are a piece of equipment which may be associated with exports,
> may be layer2, layer3, both, and have associated physical and logical address
> information.  The primary differences are the name of the customer, the
> "edginess," and the relative permanence.  In the case of the NAS device,
> the ISP/freeside operator is the implied customer whereas with the
> svc_broadband it is explicitly associated with a cust_main record through
> cust_svc and cust_pkg.  The NAS may very well be a different model from
> the non-NAS, and have different exports.  This is true for any two
> svc_broadband records.
>
>    Placing nas information in svc_broadband records is analogous to placing
> svc_domain records on a 'system' customer representing the ISP or agent.

Except that exports for other domains services don't depend on
information stored in another domain service record.  I don't have
export-related information about my DNS servers stored in any svc_domain
records.  That information is currently stored as a property of the
export itself.

And that is actually why I think we're in the router/virtual field mess
that we are.  The current export configuration assumes that you're going
to export information for all services of a given type (part_svc) to
exactly one device.  With svc_broadband, this is clearly not the case.  

>From the very beginning, the only svc_broadband export
(FS::part_export::router) required virtual fields in the router
containing information required to complete the export (ip, username,
password, etc).  That was a temporary hack that went on way too long,
and I regret writing it every time I look at it.  The proposed
svc_broadband rewrite was intended to fix that, but I don't think that I
said enough about that specific problem, or how to fix it.  I'll do so
below, and maybe it'll explain the reasoning for my opposition to
merging svc_broadband and router.

> +----------
> | >   The current mechanism (router, part_svc_router) offers better granularity
> | > for selection purposes.
> | 
> | Selection of what?  part_svc_router is intended to relate router to
> | part_svc records in order to define which types of services (part_svc)
> | can be provisioned on which routers (router).
> +----------
> 
>   I mean selection of appropriate 'parent.'  Directly associating
> part_svc_router (aka part_svc_svc_broadband) allows us to know which
> svc_broadband devices can supply what service to other svc_broadband
> devices.

I see what you mean now, as well as your reasoning for merging
svc_broadband with router.  At the time of writing (past and present
proposal), I also considered a way to arbitrarily chain svc_broadband
records just as you're suggesting.  Part of my motivation was to account
for the multi-tenant unit scenario, where a service that is typically
offered to a customer is used to provide service for many customers.
And as you're suggesting, the service for one customer, becomes the
provider of service to other subordinate customers.

Given the current implementation, I handle this situation by
provisioning the "parent" service in "my" customer, as you suggest.
Then I create a router (not related to the parent service) from which I
provision the subordinate services.  I am able to accomplish the same
effect without the need for or ability to relate svc_broadband records
directly.

> +----------
> | >   I suggest that a svc_broadband is associated with part_svc records much
> | > as router is now.  The edge and core flags, if desired, can then be moved
> | > onto svc_broadband.
> | 
> | svc_broadband is already related to part_svc via cust_svc.
> +----------
> 
>   Indeed.  And also through addr_block, router, and part_svc_router.

I think I see what your intention here is now.

> +----------
> | What is a core svc_broadband service?
> +----------
> 
>   A core svc_broadband service is one you might like to specifically filter
> in or out of an inventory report.  It is the object the freeside operator
> finds conceptually different from an edge svc_broadband service.  Perhaps
> exports are interested in this characteristic as well.

I'll make my argument for router/nas here.  My intention for router
(I'll call it nas now to signify it's post-refactor state) is to model a
device that provides services to customers.  Examples of a nas could be
a wireless AP, DSLAM, dial-up RAS or even mail, web, and DNS server.
Yes, even a web server.  Instead of combining router with svc_broadband,
I suggest we pull the device specific information (such as hostname,
login information, etc.) out of part_export_option and move it to nas.

That opens up the possibility for freeside to provision, for example, a
svc_www to a user selectable web server (nas) if you happen to have a
cluster of web servers, or web servers running different operating
systems.  This can currently be done, but only with multiple part_svc
records.

To state it another way...If we were to use part_export with
svc_broadband, the way part_export was indented to be used, the router's
IP address would be stored in part_export.machine.  This would and does
work just fine if you have exactly one router providing a given type of
service.  This is quite often not the case.  ISPs have many routers
providing the same type of service, and need a way to tell freeside
which of those routers to export to based on some criteria other than
the type of service.

The same problem exists with svc_www (and all service types), but is
just much less common.  An ISP with multiple web servers has no way to
pick web server "A" vs. web server "B" when provisioning equivalent web
hosting services.

I understand why you see router as useless in the current design.  The
difference is you want to get rid of it, and I want to make it useful.
The downside to your solution is that it doesn't solve the same problem
that exists for other service types, only svc_broadband.

I'm going to leave it at that, as I think that is the core of the
difference in our proposals.

Regards,

-- 
Kristian Hoffmann
Fire2Wire System Administrator
khoff at fire2wire.com