[freeside-devel] Broadband Services Spec

[Jeff Finucane]

Kristian Hoffmann <khoff at fire2wire.com> at Wed, 27 Jun 2007 14:10:57 -0700....

+----------
| 
| On Wed, 2007-06-27 at 15:11 -0400, Jeff Finucane wrote:
| > Freeside Developers:
| > 
| >   I do not see any particular reason to separate svc_broadband and nas
| > as currently indicated at 
| > http://www.sisd.com/mediawiki/index.php/Broadband_Services_Spec as the
| > same types of information are required for each.  
| 
| router and svc_broadband are two conceptually different things.  [ ... ]
| 
| Can you point out the overlap between router and svc_broadband?  Aside
| from physical address, I don't see it.
+----------

   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.

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

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

+----------
| >   addr_block/svc_ip may be directly associated with a svc_broadband and
| > the superfluous router record disappears.
| 
| addr_block should be related to svc_ip, and svc_ip with svc_broadband
| (as necessary).  But how do a block of IP addresses (layer 3) related in
| any way to a single svc_broadband service (layer 2)?
+----------

  In some situations, a layer 2 svc_broadband service may require a block
of IP address for doling out to subsidiary svc_broadband services.  It
well might require a /32 addr_block to represent a management interface.
It may not require any at all.  The use of these values is determined
by the exports.

+----------
| Again, I don't see how relating part_svc to svc_broadband *twice* can be
| useful.
+----------

  It already is.  Once is through cust_svc, and the other is through
addr_block, router, and part_svc_router.  I am suggesting dumping
'router' as an unnecessary complication.  The distinction between
nas and svc_broadband also seems a complication.

  svc_broadband records with part_svc_svc_broadband (aka part_svc_router)
records are candidates for parenting svc_broadband records who's cust_svc
records indicate matching part_svc records.


-- 
jeff at cmh.net

"There is no worse tyranny than to force a man to pay for what he does
 not want merely because you think it would be good for him." 

 Professor Bernardo de le Paz
  [ R.A. Heinlein -- "The Moon is a Harsh Mistress" ]