Merge problems

Kristian Hoffmann khoff at pc-intouch.com
Tue Mar 26 09:43:24 PST 2002


I was looking at ticket #332 (Wish list/Ideas relating to svc_*), and was
wondering how interested you were in doing something like that.  We are
still trying to rewrite one of our major changes so it isn't such a kluge.
Our biggest problem is finding a good way to export the service.

It's a two part service.  The first part is a layer 2 transport service,
or svc_l2.  With all high speed internet connections these days, there is
some sort of ethernet transport.  Wireless, DSL, CoLo, etc. are all fancy
ways of distributing a bridged ethernet connection.  So, this service
reflects the physical ethernet connection and information like where the
connection was installed, what type of equipment was used, and how much
bandwidth should be allowed over the connection.

The second part is the IP service, or svc_ip.  It keeps track of the MAC
address and IP address of one, several, or a subnet of devices connected
to the other side of the ethernet connection.

The first problem is with the svc_l2.  Different types of svc_l2's are
necessary because of the different kinds of services available.  And each
different type of svc_l2 needs it's own type specific fields in the
database.  We are thinking about having tables like l2_wireless, l2_dsl,
and l2_colo to store the type-specific information.  When you want to add
a new type, you just add the tables and write your check functions to do
data type checking and validation.  Comments?

The biggest problem is exporting.  We've working out the IP address
provisioning but that will take forever to go over.  Basically, there is a
table of access concentrators (could be DSLAM, Wireless AP, ethernet
switch), and a table of available IP subnets from which each access
concentrator can allocate addresses.  So in theory, even for the same type
of service, you could have a Cisco 1600 at one location, and a Nortel
A92392, at another.  So, you would need different export scripts for each
access concentrator. |Brick wall here|

That brings me back to the ticket mentioned at the top.  We've been
playing with the idea of setting up an event-based export system.  For our
case, the code for doing Add, Replace, Delete, ... could each be stored in
a table along with each access concentrator.  So when a service is
modified, it would call a notify fucntion, passing itself, that would
lookup it's AC and run the correct event code.  This could be generalized
to any service with different event scripts being stored either in
part_svc or in a way similar to the invoice event.

Comments Ivan, or anyone else?  We can't decide.

Thanks,

-Kristian





More information about the freeside-devel mailing list