BIND 10 #1634: Abstract pool/lease store: initial requirements list

[BIND 10 Development]

#1634: Abstract pool/lease store: initial requirements list
-------------------------------------+-------------------------------------
                   Reporter:  tomek  |                 Owner:  UnAssigned
                       Type:  task   |                Status:  reviewing
                   Priority:  major  |             Milestone:  Sprint-
                  Component:  dhcp   |  DHCP-20120220
                   Keywords:         |            Resolution:
            Defect Severity:  N/A    |             Sensitive:  0
Feature Depending on Ticket:         |           Sub-Project:  DHCP
        Add Hours to Ticket:  0      |  Estimated Difficulty:  0
                  Internal?:  0      |           Total Hours:  0
-------------------------------------+-------------------------------------

Comment (by stephen):

 '''General Points'''[[BR]]
 I suggest that the requirements be numbered - it makes it easier to refer
 to them.  Perhaps easiest would be to number each section then number the
 requirements within a section.


 '''General Requirements'''[[BR]]
 ''MUST allow lease manipulation on-line (during server operation)''[[BR]]
 I think I would rephrase this as "MUST allow interrogation and
 manipulation of the lease by external tools while the server is
 operating".  The same goes for the similar requirement on the pool.

 Suggest that requirements related to the lease be grouped together, and
 the same for the pool requirements: it makes it clearer.

 ''Number of pools MUST NOT be limited''[[BR]]
 This is should be a separate requirement.

 ''MUST allow lease reservation for specific hosts (via hooks?)''[[BR]]
 Remove the "(via hooks?)"; that is an implementation detail and is not a
 requirement.  The same goes for the requirement ''MUST allow pool
 selection for new clients (via hooks)''.

 ''additional, flexible information MUST be stored along with lease (e.g.
 subscriber-id, relay-id or other options. This may be used for RECONFIGURE
 or requested over LEASEQUERY). Number of actual information MUST be
 flexible as number of options may increase in the future.''  I suggest:
 {{{
 It must be possible to store DHCP options with the lease (e.g. subscriber-
 id,
 relay-id or other options).
 * The number of options that can be associated with the lease MUST NOT be
   limited.
 * No restrictions must exist on the types of options and their data.
 * It MUST be possible to store multiple options of the same type with a
   particular lease.
 }}}

 The last requirement in this section: ''MAY allow view/update by existing
 tools'' is not really an independent requirement - it is implicitly
 covered by the lease/pool manipulation requirements.

 '''Scalability Requirements'''[[BR]]
 ''MUST support option definitions''[[BR]]
 I would put this as "MUST be able to store user-defined options".

 ''MUST allow multiple r/w access''[[BR]]
 Clearer to put "MUST be able to support concurrent read/write access from
 multiple processes".

 ''MUST scale from small (mostly sqlite) to medium (e.g. Postgres, MySQL,
 Oracle) to large (e.g. cassandra, hadoop) databases''[[BR]]
 I would put this as "MUST be able to work with different databases".  It
 is quite possible that an SQLite database would be too slow and not
 support a large DHCP installation.  But that is the fault of the database
 and not a problem with the system.

 '''Lease Information'''[[BR]]
 Focus on the information to be stored, not the format.  For example, a
 valid design would be to separate information about the IPV4/IPV6 leases
 into different tables.  In that case the size of the address field in the
 V4 table would be different from that in the V6 table.  I suggest listing
 the V4 information and V6 information separately - it is a design choice
 if the information is combined in one table.

 The following comments are about individual items but, unless the format
 of the data is mandated by an RFC, just identify the data to be stored.
 * client-id/client-id-length/hw-address: No need to worry about the length
 of the client-id field.  If this is stored in a string in a database, the
 database will handle storing the size information.
 * pool-id: There are no pointers in SQL true, but storing in one table the
 ID of a row in another table is very common, so does not need a remark.
 This would be better described as "Pool from which the lease was
 assigned".
 * string fqdn: if the fqdn is shared by multiple leases, it may be better
 not to store this as a string - perhaps a pointer to a row in another
 table.  For this reason, just refer to it as fqdn.
 * address fqdn_dns: I would by this as "Indication of DNS server where DNS
 update was performed".  It might not be an address - it could be a pointer
 into a separate table that holds both the address of the server along with
 the TSIG information needed to access it.

 '''Pool Information'''[[BR]]
 As noted above, for the requirements it will be clearer to separate out
 the V4 pool requirements for the V6 pool requirements.

 Not sure what start_lease/end_lease is - it seems to be separate things
 for different address types.

 Would we want to store comments with individual pool entries?  They might
 be useful when inspecting the database.

 Do we want to store additional flags relating to pools, such as:
 * Don't use before ''time''
 * Don't use after ''time''
 * Don't use


 '''Comments on Questions'''[[BR]]
 ''Do we want to keep separate list of fixed-leases?''[[BR]]
 This is a design issue, but I would say no.  Treating them the same as
 temporary leases - perhaps not even marking them as fixed, just setting
 the lease end time to a thousand years in the future - would seem to be
 the easiest for implementation purposes.

 The need for name reservation is a requirement and should be explicitly
 included in the requirements.

 ''Do we want IPv4 and IPv6 lease structures unified?''[[BR]]
 This is a also design issue - the requirements should just state what
 needs to be stored and modified.

 ''Do we want to have subnets and pools split?''[[BR]]
 The current split does seem a bit confusing - I can specify a range of
 addresses in a subnet, with subnet-specific parameters, or in a pool, with
 pool-specific parameters.  If we can get away from subnets, I would drop
 them.

 The more general question though is whether we want some form of pool
 hierarchy with the ability to associate attributes with any level of the
 hierarchy and with the resulting set of attributes for an address
 determined from the attributes at its level and those above it.

 ''Do we want to store information in human readable form''[[BR]]
 I would go for binary data first and then move to human-readable data if
 we want.  The reason here comes because human-readable data can be bad for
 operations that we want to do, e.g. the string "10.25.0.0" sorts after
 "10.192.0.0" even though numerically it comes before it.  This could cause
 problems if we need to sort retrieved data.

 Alternatively, we could store both - use the binary data on input, but add
 an operation to fill in the human readable fields on output.

 ''Network topology''[[BR]]
 Go for the minimalist approach - just store the minimum needed, not the
 whole topology.

 ''DNS Updates''[[BR]]
 I suggested starting a new section in the requirements for DNS.

 Comments from one customer indicate that the ability to clean up the DNS -
 even if the responsibility for an address has been reassigned - is
 important.  We may only be able to do that in certain circumstances, but
 if we can, we should.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1634#comment:5>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development