... | @@ -156,12 +156,10 @@ an active lease for that prefix. |
... | @@ -156,12 +156,10 @@ an active lease for that prefix. |
|
|
|
|
|
### Providing Additional Options
|
|
### Providing Additional Options
|
|
|
|
|
|
Queries provide a list of requested options which servers "should" provide, when possible. There is also mention
|
|
As mentioned earlier, LeaseQuery queries provide a list of requested options which servers should provide, when possible. There is also mention of a "sensitive options list" which servers could be configured with to not supply values deemed sensitive. Storing some or all of the options for each lease could have enormous impact on Lease IO. It is suggested here, that rather than store them, we recalculate the desired options for each the lease being returned in the LeaseQuery response. If we include vendor information and client-classes along with the relay data stored for each lease, we should be able to provide the bulk of the options that might be requested. A "sensitive options list" would be supplied as a Hook parameter.
|
|
of a "sensitive options list" which servers could be configured with to not supply values deemed sensitive. As discussed earlier, storing options for each lease could have enormous impact on Lease IO. It is suggested here, that we recalculate the desired option values for each the lease(es) being returned in the LeaseQuery response. If we include vendor IDs and possibly client-class lists in the data stored for each lease, we should be able to provide the bulk of options that would be requested.
|
|
|
|
|
|
|
|
Whether we implement this initially, or ever is another matter. It is suggested that we wait until we have user feedback as to whether the additional options are important.
|
|
Whether we implement this initially, or ever is another matter. It is suggested that we wait until we have user feedback as to whether the additional options are important.
|
|
|
|
|
|
|
|
|
|
## Looking Forward
|
|
## Looking Forward
|
|
|
|
|
|
While the scope of this design does not include Bulk LeaseQuery, there is at least one point worth discussing. Bulk LeaseQuery, for both DHCPv4 and DHCPv6, provides for the ability to search for leases by relay attributes such as relay-id, remote-id, link address. In other words, by values within the same information that this design proposes be stored as part of a lease's user-context. The proposed format in this design is store these values opaquely rather than as individual sub-option values. While more efficient for lease storage IO during normal DHCP operations, it may not be the best arrangement for Bulk LeaseQuery performance and may well require walking lists of leases, as opposed to querying against indexes of explicit values.
|
|
While the scope of this design does not include Bulk LeaseQuery, there is at least one point worth discussing. Bulk LeaseQuery, for both DHCPv4 and DHCPv6, provides for the ability to search for leases by relay attributes such as relay-id, remote-id, link address. In other words, by values within the same information that this design proposes be stored as part of a lease's user-context. The proposed format in this design is store these values opaquely rather than as individual sub-option values. While more efficient for lease storage IO during normal DHCP operations, it may not be the best arrangement for Bulk LeaseQuery performance and may well require walking lists of leases, as opposed to querying against indexes of explicit values.
|
... | | ... | |