Opened 8 years ago

Closed 8 years ago

#1634 closed task (complete)

Abstract pool/lease store: initial requirements list

Reported by: tomek Owned by: stephen
Priority: medium Milestone: Sprint-DHCP-20120319
Component: dhcp Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

The whole requirements task (Database design for storage of V4 and V6 information.) was defined for 8 days. This is the first part of it.

Subtickets

Change History (14)

comment:1 Changed 8 years ago by stephen

  • Milestone changed from DHCP 2012 to Sprint-DHCP-20120206

comment:2 Changed 8 years ago by tomek

  • Owner set to tomek
  • Status changed from new to accepted

Design is available here: DhcpPoolLeaseDesign

comment:3 Changed 8 years ago by tomek

Follow-up ticket (design) created #1648.

comment:4 Changed 8 years ago by tomek

  • Owner changed from tomek to UnAssigned
  • Status changed from accepted to reviewing

I'm not sure how detailed the requirements should be. Here is initial list of requirements. Please review.

comment:5 follow-up: Changed 8 years ago by stephen

General Points
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
MUST allow lease manipulation on-line (during server operation)
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
This is should be a separate requirement.

MUST allow lease reservation for specific hosts (via hooks?)
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
MUST support option definitions
I would put this as "MUST be able to store user-defined options".

MUST allow multiple r/w access
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
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
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
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
Do we want to keep separate list of fixed-leases?
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?
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?
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
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
Go for the minimalist approach - just store the minimum needed, not the whole topology.

DNS Updates
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.


comment:6 follow-up: Changed 8 years ago by sar

MUST allow lease manipulation on-line (during server operation)
Do we need to allow this while the server is running? Or is it possible to do something similar to Bind9 where the database is frozen for a bit while the changes are made?

Re: Storage of additional information
Stephen has this in his notes:

  • It MUST be possible to store multiple options of the same type with a particular lease.

Can we elaborate on this? Does this mean multiple options from multiple sources or multiple options within the same packet? In v4 multiple options tend to get concatenated and we should be clear if it applies to v4 and if so how it applies.

I read the statement MAY allow view/update by existing tools
as saying that we may allow Omapi to access the database in some fashion. As there seems to be confusion as to what the document means it should be clarified. I assume we would only worry about Omapi and we wouldn't worry about tools that might read the current lease database file as there isn't much of a way for them to connect to the new database. And I would agree that this is a "may". We've told folks that we will see what we can do but haven't promised anything.

string or char[128] client-id - DUID is up to 128 bytes long, DHCPv4 uses HW address;
DHCPv4 client id doesn't have to be the HW address and is mostly treated as an opaque blob,
though I don't think that really affects the DB except that we need fields for both HW address
and client id.

timestamp cltt - client last communication time - required for failover;
I think there are several other fields we may need or want for failover if we choose to do the current failover draft again. However we may do failover in a different fashion. If we allow multiple DHCP servers to access the same backend database then we don't need to have the DHCP servers talk to each other to do failover. The failover is handled by the backend DB. Using this model does have implications - in particular with what happens if the two servers are partitioned.

bool fixed - Is this lease fixed? If yes, never remove it from DB
In the current v4 code fixed leases don't appear in the DB, they are in the configuration file but don't get written to the DB. Reserved leases do get written to the DB as well as going through the other steps of a lease.
This brings up the question of configuration vs DB. In the current split information such as pool start and end is in the configuration file but not in the DB. Are we planning to have a separate configuration store? (I thought the answer was yes). If so how are we deciding which information goes into which area?

bool fqdn_fwd - was forward update performed? Required during lease release or expiration.
What information we choose to store for DDNS will depend quite strongly on how we choose to implement it. The original suggestion was that there would be a co-located DNS server. The dhcp server would update the DNS server via messages. The DNS server would update the master DNS server using DNS magic. The more recent suggestion from Bluecat was that there would be a DDNS update module. The DHCP server would simply send the appropriate information to the DDNS module and it would be responsible for doing the DDNS transactions with an actual DNS server. It would be possible for the DDNS module to update the lease DB but it would probably be neater to have a separate DB that contained only the DDNS information. The DHCP server would pass messages to the DDNS module whenever there was a transition and let the DDNS module sort out if it needed to do an update.

In short we may not need to store any DDNS information (though we may wish to track anything we need to generate such as FQDN names.)

As a minor note currently we don't actually know which DNS server we updated. We can track up to 3 servers for a zone and simply hand them all to the DNS client code. Mostly we get back success of failure - but no indication of which server it contacted.

t1, t2 timers (v6 only)
I believe we currently keep similar things for v4 and use them to set the suggested renew and rebind times.

Do we want to keep separate list of fixed-leases?
I think there are two features in our current separation of fixed-leases. 1) We don't have to put them into the DB, and indeed don't do several things with them that we do with normal leases. 2) The provide a cheap way of doing failover. There are some places that only do fixed leases. When a new machine appears an address is selected for it and a new conf file is generated (or they use omapi to generate the new entry). In this case if the same set of fixed addresses are shared between a set of servers they can all the same clients without conflict. (But woe unto you if your files become inconsistent.)

I don't think (1) is that interesting and we have had to add the reserved option to allow for fixed addresses that do go through the normal cycle. (2) has some interest but we can probably get the same features out of using the same DB for multiple DHCP servers.

Do we want to have subnets and pools split?
I believe we should try and simplify the current arrangement, but the arrangement exists for some reasons so we should 1) try to figure out what they are 2) provide similar features in the new arrangement 3) be prepared to add some of the hierarchy as needed. (It may be that much of the complexity is simply due to adding new features on top of old and we don't actually need most of it, but I'm not sure if that is wishful thinking or not.)

I believe there is one place where the current arrangement isn't strictly hierarchical but I can't remember it offhand. In any case we should try and make any hierarchy clean and clear. Currently it is the case that even if you define some things within a restricted range (pool, subnet etc) the affects are global. People regularly run into this as a problem.

Do we want to store information in human readable form
Stephen's comment seems reasonable. I would add that in case of any inconsistency the binary data wins and the human readable is replaced.

Network topology
I don't think we currently need a complete topology. If I'm running the server on a machine with 3 interfaces but only provide it one via the command line it seems to be happy with a configuration that only describes that interface. We do need to supply information about an interface even if there won't be any clients using it directly though.

As to the complexity I think we may need to write up what we need for (b) before making a final decision. As a user I'd be unhappy if I needed to include specific interface to pool mappings. That would seem to make it difficult to modify the server hardware without having to reconfigure the DHCP server.

DNS Updates
See previous comments on DDNS. If we go with a separate module handling all of this then all these issues move to there.

From the scratchpad section
Are there requirements on detecting overlapping pools or other inconsistencies
My first though is that it would be part of the configuration code to figure out if something is inconsistent before it can be put into the lease database - assuming that some configuration information is going into the DB. Or were you thinking about bugs in the server causing it to try and write inconsistent information?

comment:7 follow-up: Changed 8 years ago by shane

I haven't looked at Stephen's or Shawn's comments yet, so there may be some duplication.

First, I think the requirements need an introduction. Something to describe what the point of an abstract lease storage is, and how it fits into Kea. So, talking about the model of having multiple concrete types of lease storage, and so on. It should also discuss the basic functionality that lease storage provides, which seems to be both lease storage an pool definition according to this document.

From the general requirements, does it make sense to explicitly mention that we want both administrative and programmatic (via an externally-exposed API) ability to change leases?

We should probably say what happens when a pool is removed during operation. Possibly when one is added too.

There is nothing in this document about how lease selection works. From a requirements level, we need to say if we want there to be alternative algorithms for lease selection. I have a vague feeling that we do, although we don't in DHCP 4.x so perhaps that is not important. In any case, if we decide that we don't want alternative algorithms we should also write that down too.

We should note that although at an abstract level lease and pool definitions must support for a wide range of scaling, concrete implementations may not. For example, SQLite does not support wide parallelism, but is certainly appropriate for smallish servers.

Maybe we also want to note support for really, really small scale sites? Like SOHO stuff with <10 devices?

Finally, I think it might make sense to separate out the requirements into:

  1. General
  2. DHCP
  3. DHCPv6

Because it's a bit confusing having them all combined.

Now I can look at the other comments and see how much overlap there is. :)

comment:8 Changed 8 years ago by stephen

  • Owner changed from UnAssigned to tomek

comment:9 in reply to: ↑ 5 Changed 8 years ago by tomek

Replying to stephen:

General Points

There are many suggestions that I agree with. I have applied them.

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

Copied this. This are actually 2 requirements: first is to be able to store user-defined options and the second is to remember them for each assigned lease if present.

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

Added as suggested, but that is somewhat difficult, e.g. sqlite blocks if more than one concurrent write is performed.

MUST scale from small (mostly sqlite) to medium (e.g. Postgres, MySQL, Oracle) to large (e.g. cassandra, hadoop) databases
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.

Reworded it and explained that this is a requirement for API itself, not the backend. API must support both small and very large installations. Some back-ends will be more appropriate for specific deployments than others. Added clarification to that effect.

Lease Information
Focus on the information to be stored, not the format.

Done as suggested. Kept requirements unified, but lease and pool information is split into separate v4/v6 sections.

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.

Removed exact type information from the design.

While we don't have to decide on specific types, I think we should not be vague anymore regarding actual DB layout. I think it is a right time to start concrete DB layout design (i.e. tables, fields and relations). Once this is done, we can start thinking about API definitions to handle/manipulate such data.

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

It is first and last lease in a pool. For address pools, it is first and last address, e.g. when you use 192.168.1.2 - 192.168.1.100 (start_lease=192.168.1.2, end_lease = 192.168.1.100).
But I get the point. This naming convention is somewhat ambiguous. Renamed to first_lease, last_lease.

I don't want to name it first_addr and last_addr, because I want the same table format for both addresses and prefixes.

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

Yes, that may be useful. User configs frequently have comments around pools.

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

I was more thinking about using hooks for that. We could define hooks for pool selection and use more rich semantics there than just a time-based selection. That would require adding extra hook, but I suppose that is ok.

Comments on Questions
Do we want to keep separate list of fixed-leases?
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.

I have thought about this more and I think we need separate table for host reservation after all. Keeping fixed-leases in table would be only part of the solution. On its own, it wouldn't work. Lease would have stopped being fixed after first client's RELEASE. The problem is that we now allow host definition to be populated with a lost of different things and fixed-address or fixed-prefix are just two of them. We can decide that this specific host gets extra option, or a different option. I think users will be very unhappy if we take away that possibility. Therefore

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

Added separate section for host reservation requirement.

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

The more I think about it, the more differences I see. I split them for now. If we decide to go with unified format, we will just merge those lists.


Do we want to have subnets and pools split?
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.

After giving more thought, I think we need both subnet and pool. Subnet defines that certain subnet is available on-link. That is required for 2 things:

  • in v6 decide which pool to use, when we have link address of the relay only (relay includes a global address that can be used to identify a link, where client is attached). This, by definition is not a dynamically assigned address, so it will always be outside of any pool. Therefore we need subnets.
  • when handling CONFIRM, server is supposed to answer a question "is this address valid for this link?", not "do you have binding for this lease?". To properly answer that question, server must have knowledge about full subnet on link, not only its dynamically allocated subset.

Given those two facts, we must use both subnet and pool.

Also there are valid cases, when there is one subnet, but many pools.

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.

No. One of the reasons we are rethinking configuration is to get rid of complexity, not exchange one complexity to another.

Do we want to store information in human readable form
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.

Agree.

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
Go for the minimalist approach - just store the minimum needed, not the whole topology.

DNS Updates
I suggested starting a new section in the requirements for DNS.

Agree. Created new section.

comment:10 in reply to: ↑ 6 Changed 8 years ago by tomek

Replying to sar:

MUST allow lease manipulation on-line (during server operation)
Do we need to allow this while the server is running? Or is it possible to do something similar to Bind9 where the database is frozen for a bit while the changes are made?

Since we already have requirement for concurrent DB writes, I think we should go with real on-line change. I imagine that there will be some short time freeze, e.g. checking if existing leases are still within new pool definitions.

Re: Storage of additional information
Stephen has this in his notes:

  • It MUST be possible to store multiple options of the same type with a particular lease.

Can we elaborate on this? Does this mean multiple options from multiple sources or multiple options within the same packet? In v4 multiple options tend to get concatenated and we should be clear if it applies to v4 and if so how it applies.

This was about v6 and relay included options. Added clarification that v4 options will be concatenated.

I read the statement MAY allow view/update by existing tools
as saying that we may allow Omapi to access the database in some fashion. As there seems to be confusion as to what the document means it should be clarified. I assume we would only worry about Omapi and we wouldn't worry about tools that might read the current lease database file as there isn't much of a way for them to connect to the new database. And I would agree that this is a "may". We've told folks that we will see what we can do but haven't promised anything.

I was too vague here. I meant that existing SQL clients or existing BIND10 tools like cfgmgr. I definitely didn't want to suggest OMAPI. Clarified that.

string or char[128] client-id - DUID is up to 128 bytes long, DHCPv4 uses HW address;
DHCPv4 client id doesn't have to be the HW address and is mostly treated as an opaque blob,
though I don't think that really affects the DB except that we need fields for both HW address
and client id.

Agree that they should be separated. However, for v4 we still should keep HW address. Users may want to assign fixed leases based on MAC addresses. Even in v6, folks are not happy with DUID not being equal to MAC. Therefore HW address option for DHCPv6 was proposed recently and has good chance of being approved.

timestamp cltt - client last communication time - required for failover;
I think there are several other fields we may need or want for failover if we choose to do the current failover draft again. However we may do failover in a different fashion. If we allow multiple DHCP servers to access the same backend database then we don't need to have the DHCP servers talk to each other to do failover. The failover is handled by the backend DB. Using this model does have implications - in particular with what happens if the two servers are partitioned.

CLTT is also useful for other things, like timers calculation or leasequery. Do you think it would be useful to review failover-12 draft and see which fields should be kept in DB?

On a related note, since v6 failover is currently not defined and we can't defer DB design until it is, we will need to realize that database format will get updated over time. Added requirement about it.

bool fixed - Is this lease fixed? If yes, never remove it from DB
In the current v4 code fixed leases don't appear in the DB, they are in the configuration file but don't get written to the DB. Reserved leases do get written to the DB as well as going through the other steps of a lease.

I think we should use it differently. In DHCP4 support for v4 appeared first and v6 was added much later. This is clearly visible in how the code operates, e.g. v6 requires server to have global addresses defined on intefaces (that is clearly an artificial requirement introduced by the software itself, not the protocol).

This brings up the question of configuration vs DB. In the current split information such as pool start and end is in the configuration file but not in the DB. Are we planning to have a separate configuration store? (I thought the answer was yes). If so how are we deciding which information goes into which area?

That was my assumption as well. We are now trying to design data structures. Where specific data will be kept is an implementation details. Added question about making that decision for each table. We should get back to that question.

bool fqdn_fwd - was forward update performed? Required during lease release or expiration.
What information we choose to store for DDNS will depend quite strongly on how we choose to implement it. The original suggestion was that there would be a co-located DNS server. The dhcp server would update the DNS server via messages. The DNS server would update the master DNS server using DNS magic. The more recent suggestion from Bluecat was that there would be a DDNS update module. The DHCP server would simply send the appropriate information to the DDNS module and it would be responsible for doing the DDNS transactions with an actual DNS server. It would be possible for the DDNS module to update the lease DB but it would probably be neater to have a separate DB that contained only the DDNS information. The DHCP server would pass messages to the DDNS module whenever there was a transition and let the DDNS module sort out if it needed to do an update.

Stephen suggested that we should keep a separate table for that. Although the co-located mode will probably be used in first implementation, regular (DDNS over wire) updates will later be supported as well. Personally, I think that having a separate module for that is very good approach. Nevertheless, I think this module will use both DB back-end and configuration store for its operation. Therefore we should pay attention to DDNS now. There are customers, who complained that after they reconfigure DHCP4, it does not clean up DNS properly. We should make this design flexible to keep DDNS info even after it no longer matches current configuration. Exact details still need to be worked out.

In short we may not need to store any DDNS information (though we may wish to track anything we need to generate such as FQDN names.)

As a minor note currently we don't actually know which DNS server we updated. We can track up to 3 servers for a zone and simply hand them all to the DNS client code. Mostly we get back success of failure - but no indication of which server it contacted.

That was exactly my point. Customers complained about that. Once they change their DNS configuration, it is no longer possible to clean up older entries. I think it would be good to use following algorithm:

  1. for new updates, use whatever is stored in configuration
  2. for existing leases, keep info on which server/key/protocol etc. was used to remove the entry in the same way as it was defined. Keep that even when current configuration changes.
  3. when removing RR, try to use info stored with lease. If it does not work, try to use current configuration.

That approach would increase our chances to remove RRs successfully.

t1, t2 timers (v6 only)
I believe we currently keep similar things for v4 and use them to set the suggested renew and rebind times.

I have missed that. Thanks. Renamed both (v4 and v6) fields to renew timer and rebind timer.

Do we want to keep separate list of fixed-leases?
I think there are two features in our current separation of fixed-leases. 1) We don't have to put them into the DB, and indeed don't do several things with them that we do with normal leases. 2) The provide a cheap way of doing failover. There are some places that only do fixed leases. When a new machine appears an address is selected for it and a new conf file is generated (or they use omapi to generate the new entry). In this case if the same set of fixed addresses are shared between a set of servers they can all the same clients without conflict. (But woe unto you if your files become inconsistent.)

I don't think (1) is that interesting and we have had to add the reserved option to allow for fixed addresses that do go through the normal cycle. (2) has some interest but we can probably get the same features out of using the same DB for multiple DHCP servers.

Since this is a clean sheet design, do you think that we need to keep both fixed and reserved leases? Wouldn't it be simpler if we decided to use just one type?

Do we want to have subnets and pools split?
I believe we should try and simplify the current arrangement, but the arrangement exists for some reasons so we should 1) try to figure out what they are 2) provide similar features in the new arrangement 3) be prepared to add some of the hierarchy as needed. (It may be that much of the complexity is simply due to adding new features on top of old and we don't actually need most of it, but I'm not sure if that is wishful thinking or not.)

I came up with 2 reasons why subnet and pools are split:

  • v6 relays don't have to include interface-id. In that case relay's global address is needed to find out which link client is attached to. By definition, this address is statically configured, so it is not in pool. I believe the same holds true for v4.
  • When server responds to CONFIRM in v6, it really answers if address is valid on this link, not if server has a lease for this address. Any server on link can answer CONFIRM. That is somewhat counter-intuitive, but please see recent discussion on DHC WG about it.

On the other hand, using only subnets is simpler. In some cases users may not care about confirm (e.g. fixed networks like broadband), and can use different mechanism (like interface-id or remote-id) to match clients with their pools.

I believe there is one place where the current arrangement isn't strictly hierarchical but I can't remember it offhand. In any case we should try and make any hierarchy clean and clear. Currently it is the case that even if you define some things within a restricted range (pool, subnet etc) the affects are global. People regularly run into this as a problem.

There is another possible hierarchy that is not present in DHCP4: interface. Dibbler users like the ability to simply say "serve pool X over interface Y". Such configuration is very simple. We need to embrace that idea anyway, as DHCPv6 server do not need to have global addresses, so it is not possible to detect server's attachment based on subnet analysis.

Do we want to store information in human readable form
Stephen's comment seems reasonable. I would add that in case of any inconsistency the binary data wins and the human readable is replaced.

My understanding is that Stephen suggested to use binary form and convert it to human form only if needed (e.g. to log if logging is enabled).

Network topology
I don't think we currently need a complete topology. If I'm running the server on a machine with 3 interfaces but only provide it one via the command line it seems to be happy with a configuration that only describes that interface.

We do need to supply information about an interface even if there won't be any clients using it directly though.

That is what I was referring to by saying complete topology. That does not work for v6. Server does not have to have global addresses at all.

As to the complexity I think we may need to write up what we need for (b) before making a final decision. As a user I'd be unhappy if I needed to include specific interface to pool mappings. That would seem to make it difficult to modify the server hardware without having to reconfigure the DHCP server.

How are you going to replace failing NIC without restarting server?

I see your point, though. Perhaps we can make interface definition optional? There are many simple cases, when it is useful and there are complicated cases when it is not.

DNS Updates
See previous comments on DDNS. If we go with a separate module handling all of this then all these issues move to there.

See my comments above. This separate module will still use DB and configuration store. Thus we need to design data layout.

From the scratchpad section
Are there requirements on detecting overlapping pools or other inconsistencies
My first though is that it would be part of the configuration code to figure out if something is inconsistent before it can be put into the lease database - assuming that some configuration information is going into the DB. Or were you thinking about bugs in the server causing it to try and write inconsistent information?

I really haven't given much thought on this. This question was also asked in hook context. What if hook overrides our proposed lease with something that does not match current configuration. Do we implement "user knows best" strategy?

It is tempting to say that any changes to lease and host data must be consistent with current configuration of pools. But do we want the opposite as well? What happens when user removes pool that has active leases in it? Do we keep the leases or toss them immediately? It would be better to keep them and remove them the next time client renews. (Removing a lease will trigger DDNS removal, while client is convinced that his lease is still valid and would be surprised that its FQDN stops resolving).

comment:11 Changed 8 years ago by tomek

Updated PoolLeaseDesign?. Will respond to Shane's comments tomorrow.

comment:12 in reply to: ↑ 7 Changed 8 years ago by tomek

Replying to shane:

I haven't looked at Stephen's or Shawn's comments yet, so there may be some duplication.

First, I think the requirements need an introduction. Something to describe what the point of an abstract lease storage is, and how it fits into Kea. So, talking about the model of having multiple concrete types of lease storage, and so on. It should also discuss the basic functionality that lease storage provides, which seems to be both lease storage an pool definition according to this document.

Agree. Wrote a paragraph about reasons for abstract API and a bit of background info.

From the general requirements, does it make sense to explicitly mention that we want both administrative and programmatic (via an externally-exposed API) ability to change leases?

Added M5 requirement, but do we really want to do that? We will get "why only leases? My tool needs to change pools/hosts/subnets/whatever as well" type of questions really soon. I imagine that many changes will be done over b10-cmdctl. We will probably be exposing SQL DB itself, so I'm not sure if we need to design API for that.

We should probably say what happens when a pool is removed during operation. Possibly when one is added too.

Added question 10 (part of my response to Shawn) about that. Adding pool is trivial. We start with pool that has zero leases in it and gradually start assigning leases from it. Now that you mentioned it, I just remembered that there is a nice feature in Dibbler about pool selection that we can use. See question 11.

There is nothing in this document about how lease selection works. From a requirements level, we need to say if we want there to be alternative algorithms for lease selection. I have a vague feeling that we do, although we don't in DHCP 4.x so perhaps that is not important. In any case, if we decide that we don't want alternative algorithms we should also write that down too.

Good point. Included this in question 11.

We should note that although at an abstract level lease and pool definitions must support for a wide range of scaling, concrete implementations may not. For example, SQLite does not support wide parallelism, but is certainly appropriate for smallish servers.

Clarified that API and concrete implementation support are not the same thing.

Maybe we also want to note support for really, really small scale sites? Like SOHO stuff with <10 devices?

That's a completely different topic. Few days ago I guys from R&D office of Telekomunikacja Polska (largest Polish telecom). They are working on CPE and complained that both Dibbler and ISC DHCP are way too large for their need, so they picked WIDE implementation. We started talking with Stephen what could be done to make Kea really small. One of the options would be to implement kind of b10-dhcp4-mini and b10-dhcp6-mini that would be stand-alone and not use most of the B10 stuff. It would basically be wrappers around libdhcp++. We could also rip features unnecessary in CPE environment, like DNS Update (somewhat debatable, but would save quite a bit of space), failover, confirm support etc.

Finally, I think it might make sense to separate out the requirements into:

  1. General
  2. DHCP
  3. DHCPv6

Requirements for v4 and v6 are really very similar. I proposed a slightly different split. See if you like it. If not, please propose a better one.

Because it's a bit confusing having them all combined.

Agree.

Now I can look at the other comments and see how much overlap there is. :)

No need to do that. I already did that.

comment:13 Changed 8 years ago by tomek

  • Owner changed from tomek to stephen

comment:14 Changed 8 years ago by stephen

  • Resolution set to complete
  • Status changed from reviewing to closed

I made some minor changes to the formatting to make it clearer. Also, in the "DB Information" section I took out references to tables so that it now states what information needs to be stored for each entity. (Depending on how much we normalize the database, one or more tables may be needed for each category of information.)

Added as suggested, but that is somewhat difficult, e.g. sqlite blocks if more than one concurrent write is performed.

I think that is only if there are concurrent writes to the same table; concurrent writes to different tables are allowed. (Although admittedly the common case is that multiple processes will want to write to the same table.)

I think we should not be vague any more regarding actual DB layout. I think it is a right time to start concrete DB layout design (i.e. tables, fields and relations).

Agreed, but let's put that in a separate design document. Otherwise there is a danger that we skew requirements to the design we have in mind.

Do we want to store additional flags relating to pools, such as:

I was more thinking about using hooks for that.

Hooks will be OK, providing that as part of the DHCP delivery we supply hook code for the common cases. At the last DHCP meeting we came to the conclusion that a lot of the stuff we now do in the configuration file can be done in hooks, and that is true. However, it will be easier for users if we supply some hooks to cover common cases.

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.

No. One of the reasons we are rethinking configuration is to get rid of complexity, not exchange one complexity to another.

Well, at some point we will need to associate attributes with items, and we need to get clear in our own minds what is needed.

My understanding is that Stephen suggested to use binary form and convert it to human form only if needed (e.g. to log if logging is enabled).

That was the idea.

One final thing: looking through the requirements, we must ensure that the design clearly identifies what will be in the lease database and what will be in the configuration database. We also need to be very clear - perhaps by writing explicit use-cases - how we set up the system to support common configurations. That way we will be able to check that the proposed design will work.

I'm closing the ticket because I think we have got as far as we can with the requirements at this stage. We can re-open it (or open another one) if we need to alter them in any significant way.

Note: See TracTickets for help on using tickets.